Il 07-09-2018 21:26 Eric Blake ha scritto:
We're also trying to add support for incremental backups into a future version of libvirt on top of the qemu 3.0 feature of persistent bitmaps in qcow2 images, which could indeed guarantee that you transfer only the portions of the guest disk that were touched since the last backup. But as that's still something I'm trying to code up, your solution of using rsync to pick out the deltas is as good as anything you can get right now.
Plain rsync is going to be very slow for large file transfer. I strongly suggest to experiment with rsync "--inplace no-whole-file" options to really transfer/write changed bits only. If that does not cut in, you can try with bdsync[1] or blocksync[2] [1] https://github.com/TargetHolding/bdsync [2] https://github.com/shodanshok/blocksync
- blockcommit the overlay: blockcommit guest /path/to/testsn --active --wait --verbose --pivot - delete the snapshot: snapshot-delete guest --snapshotname testsn --metadata - remove the overlay
Is that ok ? How "safe" is blockcommit on a running guest ?
Yep, that's the right way to do it! It's perfectly safe - the guest doesn't care whether it is reading/writing from the backing file or the overlay, and even if the blockcommit action is aborted, you can restart it for the same effects.
I found the "manual overlay rm" a bit of a pain. What is the reason why a successfull blockcommit does not delete the just-inactivate overlay file? Thanks. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.danti@assyoma.it - info@assyoma.it GPG public key ID: FF5F32A8