On Sat, 26 Jan 2002 at 10:56am, John R. Jackson wrote > >... 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.
Yeah, that's what I was saying, and apparently I was talking out of my a$$ -- sorry about that. I thought I recalled a discussion about dump reading at a lower level than tar (now that I think about it, maybe it was referncing xfsdump/tar vs. EAs), and went from there. You know, they say that the memory is the second thing to go. The first is, uh, something else. > >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. Once again, I sit corrected. > 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. > Amen. Thanks for setting me straight, John. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
