dump(8), incremental backups, Tower of Hanoi sequence, don't get it

[Ilari Laitinen]

On Fri, Aug 19, 2005 at 04:22:20PM +0100, Alex Zbyslaw wrote:
> Ilari Laitinen wrote:
> 
> >Handbook reads dump(8) is the best backup program there is. So I am
> >giving it a try - only to find out that I don't understand at all the
> >meaning of that modified Tower of Hanoi algorithm descibed in the
> >manual page and elsewhere. The manual page says it is "an efficient
> >method of staggering incremental dumps to minimize the number of
> >tapes." I just don't get the picture here.
> >
> >So, could somebody please give an idiot-proof explanation why "3 2 5
> >4 7 6 9 8 9 9" is such a tape-number-minimizing dump level sequence
> >(with helpful examples, if at all possible)? How does it work?
> >
> >Am I relatively safe doing level 0 dump every two months and
> >increasing dump level for weekly backups like the following, given
> >two separate harddrives storing them?
> >
> >Date        Dump level
> >2005-09-01  0
> >2005-09-08  1
> >2005-09-15  2
> >...
> >2005-10-27  8
> >2005-11-03  0
> > 
> >
> No, your sequence is the worst possible.  If you have a crash on  
> 2005-10-27 then you will need to recover files from *every* dump  from 
> your last level 0.
> 
> A level 0 dumps everything. 
> 
> A level 1 everything since the last 0
> 
> a level 2, everything since the last 0 or 1
> 
> a level 3 everything since the last 0, 1 or 2
> 
> A level 4, everything since the last 0, 1, 2, or 3
> 
> etc.
> 
> The idea is is to make the numbers rise and fall to minimise the number 
> of backups needed to do a full restore.  Write yourself some sequences 
> and figure out for yourself which ones you would need for a full 
> backup.  Try to figure out for each backup whether the same files will 
> be dumped by a later backup.  They will, if a later backup number is 
> *lower*.
> 
> The algorithm your aiming to create is:
>    Start with a level 0 and ignore everything before.
>    from end of list, find the lowest number before you reach the 
> starting dump.  You'll need this backup.  Make it the new start of list.
>    from end of list, find the lowest number before you reach the 
> starting dump.  You'll need this backup.  Make it the new start of list.
>    etc.
> 
> E.g. Given 0 3 2 5 4 7 6 9
> 
> To restore everything you need the 0, 2, 4 and 6.  I.e. every second 
> dump.  You'll see that wherever you stop in that sequence, no more than 
> 3 backups are required to recover everything.

This pretty much cleared it up. Now that I read the manual page again,
enlightened, it seems quite easy to follow. Nice.

Using the algorithm above I get the following:

Sequence                Dumps needed
0 3                     0 3
0 3 2                   0 2
0 3 2 5                 0 2 5
0 3 2 5 4               0 2 4
0 3 2 5 4 7             0 2 4 7
0 3 2 5 4 7 6           0 2 4 6
0 3 2 5 4 7 6 9         0 2 4 6 9
0 3 2 5 4 7 6 9 8       0 2 4 6 8
0 3 2 5 4 7 6 9¹8 9²    0 2 4 6 8 9²

Am I doing this right? Every time a dump of level N is, eh, taken,
earlier tapes of level >N become obsolete and are free to go(*). In this
case, that happens every other time.

(*) Unless one would like to have those file versions around for a
    longer time, of course.

> clip
>
> I would also consider doing your backups daily, not weekly as your 
> example suggests.  The timing of full backups depends on how busy your 
> machine is.  Anything from weekly to quarterly.

Well, I am the only active user on this computer. And I know when there
is something to back up, so it will be a bit irregular in reality. If I
only surf the Net all weekend long, there is nothing to worry about. Or
if I am not physically around, the computer will have no power to mess
with.

Thank you, Alex, and others who replied (Jerry, Charles)! Now I only
have to buy those harddrives to start my new, shiny life with less fear
for random data loss. :)

Ilari

-- 
Ilari Laitinen - ilari.laitinen at iki.fi - http://iki.fi/ilari.laitinen/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20050819/4dd7b932/attachment.bin