Agent Rooker wrote:
> On Tue, Oct 28, 2008 at 3:34 PM, Javier Guerra <javier@xxxxxxxxxxx> wrote:
>
>> the point of pausing the DomU is to get hold of a snapshot of memory
>> state, as well as the block device(s).
>> doesn't sound like something worthy to replace real backups; but might
>> buy you much lower restore times, if you have the capacity to do both.
>>
>> --
>> Javier
>>
>>
>
> That's what I'm thinking, anyway. As I said in a previous message in
> this thread, "...we're also doing domU level backups with NetBackup."
>
I assume that in domU you also use some kind of snapshot (lvm or
whatever) so that NetBackup sees consistent files (e.g. all files backed
up are from the same time, not changing in the middle of backup process)?
If you do, then I assume:
a. you can tolerate whatever corruption that may possibly happen using
that method (i.e. the same kind of corruption you can get if you yank
the power cord), or
b. your application can recover from [a] (e.g. Using Innodb instead of
MyIsam for MySQL)
With that in mind, it should be easier to simply use snapshot without
the need of xm save/restore. It will save some domU "downtime" (the time
needed to save and restore domU).
Another thing to consider, when the question "how to backup domU" arised
on this list in the past (and it comes up quite often, search the list
archive) I'd generally reply "try using zfs snapshot". Which means :
- for backup in domU, you either need an opensolaris or zfs-fuse/linux
running on domU
- for backup in dom0, you need opensolaris dom0 (using zfs volume),
whatever the OS/fs running on domU.
Another alternative is to have an opensolaris server exporting zfs
volumes via iscsi, have dom0/domU import it, and do all backups on the
storage server.
The benefit is that :
- zfs snapshot is much faster than lvm snapshot (when using lvm snapshot
disk writes will be doubled : to the original lv and the snapshot lv)
- subsequent zfs snapshot is much faster since zfs tracks changes
between snapshots internally (compared to rsync/blocksync which needs to
read all files/blocks and compare their stats/checksum, thus eating lots
of disk read i/o during backup process)
> An alternative solution would be to bring the domUs down for a cold
> block-level backup each night, but that is just a little more downtime
> than I would like.
>
>
>
Your current backup solution uses lots of disk I/O, which might result
in severe performance degradation during backup. Depending on your
requirements, this might be okay, but you'll get bettere performance
with zfs.
Regards,
Fajar
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home