Amanda-Users

Re: LVM snapshots

2006-07-07 17:18:48
Subject: Re: LVM snapshots
From: Paul Bijnens <paul.bijnens AT xplanation DOT com>
To: amanda-users AT amanda DOT org
Date: Fri, 07 Jul 2006 23:13:44 +0200
Jon LaBadie schreef:
On Fri, Jul 07, 2006 at 12:47:15PM -0600, Michael Loftis wrote:

Does anyone use or have knowledge of using LVM snapshots with Amanda
backups?

...
I'm just wondering what happens during the freeze - how freezing "all
activity to and from the filesystem to reduce the risk of problems"
affects the system?  One would imagine that disk writes are somehow
queued up and complete when the file system is unfreezed again?
It's only stopped long enough to make the bitmap table. After that it's Copy On Write. Meaning a snapshot is free until the 'original' starts to differ then the snapshot starts to take up space because you have to make copies of the original blocks for the snapshot once they start to change.


Apologies for an OT comments;  This seems like an ineffecient way to
implement snapshots.  Granted the inode for a changed file has to be
copied, but I don't see why the data blocks do.  If I'm changing a
data block, I have to write that block to disk anyway.  Whether I
overwrite the original block, or a newly allocated one doesn't matter.
If the original was just left in place, the snapshot could continue
to use it.  Its copied inode would already have the pointers to the
original blocks.  Otherwise you have to copy the inode, allocate a
new block for the copy of the original block, change the copied inode
to point to the copied block, and still have to write the changed data
for the active file.

There are two approaches (maybe even many more -- I'm not the
specialist here).

One approach is to let the snapshot mechanism understand the filesystem
and work on that level. That is how xfs and solaris ufs snapshots seem
to work.

The other approach is a layer deeper: on the logical volume manager.
This implementation is not interested in where the inodes are located
or how directories and datablocks are layed out on disk. The LVM just
manages large blocks.  The LVM2 snapshots in linux work on this layer.

Using method 1, you can probably get more optimized (quicker, using less
diskspace).  Using method 2 is more general, and is is independent of
the filesystems on it.  In my test setup I even managed to make a
snapshots of a vfat filesystem.  I never noticed any significant
performance loss with LVM2 snapshots, but I did not really made some
hard benchmarks either -- just look and feel...

I'll post my script that I use for LVM2 snapshots with Amanda backups
in the not too distant future  (I'm not at work).  Some patience...


--
Paul Bijnens, Xplanation                            Tel  +32 16 397.511
Technologielaan 21 bus 2, B-3001 Leuven, BELGIUM    Fax  +32 16 397.512
http://www.xplanation.com/          email:  Paul.Bijnens AT xplanation DOT com
***********************************************************************
* I think I've got the hang of it now:  exit, ^D, ^C, ^\, ^Z, ^Q, F6, *
* quit,  ZZ, :q, :q!,  M-Z, ^X^C,  logoff, logout, close, bye,  /bye, *
* stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt,  abort,  hangup, *
* PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e,  kill -1 $$,  shutdown, *
* kill -9 1,  Alt-F4,  Ctrl-Alt-Del,  AltGr-NumLock,  Stop-A,  ...    *
* ...  "Are you sure?"  ...   YES   ...   Phew ...   I'm out          *
***********************************************************************

<Prev in Thread] Current Thread [Next in Thread>