I have been using dump for over 20 years now and it has always been very reliable. In fact, it was because amanda uses dump that I felt comfortable enough to try it out in the first place.
Up until now I have been keeping track manually of what filesystems and dump levels I keep on what tapes. I occasionally make changes to the /dev directory or install named pipes (eg, hylafax) which if they are not restored properly will cause something to break. I don't think I can think of all the cases to test gnutar on, so I wouldn't know how to do an exhaustive test of gnutar. What was it exactly that the complaint was regarding dump? Dick > >... Things > >aren't going to be on the same inode (as they would be with dump) ... > > Not sure if I'm reading this right, but if you're implying that a > restore from a backup image created with "dump" will bring things back > with the same inode number, that's not right. The "restore" program > that goes along with "dump" is just a user level program with no magic. > It does normal file system "open" and "write" calls, then resets the > various attributes like modification time (again, with normal OS calls). > So files come back to whatever inode is handed out by the OS. > > >and I'm > >not sure about stuff like /dev -- it probably won't get that right. > > I'm not getting into this argument again (been there, done that :-), > but this was the very thing Dick was concerned about. I *thought* > the combination of the way Amanda runs GNU tar and extra features of > GNU tar itself brought most everything back properly. > > The important point here, of course, is that with **any** backup system > you should test, test, test and then test some more. Amanda+gtar will > either do what you want or it won't. If it won't, figure out what you > need and adjust the procedures until you're covered. > > >Joshua Baker-LePain > > John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED] >
