Re: [libvirt-users] Drive-backup functions.

On 05/01/2018 02:08 PM, Matthew Schumacher wrote: We're working on formalizing a new API to make checkpoints (the libvirt commands that create persistent bitmaps on qcow2 images) and incremental backups (the libvirt commands to create either a direct backup [push model, where qemu writes the backed up data to the destination based on the bitmap] or facilitates a third-party backup [pull model, where qemu exposes an NBD image containing the data at the time of the backup, along with a way for the third party to query the bitmap to learn which portions of the disk changed since the last backup]). Read the giant thread here [1] for more details and/or contributions, although I hope to start another thread soon with a revised version of the proposal that irons out some of the details from last round, with a goal of getting the libvirt API committed during May. [1] https://www.redhat.com/archives/libvir-list/2018-April/thread.html#00115 Indeed, incremental backups using qcow2 bitmaps will make it so you don't have to copy off quite as much data when capturing just the delta of what changed since a previous backup checkpoint, and that's true whether it is qemu writing the backup [push model] or a third party consuming the backup over NBD [pull model]. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org