On Thu, Jan 14, 2010 at 10:28 PM, Matthew Law <matt@xxxxxxxxxxxxxxxxxx> wrote:
> On Thu, January 14, 2010 2:22 pm, John Madden wrote:
>> Keep in mind that snapshots are not backups. There's no way that
>> snapshot would be consistent unless you were also doing something on the
>> domU to stop and flush all i/o and clear the scsi caches.
>
> Understood. Does suspending the domU do the job? I wanted to:
>
> - 'xm save' the domU
> - snapshot the domU's zvol on the storage server
> - 'xm restore' the domU
>
> this will give me a consistent snapshot, right? I know this means the
> domU will be unavailable for the duration of the snapshot. In my
> experience zfs snapshots are very quick indeed - much quicker than lvm.
>
> Is the only backup option for a running domU to run a conventional backup
> client within it, such as bacula?
I'd step back a bit and look at what kind of application are you
trying to back up.
If they're applications that can survive unclean shutdown or server
power outage (like most modern ACID database with journaling), then
most likely a simple zfs/lvm snapshot is enough. "xm suspend" or "xm
save" is similar to having suspend/hibernate on the server, not needed
if you already have zfs/lvm snapshot.
In some cases, taking zfs/lvm snapshot can actually be BETTER compared
to having backup software on domU.
For example: you run MySQL on domU with innodb storage engine, and
your backup software can only backup filesystem. In this scenario, if
you backup the innodb files directly from domU, and domU doesn't use
LVM, then most likely the backup will be useless as the files will not
be from the same time (i.e. some could be changed when the backup
process is running). However, if you do this from dom0 side with
zfs/lvm snapshot, the files will be consistent enough that MySQL
should be able to replay the journal and function normally afterwards.
--
Fajar
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home