Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] Backing up LVM partitions using snapshots

> From: at [mailto:discuss-
> at] On Behalf Of Mark Woodward
> example:
> PREVTIME=13234915
> CURRTIME=$(now)
> lvrename /dev/lvm/mysnap /dev/lvm/mysnap.old
> lvcreate -s -c 64 -L1G -nmysnap /dev/lvm/myvol
> bcebackup -C /dev/mapper/lvm-mysnap-old.cow -P $PREVTIME -t
> /dev/lvm/mysnap
> lvremove /dev/lvm/mysnap.old

This is a limitation people should be aware of - and if they're able to find
numbers that works for them and their dataset, then great.  ;-)  In the
above example, you've reserved 1G to the snapshot.  If the amount of
volatile data in the mounted filesystem exceeds 1G, then the snapshot
disappears, so the next time, you won't be able to do any more incrementals,
you'll have to start fresh again with a new full block level image.  If you
increase to a huge number, say 1T, then you'll be wasting 1T of disk space
reserved "just in case" the snapshot grows that large.  

If the snapshot disappears in the middle of an incremental send - Well then,
the receiving side will have received a corrupt incremental.  Hopefully
you're able to rollback the receiving side as if no incremental had ever
started.  Lest the receiving side be entirely destroyed.

Also, because your snapshots are taking place at the block level (filesystem
unaware) all block level changes are counted.  If somebody creates a random
file and then removes it, or if they delete, change, or restore a file, move
or copy, those blocks are still marked as "changed" even though they're no
longer used or referenced in the filesystem, or they've been restored back
to their original values.  During your incremental, those blocks will be
sent.  This means, depending on the end user's system usage patterns,
sometimes this snapshot backup mechanism will greatly outperform something
like "rsync," and sometimes something like "rsync" would greatly outperform
the snapshot backup mechanism.  It's important to understand your individual
usage characteristics, and make sure something like this is appropriate for
your usage patterns.

BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!

Boston Linux & Unix /