On Thu, Mar 15, 2007 at 09:03:19AM +0700, Fajar A. Nugraha wrote:
> Ligesh wrote:
> > But LVM data corruption happens at the file system level, and has to be
> > recovered first using e2fsck, before mysql can even have a go at it fixing
> > the rest of the problems.
> >
> >
> Aah, I think this is the source of our different point of view. I was
> refering to journaling filesystems (ext3, reiserfs, etc) where the
> kernel will automatically replay last journal, so (on most cases) no
> MANUAL fsck is necessary.
Are you backing up the entire LVM image as a single file? You are mounting
and tarring the contents right? If you are backing the LVM image as a single
entity, then yes, you can even get perfect backup, if you simultaneously do a
xm save, and keep the ram too. In fact, that's a nice way to do perfect backup.
Take an lvm snapshot and also save the ram image, and you can restore the state
perfectly.
But in normal circumstances, what we do is, take an LVM snapshot, then mount
it, and then tar/rsync the contents. That can be hazardous. Anyway, now that I
have given it some consideration, it appears, you can indeed run e2fsck on the
LVM snapshot, and get a consistent file system, albeit without the application
buffers in the ram.
So I think
lvm2 snapshot
e2fsck -f -y /dev/lvm-snapshot
mount -o ro /dev/lvm-snapshot /mnt/backup
rsync /mnt/backup
Is indeed a solution for a reliable backing up--you will loose the application
buffers, but that's actually alright for small vpses.
Any comments?
Thanks.
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home