On 05/01/2018 02:08 PM, Matthew Schumacher wrote:
List,
Two years ago there was discussion on implementing QEMU's
block-dirty-bitmap backup solution:
https://www.redhat.com/archives/libvir-list/2016-June/msg00380.html
https://www.redhat.com/archives/libvir-list/2016-April/msg00401.html
But I haven't seen anything since, and looking through git, it doesn't
look like any of these patches were included.
Can someone please bring me up to speed on what is up with these patches
and what the current thinking is in regards to backing up with libvirt?
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
Currently I'm snapshotting, then syncing the quiesced base image to one
I have on alternate media, but it's slow and takes up a lot of space.
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