qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Fam Zheng <famz@redhat.com>
To: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Cc: Kevin Wolf <kwolf@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Stefan Hajnoczi <stefanha@redhat.com>
Subject: [Qemu-devel] [RFC] Incremental live backup with in memory dirty bitmap
Date: Mon, 25 Nov 2013 17:59:12 +0800	[thread overview]
Message-ID: <52931F70.5020904@redhat.com> (raw)

Hi all,

This is an idea about allowing online incremental backup of block 
device, with drive-backup and (proposed here) in-memory block dirty bitmap:

1. We enable a dirty bitmap on a block device, at the start point of 
write tracking:

   (QMP) dirty-bitmap-add device=foo name=bitmap0 granularity=4k

Since now, all the writes to "foo" will mark dirty bits on it.

2.1 Later, when the user wants to export all the dirty data, one 
possible approach is using image fleecing:

   # step a. prepare the image fleecing target
   (QMP) blockdev-add backing=foo file.filename=backup.qcow2 id=backup0 
if=none driver=qcow2

   # step b. stop the dirty bitmap and start backup job. These two steps 
need to be in a transaction, so the exported data matches the exported 
dirty bitmap
   (QMP) transaction:
             dirty-bitmap-stop device=foo name=bitmap0
             blockdev-backup device=foo sync=none target=backup0

   # step c. export the snapshot:
   (QMP) nbd-server-add device=backup0

   # step d. export the dirty bitmap as well, so the management 
application can access it and decide what sectors to backup
   (QMP) dirty-bitmap-nbd-add device=foo name=bitmap0

Now the management application can connect to both dirty bitmap target 
and image fleecing target, and read whatever data it is interested in.

The tricky part is to export the dirty bitmap through NBD, but it may 
also be useful for persistent the in-memory dirty bitmap too.

2.2 Alternatively, we can avoid exporting the dirty bitmap through NBD, 
by adding another sync mode "dirty" to drive-backup, and change step b to:

   # step b. stop the dirty bitmap and start backup job with the dirty 
bitmap
   (QMP) transaction:
             dirty-bitmap-stop device=foo name=bitmap0
             blockdev-backup device=foo sync=dirty bitmap=bitmap0 
target=backup0

With the "dirty" sync mode, drive-backup/blockdev-backup takes a dirty 
bitmap name of the device and writes only dirty data to target.

Note that NBD is not necessary for backup, we can use "drive-backup" and 
omit step c as well. Also, the target could be an NBD server, in which 
case we will directly send new data to a remote NBD target. This part is 
fully flexible.

Summary: what we are missing are the dirty bitmap interfaces to 
add/stop/remove/query/export it and it's support of transaction, depends 
on how we want to use it. E.g. for continuity of the incremental 
tracking, the transaction could be:

   (QMP) transaction:
             dirty-bitmap-stop device=foo name=bitmap0
             dirty-bitmap-add device=foo name=bitmap1   # Start a new 
bitmap atomically
             blockdev-backup device=foo sync=dirty bitmap=bitmap0 
target=backup0

And the last command is to free the no longer used dirty bitmap:

   (QMP) dirty-bitmap-remove device=foo name=bitmap0

So, do these sound good/useful at all? Any comment is welcome!

Thanks,
Fam

             reply	other threads:[~2013-11-25  9:59 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-25  9:59 Fam Zheng [this message]
2013-12-02 15:48 ` [Qemu-devel] [RFC] Incremental live backup with in memory dirty bitmap Stefan Hajnoczi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52931F70.5020904@redhat.com \
    --to=famz@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).