On Mon, Apr 12, 2010 at 09:25:52AM -0500, Javier Guerra Giraldez wrote:
> On Mon, Apr 12, 2010 at 4:01 AM, Pasi Kärkkäinen <pasik@xxxxxx> wrote:
> > You'll get fsck when you restore that kind of snapshot and start the guest.
> > And some applications might be in a bad state.
>
> even worse: if you mount the filesystem to perform the backup while
> the VM is suspended to disk (by xm save), it would automatically do a
> journal replay/revert/whatever. suppose it goes smoothly and you now
> have a consistent FS (usually it wil); now you resume the VM and....
> it would complain, most likely crash, and maybe corrupt the filesystem
>
Uh, that's why you take a SNAPSHOT of the disk before doing the backup,
and then do the backup from the snapshot!
You *don't* touch the original guest disk while it's paused/saved!!!
-- Pasi
> why? simple, you changed the filesystem (by mounting it) while it was
> sleeping. from the point of view of the VM, in a blink, and without
> any warning, several critical disk structures were changed and the're
> no longer consistent with the memory state.
>
> even if you mount the filesystem as R/O, most would perform a journal
> replay on mounting. there's usually an obscure mount option to block
> it, or you might set the block device as R/O, but then you don't have
> a consistent FS to backup. Better save the replay to a different
> medium, like a COW file, or an LVM R/W snapshot.
>
> and we're back at the beginning....
>
> and still it's not a full backup, since the guest didn't have any
> chance to flush it's buffers or userspace caches (like all DBs do)
>
>
>
> really, just do backups from inside the guest.
>
>
>
> --
> Javier
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home