Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
> From: discuss-bounces+blu=nedharvey.com at blu.org [mailto:discuss- > bounces+blu=nedharvey.com at blu.org] 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 > $CURTIME > /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 | |
We also thank MIT for the use of their facilities. |