From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54880) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vksww-0000cU-V9 for qemu-devel@nongnu.org; Mon, 25 Nov 2013 04:59:32 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vkswr-0008VG-0W for qemu-devel@nongnu.org; Mon, 25 Nov 2013 04:59:26 -0500 Received: from mx1.redhat.com ([209.132.183.28]:52358) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vkswq-0008VC-OS for qemu-devel@nongnu.org; Mon, 25 Nov 2013 04:59:20 -0500 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id rAP9xJHY022874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 25 Nov 2013 04:59:19 -0500 Message-ID: <52931F70.5020904@redhat.com> Date: Mon, 25 Nov 2013 17:59:12 +0800 From: Fam Zheng MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] [RFC] Incremental live backup with in memory dirty bitmap List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "qemu-devel@nongnu.org" Cc: Kevin Wolf , Paolo Bonzini , Stefan Hajnoczi 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