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

I'll take the blame for not explaining it well. You aren't getting what I'm saying. The idea of "incremental" is dead. you look at your volume as a catalog of blocks. You create a storage system of compressed blocks and create a system for storing block lists. Even after so called incremental backup, you still have a full backup. 

Richard Pieri <richard.pieri at> wrote:

>On Sun, Dec 11, 2011 at 9:15 PM, <markw at> wrote:
>> Now, you make a HUGE (5%) change to your disk, you back-up 3 million
>> changed blocks! You overlay those new blocks on to a list of old blocks
>> and create a new list for the backup. Even though you've done an
>> incremental backup, you still have a "whole" representation of the volume.
>I make that 5% change and do an incremental backup.  Then I make a
>different 5% change and do another incremental backup.  Here I have two
>reasonable choices: I can calculate delta against the most recent
>incremental backup or I can calculate against the most recent full backup.
>The first option is the more efficient as far as capacity goes but is
>vulnerable to loss.  If I lose the first incremental and have to do a
>restore then I have everything from the full and everything from the second
>incremental but there is a 5% "hole" of changes that I cannot restore.
> That's 3 million blocks of data that my second 3 million blocks may depend
>on.  One specific example is the file system superblocks which are pointing
>to inode data that isn't there.  My file system is in an inconsistent
>state.  You have not addressed this point.
>The second option is resistent to loss of incremental backups but requires
>successively more capacity for each day's incremental backups with
>cumulative deltas potentially exceeding the size of the base volume.
>Sorry, Mark.  All that I see here is a complex, dodgy technical solution
>looking for a problem that doesn't exist.
>Discuss mailing list
>Discuss at

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 /