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.da...@assyoma.it - i...@assyoma.it
GPG public key ID: FF5F32A8
_______________________________________________
libvirt-users mailing list
libvirt-users@redhat.com
https://www.redhat.com/mailman/listinfo/libvirt-users
