[libvirt-users] Re: backup procedure using blockcopy

Nicolas Sebrecht nsebrecht at piing.fr
Thu Mar 21 08:08:02 UTC 2013


The 20/03/13, Eric Blake wrote:
> On 03/18/2013 05:39 AM, Nicolas Sebrecht wrote:

> > I'd say that the man page miss the information that these commands can
> > run with a running guest, dispite the mirroring feature might imply it.
> 
> Care to write a patch?  The virsh man page is generated from
> libvirt.git:tools/virsh.pod.

Sure, I wish to write one but I'm very busy these days. Will do my
best.

> > The main drawback I can see is that the hypervisor must have at least as
> > free disk space than the disks to backup... Or have the path/to/backups
> > as a remote mount point.
> 
> Yes, but that's true of any backup operation - you are committing to the
> disk space for both the live and the backup, in some form or another.
> Also, disk mirroring to a remote point is fairly easy to set up, by
> using nbd:... instead of /path/to/file as the destination for the
> blockcopy, and having an NBD server listening on the remote destination
> side.

Don't know NBD very well but I'll investigate on it. Thanks for the
input.

> > Now, I wonder if I change of backup strategy and make the remote hosting
> > the backup mounted locally on the hypervisor (via nfs, iSCSI, sshfs,
> > etc), should I expect write performance degradation? I mean, does the
> > running guest wait for underlying both mirrored disk write (cache is set
> > to none for the current disks)?
> 
> Probably a question better asked on the qemu list, but yes, my
> understanding is that if you have a disk mirror or backup job set up,
> then qemu has to manage to flush I/O to two locations instead of one,
> and might end up slightly slowing the guest as a result.

Ok.

Thank you very much Eric for this whole thread and your efforts in
giving me all these information I was missing.  Very appreciated.

-- 
Nicolas Sebrecht




More information about the libvirt-users mailing list