Re: [Xen-users] Backup domU

[Andrew McGlashan <andrew.mcglashan@xxxxxxxxxxxxxxxxxxxxx>]

Hi,

Simon Hobson wrote:
> Kalil Costa - Brasilsite wrote:
>
> > I need to know which way to backup domU to restore these to another 
> > server if i've problem with this machine.
> There are many ways, all with their pros and cons.
True.

> One suggestion given here in the past was to send a signal (with an xm 
> command IIRC) to the guest (assuming guest with Xen support included) to 
> tell the guest to sync it's unwritten buffers to disk. He then did a 
> snapshot live via LVM.
Interesting, but still not clean enough for me.

> Upside - no downtime on guest. Downside, your backups are of a mounted 
> filesystem with open files, partially written files, whatever. Getting 
> the guest to sync first reduces the impact so it's not quite the same as 
> the backup being analogous to what you'd find on disk after pulling the 
> power cord on a real machine.
> The backup is also on the same disks as the live system.
No, it is not on the same disk [as already mentioned] -- actually, rsync 
is used with the lvm snapshot and better still it uses rsnapshot to have 
historical versions -- many restore points.  Then the rsanpshot is 
rsynced off-site with again, you guessed it, rsnapshot using rsync.
It's complicated and works very well, but the downtime is so minimal to 
me that it isn't an issue.  It could probably be expanded upon using 
multi-mysql master or similar, then shutting down one of the masters, 
but not shutting down the main server instance.
> As a variation, you could pause the guest and snapshot the LVM volumes 
> **PLUS** save the guest saved state file. If you need to restore then 
> the guest would unpause in the same state as when it was paused.
Interesting too, but you still have a "running" system backup, although 
it might be fine doing that.
> At work I've setup a system where I have a VM dedicated just to holding 
> backups of the other machines - each of which uses rsync to update a 
> backup copy of itself on the backup server (the server runs rsync in 
> server mode). Thus I have a server holding a complete image of each of 
> my servers at the point they last backed up. Should a host go down, I 
> can move the guests to another host by creating volumes for them and 
> using rsync to pull their files back (mount the guest filesystems on the 
> host, use rsync on the host to pull the files, unmount the filesystems 
> and start the guest).
> Of course, once you are using rsync, then it doesnt' matter whether the 
> destination is on the same host, another host in the same rack, or half 
> way round the world - as long as you have enough bandwidth.
The only issue with rsync with rsnapshot from what I can see, is for 
very large files that change frequently.  You might end up having loads 
of copies of these large files and that would be painful in terms of 
storage and transfer.  Take a 2TB Oracle datafile for instance; don't 
want to touch that right now with this method, but Oracle has other 
backup methods anyway .....
> On my backup machine I then copy the copies to create various levels of 
> historical backups. Again there are various ways of doing this, I 
> settled on StoreBackup which if you disable compression creates full 
> copies which you can just navigate into and use your normal unix/linux 
> tools to access files*. It saves space by hard-linking identical files 
> so it's fairly efficient.
Sounds exactly like rsnapshot does.  Get the flags right for rsync and 
you don't need to re-invent anything.  I'm also selectively using 
.rsync-filter as well for files / dirs that I don't require such full 
backups of.
This is an interesting feature of StoreBackup:

"recognizes when files have been copied, moved or renamed and does not 
waste time or space to duplicate the backup of such files"
I'm considering these ideas too, it would help with maildir files that 
only change the dir they live in or the flags at the end of the file 
name.  Duplicates .... hmmm, another whole area, md5 every file being 
backed up, check if you have the md5 on record -- then binary compare 
the two files and if they really are absolutely identical, hard link 
them and only keep one copy.  But lots more work for the backup job / 
tool to consider.
> * Just the other day I found this useful as I wanted to find out when a 
> DNS record had changed. I was able to grep 
> <something>/*/var/named/zones/<somezonefile> for the name in question 
> and find out that it changed about a month ago - yes no-one had noticed 
> a service was broken !
Yep, can do that fine with rsnapshot backups too.  See all versions kept 
of a file then vim -d any variants that are interesting.
--
Kind Regards
AndrewM

Andrew McGlashan
Broadband Solutions now including VoIP


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