Re: [libvirt-users] how "safe" is blockcommit ?

----- On Sep 7, 2018, at 9:26 PM, Eric Blake eblake(a)redhat.com wrote: > On 09/07/2018 12:06 PM, Lentes, Bernd wrote: >> Hi, >> >> currently i'm following >> https://wiki.libvirt.org/page/Live-disk-backup-with-active-blockcommit. I 'm >> playing around with it and it seems to be quite nice. >> What i want is a daily consistent backup of my image file of the guest. >> I have the idea of the following procedure: >> >> - Shutdown the guest (i can live with a downtime of a few minutes, it will >> happen in the night). >> And i think it's the only way to have a real clean snapshot > > Not the only way - you can also use qemu-guest-agent with a trusted > guest to quiesce all filesystem I/O after freezing database operations > at a consistent point, for a clean snapshot of a live guest. But > shutting down is indeed safe, and easier to reason about than worrying > whether your qga interaction is properly hooked into all necessary > places for a live quiesce. > >> - create a snapshot with snapshot-create-as: snapshot-create-as guest testsn >> --disk-only >> - start the guest again. Changes will now go into the overlay, as e.g. inserts >> in a database >> - rsync the base file to a cifs server. With rsync not the complete, likely big >> file is transferred but just the delta > > 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. > >> - 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. > > (Okay, if you want to get technical, you need to know that committing > from 'Base <- mid <- top' down to 'Base' leaves 'mid' in an inconsistent > state - but that's not something the guest can see through 'top'; and > your specific case is just committing to the immediate backing layer > rather than skipping layers like that). > >> It's possible that during the rsync, when the guest is running, some inserts are >> done in a database. > > As long as the backing file is read-only during the rsync (which it is, > since all your guest writes are going to the overlay), then nothing the > guest can do will interfere with what rsync can see. Just be sure that > you don't start the blockcommit until after rsync is done. > >> Is it safe to copy the new sectors (i assume that's what blockcommit does) under >> a running database ? >> Or is it only safe doing blockcommit on a stopped guest ? > > Live blockcommit is safe, and exists so you don't have to stop the guest.