Tom Limoncelli wrote: > Which reminds me... > > The BSD man page for dump recommends a Towers of Nanoi algorithm. To > be honest, I never really understood it. However, the page was > written by very smart people and it may be better than 9,8,7,6,5,4,... > or 1,2,3,4,5,... > > o After a level 0, dumps of active file systems (file systems > with files that change, depending on your partition layout some > file systems may contain only data that does not change) are > taken on a daily basis, using a modified Tower of Hanoi algo- > rithm, with this sequence of dump levels: > > 3 2 5 4 7 6 9 8 9 9 ... > > For the daily dumps, it should be possible to use a fixed num- > ber of tapes for each day, used on a weekly basis. Each week, > a level 1 dump is taken, and the daily Hanoi sequence repeats > beginning with 3. For weekly dumps, another fixed set of tapes > per dumped file system is used, also on a cyclical basis.
cute mathematically and from a computer science programming point of view, but not practical or useful for most real world backup situations. It doesn't minimize cost. It doesn't do a number of other things backup admins might want to do. It does (and only does) maximize the length of the mathematical sequence corresponding to the tape rotation for a given number of tapes. Thus, the largest number of days possible before your tape rotation sequence repeats and overwrites the last tape. A sort of mathematical oddity. It puts a very uneven usage load and wear on tapes, with some tapes being used very frequently and others being used very infrequently. And it leaves progressively larger gaps in file coverage as it goes back in time. You can recover from any day in the past that is a power of 2 days ago, up to 2^(n-1), where n is the number of tapes. However, if the day is not a power of 2, you may be out of luck. For example, if a file was put on the system 7 days ago and then damaged in an edit 5 days ago, it is no longer on any tape. It's in the gap between 8 days ago and 4 days ago. It also gets way too complicated to shuffle the tapes without some kind of computer automation of a tape library. If you are interested in more detail or commentary, google "tower of hanoi backup rotation", or go to wikipedia, or another link I found following that. http://en.wikipedia.org/wiki/Backup_rotation_scheme http://sarab.sourceforge.net/faq.php -- which lead to an interesting paper: http://www.sans.org/rr/papers/56/305.pdf One situation where it might be useful is if you have an essentially stable system and are worried about the possibility of getting hacked. You want a clean backup to recover from. Hacked. Darn. Go back 8 days. Still hacked. OK, go back 32 days. Still hacked. Bummer. Go back 64 days. And so on, until you have a clean system or run out of tapes. One would hope however, that if you have the wherewithal to implement tower of hanoi backup rotation, you would also be more vigilant about watching logs and other things to detect hacking, as well as spending the time to secure the system. It might also make sense to make benchmark archival backups at points of development where you have built or updated the system. -- --------------- Chris Hoogendyk - O__ ---- Systems Administrator c/ /'_ --- Biology & Geology Departments (*) \(*) -- 140 Morrill Science Center ~~~~~~~~~~ - University of Massachusetts, Amherst <[email protected]> --------------- Erdös 4 _______________________________________________ Tech mailing list [email protected] http://lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
