Re: backup procedure using blockcopy

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 03/18/2013 05:39 AM, Nicolas Sebrecht wrote:
> The 15/03/13, Eric Blake wrote:
>> On 03/15/2013 06:17 AM, Nicolas Sebrecht wrote:
> 
>> In other words, 'blockcopy' is my current preferred method of online
>> guest backup, even though I'm still waiting for qemu improvements to
>> make it even nicer.
> 
> As I understand the man-page, blockcopy (without --shallow) creates a
> new disk file of a disk by merging all the current files if there are
> more than one.

Correct.

> 
> Unless --finish/--pivot is passed to blockcopy or until
> --abort/--pivot/--async is passed to blockjob, the original disks
> (before blockcopy started) and the new disk created by blockcopy are
> both mirrored.
> 
> Only --pivot makes use of the new disk. So with --finish or --abort, we
> get a backup of a running guest. Nice! Except maybe that the backup
> doesn't include the memory state.

Indeed, sounds like room for a future addition to libvirt, if qemu 1.5
gives us the additional hooks that I'd like to have.  In particular,
there is talk on the upstream qemu list about adding a blockbackup
operation that would make capturing memory state and starting a backup
job easier to manage than the current approach of starting a mirroring
job, then capturing memory state and ending the mirroring job.

> 
> In order to include the memory state to the backup, I guess the
> pause/resume is inevitable:
> 
>   virsh dumpxml --security-info dom > dom.xml
>   virsh undefine dom
>   virsh blockcopy dom vda /path/to/backup-vda
>   polling loop - check periodically until 'virsh blockjob dom vda'
>   shows 100% completion
>   virsh suspend dom
>   virsh save dom /path/to/memory-backup --running
>   virsh blockjob dom vda --abort
>   virsh resume dom
>   virsh define dom.xml

A live-migration solution would have less downtime, but potentially take
up more disk space.  Again, there is talk on the upstream qemu list
about how to optimize the amount of disk space taken by a live migration
to a seekable file.

> 
> 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.

> 
> I would also add a "sync" command just after the first command as a
> safety mesure to ensure the xml is kept on disk.

Again, if libvirt can be improved to do better external snapshot
management, a sync of the xml/memory state file should be part of this
effort.

> 
> 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.

> 
> 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.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
libvirt-users mailing list
libvirt-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvirt-users

[Index of Archives]     [Virt Tools]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]

  Powered by Linux