On Jan 12, 2007, at 11:09 PM, Tim Post wrote:
On Sat, 2007-01-13 at 11:39 +0530, Ligesh wrote:
On Sat, Jan 13, 2007 at 12:57:04AM +0800, Tim Post wrote:
Take backup of only these directories.
/etc
/var
/home
/usr/local
The same effect can be better achieved by taking an incremental
backup relative to the OSimage
with which the vm was built. So full backup is taken not per VM,
but rather PER Distro or PER osimage.
I am working on a solution using the concept of hard links as
used by rsnapshot. IN that case, we will
just take a full backup of the distro, and then use rsync to
honour hard links and break them if it encounters
a new version. That would mean that the name of the OSimage should
be kept in the config file, but that can be
done as a comment.
Not a bad idea, actually, and I was looking at using something similar
to the database that slocate uses to speed this up. This avoids having
to keep the original image mounted, and lets you update a change to
that
image to many places easily.
Then (as you suggest) an incremental backup based on whats different
than in the original template.
See, with VM we can always go for hard science. :-)
Not quite, but close.
I have always been scared of special cases. In the provider
scenario with large number of identical virtual machines,
it could lead to very large space saving, and yet, you get 100%
consistent backup.
That would be cool. Being able to restore one of several dated backups
for any VM would be ideal, as some people need to revert to
yesterday's
data, or last week's .. or a combination of the two.
If a VM is compromised and defaced, and 20 minutes later a new
snapshot
is taken.. then the backup is useless. Keeping dated backups with a
selectable retention time per VM would be the ideal goal :)
Consider using Amazon S3.
We've been using them for backups at Engine Yard. They're very
inexpensive, particularly so once you get the data inside.
Of course, you'll need big pipes to them if you're going to store a
lot of data.
We send over tar.bz2.pgp files.
--
-- Tom Mornini, CTO
-- Engine Yard, Ruby on Rails Hosting
-- Reliability, Ease of Use, Scalability
-- (866) 518-YARD (9273)
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home