Path: utzoo!attcan!uunet!nih-csl!lhc!ncifcrf!haven!aplcen!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!swrinde!ucsd!ames!dftsrv!jagmac2.gsfc.nasa.gov!jim From: jim@jagmac2.gsfc.nasa.gov (Jim Jagielski) Newsgroups: comp.unix.aux Subject: Re: Backup & Misc Message-ID: <3576@dftsrv.gsfc.nasa.gov> Date: 9 Oct 90 10:48:54 GMT References: <1990Oct5.035047.32209@uokmax.ecn.uoknor.edu> <3563@dftsrv.gsfc.nasa.gov> <1990Oct5.212803.11873@servalan.uucp> Sender: news@dftsrv.gsfc.nasa.gov Reply-To: jim@jagmac2.gsfc.nasa.gov (Jim Jagielski) Organization: NASA/Goddard Space Flight Center Lines: 40 In article <1990Oct5.212803.11873@servalan.uucp> rmtodd@servalan.uucp (Richard Todd) writes: >jim@jagmac2.gsfc.nasa.gov (Jim Jagielski) writes: > >>As I recall, dump.bsd and restore (when used in the "full" mode) also copy >>the SuperBlock information, so if a restore -r (or whatever the flag is, I >>don't use dump/restore) is done, SuperBlock info is also restored. One of the >>upshots of this is that your new filesystem must be the same size as the old >>one. > > Nope, I'm sorry, you didn't Beat the Reaper. > > Restore is smart enough to automatically handle restoring onto >filesystems with different numbers of inodes or disk blocks I seem to recall somewhere in the documentation for 1.1, that one of the considerations when using dump and restore was that the restored backup had to be the same size file system that was originally dumped. In other words, if your file system was orginally 40 megs and you wanted to "increase" it to 80 megs, the documentation suggested NOT using dump/restore since the file system sizes were different and it would not work. (they also mentioned in there information about the SB being copied also) Now I don't know if this is true or not, but it WAS in the 1.1 documentation set... I recall this because around that time I had upgraded from an 80 MB disk to a 170 one and wanted to: 1) increase the root FS size from 55MB (which was about the size of 1.1) to 70MB as well as 2) make /usr it's own FS. Now maybe the documentation was wrong, or maybe dump/restore was changed/fixed to circumvent this (heck, I remember the days of nightly "dd" backups!) under 2.0. I simply felt the need to relay what I read, even if it IS/WAS wrong :) -- ======================================================================= #include =:^) Jim Jagielski NASA/GSFC, Code 711.1 jim@jagmac2.gsfc.nasa.gov Greenbelt, MD 20771 "Kilimanjaro is a pretty tricky climb. Most of it's up, until you reach the very, very top, and then it tends to slope away rather sharply."