[libvirt PATCH v2 1/2] docs: kbase: Add a doc on live full disk backup
mprivozn at redhat.com
Tue May 11 07:54:32 UTC 2021
On 5/10/21 6:39 PM, Kashyap Chamarthy wrote:
> This is a rewrite of:
> Once this commit merges, the above wiki should point to this kbase
> NB: I've intentionally left out the example for pull-based full backups.
> I'll tackle it once QMP `x-blockdev-reopen` comes out of experimental
> mode in upstream QEMU. Then pull-based can be described for both full
> and and differntial backups.
> Overall, future documents should cover:
> - full backups using both push- and pull-mode
> - differential backups using both push- and pull-mode
> Signed-off-by: Kashyap Chamarthy <kchamart at redhat.com>
> docs/kbase/live_full_disk_backup.rst | 186 +++++++++++++++++++++++++++
> docs/kbase/meson.build | 1 +
> 2 files changed, 187 insertions(+)
> create mode 100644 docs/kbase/live_full_disk_backup.rst
> diff --git a/docs/kbase/live_full_disk_backup.rst b/docs/kbase/live_full_disk_backup.rst
> new file mode 100644
> index 0000000000..19f027daac
> --- /dev/null
> +++ b/docs/kbase/live_full_disk_backup.rst
> @@ -0,0 +1,186 @@
> +Efficient live full disk backup
> +.. contents::
> +Live full disk backups are preferred in many scenarios, *despite* their
> +space requirements. The following outlines an efficient method to do
> +that using libvirt's APIs. This method involves concepts: the notion of
> +`backing chains <https://libvirt.org/kbase/backing_chains.html>`_,
> +`QCOW2 overlays
> +and a special operation called "active block-commit", which allows
> +live-merging an overlay disk image into its backing file.
> +Two kinds of backup: "push" and "pull"
> +QEMU and libvirt combine the concept of `bitmaps
> +<https://qemu-project.gitlab.io/qemu/interop/bitmaps.html>`_ and network
> +block device (NBD) to allow copying out modified data blocks. There are
> +two approaches to it: In the first, "push mode", when a user requests
> +for it, libvirt creates a full backup in an external location (i.e.
> +libvirt "pushes" the data to the target).
> +In the other, "pull mode", libvirt (in coordination with QEMU) exposes
> +the data that needs to be written out and allows a third-party tool to
> +copy them out reliably (i.e. the data is being "pulled" from libvirt).
> +The pull-based backup provides more flexibility by letting an external
> +tool fetch the modified bits as it sees fit, rather than waiting on
> +libvirt to push out a full backup to a target location.
> +The push- and pull-mode techniques also apply for differential backups
> +(it also includes incremental backups), which track what has changed
> +since *any* given backup.
> +This document covers only the full backups using the the "push" mode.
I'm surprised that 'ninja test' did not catch it. And it can also be
seen in the pipeline output you link in cover letter - if you know where
to look because it's way too verbose.
More information about the libvir-list