zemon@felix.UUCP (02/10/88)
Larry W. Virden (lwv@n8emr.UUCP) writes: > Hi there! I have seen the 3-4 paragraphs or so in the supplimental or is > that the administrative manual which tells me that if I do dumps using > levels 3 2 5 4 ... I get a 'tower of hanoi' style dump. Unfortunately, > I am not sure a) what the level numbers mean, and b) in what order the > restores are supposed to be done. Since someone out there connected with The oblique reference to towers of Hanoi is one of the more rediculous examples of documentation that I have ever seen. It has been in the Unix manuals for years and apparently no one at DEC's technical writing department understands it either or they would have replaced it! :-) So here is my long explanation. Hope you find it helpful. Feel free to ask more questions. Start by assuming two goals for your backup procedure. 1) Dumps, which are performed daily (i.e., very frequently) should not take too long. 2) Restorations, which are performed infrequently, can take significantly longer. On the other hand, if you can still achieve #1 and avoid reading *all* of your backup tapes to do a restoration then you can save some time on those infrequent occasions when you do need to restore. You can achieve #1 by only backing up the files that have changed in the last day. The dump levels make this easy since they mean "dump all files which have changed since the previous dump with a LOWER dump level." In other words, if you type "dump 3 ..." then the dump program will look in /etc/dumpdates to determine when the most recent dump of level 0, 1, or 2 occured. Only the files which changed since the most recent of those three levels will be dumped this time. So you can dump one day's work at a time with the following sequence: Su M Tu W Th F Su M Tu W Th F Su M 0 1 2 3 4 5 6 7 8 9 0 1 ... You back everything up on Sunday (dump level 0 means backup everything). On Monday evening you back up the work done on Monday (and Sunday but who works on Sunday? :-) On Tuesday evening, dump looks for the next lower level dump from level 2 and finds a level 1 dump done on Monday so it picks up just the files changed on Tuesday. And so on. There are a couple of problems with this sequence, however. One is that if the disk crashes on the second Friday you must restore all ten of your tapes to get back to Thursday night. You would start with tape 0 and then read all the others in increasing order. Since restore is *much* slower than dump, you will be slinging tapes for a *long* time. The other problem is that work done on the second Friday is not backed up until later in the weekend. This gives a wider window between when the work was done and the backup is made and that means more time for gremlins to strike. You can reach a compromise by being willing to back up two days worth of work in an evening. Consider the following sequence, the infamous Towers of Hanoi: Su M Tu W Th F Su M Tu W Th F Su M 0 2 1 4 3 6 5 8 7 9 9 0 2 ... You start with a full dump on Sunday. On Monday you dump one day's worth of work. On Tuesday, dump looks for a previous dump with a level less than 1 and dumps all files changed since Sunday (since the 0 on Sunday is less than 1 but the 2 on Monday is not). On Wednesday, you dump all changes made since Tuesday (1 < 4). On Thursday, you again dump all the changes since Tuesday (1 < 3). And so on. Now if you have to restore on the second Friday, you only need to read half of your tapes. In order, they would be: 0 1 3 5 7 9 This sequence also gives you a bit of redundancy, although it is not intended to provide complete redundancy. Cheers, -- Art Zemon By Computer: ...!hplabs!felix!zemon By Air: Archer N33565 By Golly: moderator of comp.unix.ultrix
tankus@hsi.UUCP (Ed Tankus) (02/20/88)
Art Zemon gives a very detailed view of this procedure. However, such detail may not always be necessary nor practical. We have a lot of activity on 2 VAX's, consequently, many files are modified and many new files are created. We were faced with several problems. 1) Maximize the number of files dumped 2) Minimize the number of tapes used (no more than one per file system) 3) Provide plenty of redundancy in case a bad tape occurs. 4) Make it fast and easy to restore files. We have been using the following procedure with great success for about 2 years. M Tu W Th F VAX #1 1 1 1 2 1 0 VAX #2 1 1 1 1 2 0 Monday thru Wednesday we perform a level 1 dump of our normal files systems. The level 1 picks up all new or modified files since the last level 0, i.e., Thursday or Friday. No more than half a 2400' mag tape at 6250 bpi is ever used for a level 1. It's usally only about 25%, even by Wednesday. Thursday morning our first VAX is brought to single user and a level 2 dump performed on the normal filesystems. This picks up everything new or modified since the day before. A level 0 dump is performed immediately after the level 2 dumps are completed. The same scenario applies to Friday for the second VAX. This scenario provides alot of redundancy and a large safety net for us. Using this scheme, we could "theorhetically" lose the dump tapes (for VAX #2) for Monday thru Wednesday and still be back to business as usual quickly. How? Each level 1 refers back to the previous level 0. Each level 2 refers back to the previous level 1. VAX #2 0 | <- 1 (Mon) | <- 1 (Tue) | <- 1 (Wed) | <- 1 (Thu) | | <- 2 (Fri) | . . 0, etc. As the picture shows, given a system crash anytime after the level 2 dump, the only tapes that would be needed would be the previous level 0, the level 1 from Thusday, and the level 2 from Friday. Even if the PREVIOUS level 0 was bad, we simulate that tape be using a level 0 from TWO WEEKS previous and the associated level 1's and 2 's. Because of the size of our filesystems, we reuse our level 1's and 2's starting every 4th week. We rotate tape sets every week so that the two most recent set of level 0 dumps are always off-site. This same scheme should work for TK50's, though this level of redundancy may not be necessary for a MicroVAX. This isn't foolproof either. Just another way of doing things. Sorry for the length but I thought the explanation might save others some time. Cheers! -- Ed. Net : {uunet,ihnp4,noao,yale}!hsi!tankus Snail: Health Systems Int'l, 100 Broadway, New Haven, CT 06511 Bell : (203) 562-2101