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

[Xen-users] Using dd and gzip to backup LVM backed domUs


  • To: xen-users@xxxxxxxxxxxxxxxxxxx
  • From: "Agent Rooker" <agentrooker@xxxxxxxxx>
  • Date: Fri, 17 Oct 2008 16:30:04 -0500
  • Delivery-date: Fri, 17 Oct 2008 14:30:50 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=IHAGaqDoJGQ/weuVEI7o9N+EexQ1hU3iVrLxxtPkqsttrSKpurjVWlS4Fhm2IBYGk2 vYZdvsXeiSgYMTpP7ljflpgSfxxid7E9KkRLehvB5/PSdWLR0+TnMCpq+QMS0SNX3050 7Kz/wy8qsDQmBGm73HIBWecgUqCCgnIVo6sos=
  • List-id: Xen user discussion <xen-users.lists.xensource.com>

I'm trying to come up with the best way to backup my xen domUs.  I
have a logical volume containing an ext3 root filesystem for each
domU.  Basically, I want to back up the whole filesystem in such a way
that I could restore the image on another xen server in the case of
hardware failure.   My idea so far is to back up the logical volume
with a command of this form (from the dom0):

# dd if=/dev/VolGroup00/XenImage bs=64k | gzip >
/mnt/archive/XenImage_20081017.gz

And to restore using a command of this form:

# zcat /mnt/archive/XenImage_20081017.gz | dd of=/dev/VolGroup00/XenImage bs=64k

I think this should work in a pinch but there are at least two issues
that I'd like to sort out.

First, one of the reasons I'm using gzip is because I have a lot of
free space on my domU logical volume, and I want to compress all that
unused space down to (almost) nothing when I make my backup image.  At
first, this unused space would be all zeros and would therefore
compress very nicely.  But as I understand it, if a file is deleted,
the data remains on the block device.  The blocks are no longer
allocated by the filesystem, but when I try to compress them, they
won't compress as well as the unused blocks that are all zeros.  What
I foresee is the compressed image growing in size even though the
space used by the domU's filesystem remains relatively steady.  One
idea would be to periodically zero out the unused blocks by filling up
the volume with a file of all zeros with something like this:

# dd if=/dev/zero of=foo ; rm foo

But I think it would be a bad idea to do this on a mounted root
filesystem.  So am I right to worry about this, and if so, what should
I do about it?

The other problem with my backup method is that it only works if the
domU is shut down.  If the domU is running, the filesystem is backed
up in an inconsistent state.  I've thought about using LVM snapshots
for hot backups, but if I take a backup from a snapshot of a running
system, would I be able to start up my domU from that volume without
losing data?  Or would I have to do something like save a checkpoint
(using 'xm save'), make a snapshot of the logical volume, restore the
DomU, dd the snapshot, and then remove the snapshot?

Also, any other ideas for doing what I'm trying to do would also be appreciated.

Thanks,

--
Agent Rooker

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.