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 |
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
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |