Re: [Qemu-devel] [PATCH v3 0/8] block: drive-backup live backup command

[Stefan Hajnoczi]

On Tue, May 21, 2013 at 10:58:47AM +0000, Dietmar Maurer wrote:
> > >> True, but that would happen only in case the host crashes.  Even for
> > >> a QEMU crash the changes would be safe, I think.  They would be
> > >> written back when the persistent dirty bitmap's mmap() area is
> > >> unmapped, during process exit.
> > >
> > > I'd err on the side of caution, mark the persistent dirty bitmap while
> > > QEMU is running.  Discard the file if there was a power failure.
> > 
> > Agreed.  Though this is something that management must do manually, isn't 
> > it?
> > QEMU cannot distinguish a SIGKILL from a power failure, while management
> > can afford treating SIGKILL as a power failure.
> > 
> > > It really depends what the dirty bitmap users are doing.  It could be
> > > okay to have a tiny chance of missing a modification but it might not.
> 
> I just want to mention that there is another way to do incremental backups. 
> Instead
> of using a dirty bitmap, you can compare the content, usually using a digest 
> (SHA1) on clusters.

Reading gigabytes of data from disk is expensive though.  I guess they
keep a Merkle tree so it's easy to find out which parts of the image
must be transferred without re-reading the entire image.

That sounds like more work than a persistent dirty bitmap.  The
advantage is that while dirty bitmaps are consumed by a single user, the
Merkle tree can be used to sync up any number of replicas.

> That way you can also implement async replication to a remote site (like MS 
> do).

Sounds like rsync.

Stefan