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

[Xen-users] Block level domU backup


  • To: xen-users@xxxxxxxxxxxxxxxxxxx
  • From: "Agent Rooker" <agentrooker@xxxxxxxxx>
  • Date: Tue, 28 Oct 2008 12:49:18 -0500
  • Delivery-date: Tue, 28 Oct 2008 10:50:40 -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=SMD0/MyxveqyGMrH5qmjtJj0sJF8hdR/slzFihVRwAzyLFEL84PrZbABL/ac2gHua2 I5zD5w04i+tYztOW0xz1tjams2XXVdcNqFn0Np5hejHda4ibEGuBu7uBtxRAxP/AOaeJ FNv59pwT+SKJUMmgdgICeNE0ifBwBPsVEPKGc=
  • List-id: Xen user discussion <xen-users.lists.xensource.com>

I'm writing a bash script to do a block-level backup of my LVM backed
xen domUs from the current xen-server to a backup xen-server.  I'm
using LVM snapshots in this script, and I'm aware that there is a risk
when using snapshots that uncommited data may be lost.  However, as I
understand it, when saving a xen domain to restore later, a checkpoint
file is created that contains a copy of everything in the domU's RAM
so that the domU can be restored later.

The idea behind my script is to pause the domU and save a checkpoint
file, then create LVM snapshots of the important volumes, then restore
the domU.  This would allow me to restore the domU at a later time on
another system without losing any data (because uncommitted data would
be in RAM).  I understand that this will cause some downtime, but
before I thought of this, I was being asked to shut down the domU
completely before creating the lvm snapshots.  Anyway, I would like to
open this up for comments and criticism.

Here is what I'm doing.  I cut out all the boring comments and error
checking.  I think the variable names should be pretty
self-explanatory, but if anyone wants me to, I can post the whole
thing.

xm save $XENNAME $CHECKPATH
lvcreate --snapshot --size $LVPATH_SIZE --name $LVPATH_SNAP $LVPATH
lvcreate --snapshot --size $LVPATH_SWAP_SIZE --name $LVPATH_SWAP_SNAP
$LVPATH_SWAP
xm restore $CHECKPATH
blocksync.py $LVPATH_SWAP_SNAP $BACKUPSERVER $LVPATH_SWAP
lvremove -f $LVPATH_SWAP_SNAP
blocksync.py $LVPATH_SNAP $BACKUPSERVER $LVPATH
lvremove -f $LVPATH_SNAP
rsync -a $CHECKPATH $BACKUPSERVER:$CHECKPATH
rsync -a $CONFPATH $BACKUPSERVER:$CONFPATH

Oh yeah, this uses the blocksync.py script that I got from
<http://www.bouncybouncy.net/ramblings/posts/xen_live_migration_without_shared_storage/>.
 It simply syncs block devices between two computers.  This means that
the first backup will be pretty slow and network intensive, but
subsequent backups should be pretty snappy.

Let me know what you think or if there is something I've overlooked.  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®.