On Tue, Apr 7, 2009 at 4:12 PM, Kevin Fox <Kevin.Fox@xxxxxxx> wrote:
> So, in a single kernel (2.6.29+), lvm can tell the file system using the
> block device to freeze so it can take its snapshot, and then tell it to
> unfreeze. How hard would this be to extend this so that an LVM sitting
> in Dom0 could forward the freeze calls to DomU? Say, through the virtual
> block devices. You could then run your backups in Dom0 instead of every
> DomU. This would save you on per client licensing fees.
AFAICT, it has nothing to do with the block device. it's a new
feature that some filesystems might choose to implement, to establish
a point in time where the filesystem is safely snapshottable without
preserving RAM state.
XFS has had this feature (and some extra bells/whistles) for years; i
don't know if any non-SGI backup system uses it.
in any case, if you want it to be initiated on Dom0, it has to signal
the DomU to do all the freezing. also, it might not flush caches to
the blockdevice, since it might assume that the snapshot is done over
the cache layer (ie. by LVM in the same machine, not the Dom0 'beneath
it').
>> 2: it does nothing about complex applications with their own caches
>> and file structures: IOW, databases. if you get an 'in VM' snapshot
>> capability, you still have to flush caches and suspend operations for
>> the snapshot.
>
> A lot of backup systems I've seen tough, largely just save the files, or
> ignore them if they are written while saving. They don't bother to flush
> caches and suspend. It doesn't work for everything (databases), but for
> most applications it is fine. One example use case would be each users
> desktop session gets a virtual machine. You could backup the users data
> without needing to have a backup client in the vm.
if you're willing to forgive databases and similar loads, a simple LVM
snapshot is more than enough. any current journal FS will easily
regain integrity.
heck, for desktop users' data just do rsync to a central location and
be done! (extra points if using rsnapshot to keep several 'snapshots')
--
Javier
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home