All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Snow <jsnow@redhat.com>
To: Qemu-block <qemu-block@nongnu.org>
Cc: Markus Armbruster <armbru@redhat.com>,
	qemu-devel <qemu-devel@nongnu.org>
Subject: [Qemu-devel] [RFC] Differential Backups
Date: Wed, 29 Apr 2015 18:51:08 -0400	[thread overview]
Message-ID: <5541605C.2090904@redhat.com> (raw)

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.

             reply	other threads:[~2015-04-29 22:51 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-29 22:51 John Snow [this message]
2015-05-05 10:25 ` [Qemu-devel] [Qemu-block] [RFC] Differential Backups Stefan Hajnoczi
2015-05-05 15:55   ` John Snow
2015-05-06  9:17     ` 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=5541605C.2090904@redhat.com \
    --to=jsnow@redhat.com \
    --cc=armbru@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.