[Discuss] Backing up LVM partitions using snapshots

Mark Woodward markw at mohawksoft.com
Mon Dec 12 12:57:27 EST 2011


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 gmail.com> wrote:

>On Sun, Dec 11, 2011 at 9:15 PM, <markw at mohawksoft.com> 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.org
>http://lists.blu.org/mailman/listinfo/discuss


More information about the Discuss mailing list