From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48560) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ynap1-0000MQ-Ma for qemu-devel@nongnu.org; Wed, 29 Apr 2015 18:51:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ynaow-00035v-NF for qemu-devel@nongnu.org; Wed, 29 Apr 2015 18:51:15 -0400 Message-ID: <5541605C.2090904@redhat.com> Date: Wed, 29 Apr 2015 18:51:08 -0400 From: John Snow MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] [RFC] Differential Backups List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Qemu-block Cc: Markus Armbruster , qemu-devel This is a feature that should be very easy to add on top of the existing incremental feature, since it's just a difference in how the bitmap is treated: Incremental - Links to the last incremental (managed by libvirt) - Clears the bitmap after creation Differential: - Links to the last full backup always (managed by libvirt) - Does not clear the bitmap after creation No biggie. How it works currently: Incremental backups are created via the MIRROR_SYNC_MODE_DIRTY_BITMAP backup mode. An early version of the patchset actually had an additional parameter called the BitmapUseMode that controlled how the bitmap was cleared, a concern that was later made obsolete for other reasons. I can add Differential backups in two ways: (1) rename MIRROR_SYNC_MODE_DIRTY_BITMAP to MIRROR_SYNC_MODE_INCREMENTAL, and then add MIRROR_SYNC_MODE_DIFFERENTIAL. It's not too late to do this, since 2.4 has just started. (2) Re-add the BitmapUseMode parameter and add some enums: BITMAP_USE_MODE_INCREMENTAL BITMAP_USE_MODE_DIFFERENTIAL I think I am partial to #1, if only to cut down on additional parameters, especially ones that are only useful to a small subset of backup types. I am also considering adding a QMP primitive to allow people to /copy/ bitmaps. This would allow users to differentiate backup chains after they've already been started -- e.g.: - User creates drive0, a full backup, and bitmap monthly0. - Six days in, user decides it would be very nice to add a "weekly" incremental backup series to the same drive, but doesn't want to lose out on the monthly chain that was already started. - User copies the monthly0 bitmap to a new weekly0 target. - User can continue two independent incremental series intended for different periodicity. Actually, the copy primitive would allow people to do both differentials and incrementals with the existing backup mode by copying the bitmap before each usage, but that's slightly yucky, so I'd rather just add both features to increase the flexibility of the delta backup system in general.