Backup & Misc

[Richard Todd]

jim at 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, as long as
there are enough inodes/blocks to hold all the files and data that were
dumped originally.  You can restore onto a filesystem larger or smaller
than the original, as long as you have enough room to do it.  BSD-style
dump and restore have historically been the recommended way to save/restore
one's data when enlarging or shrinking a filesystem.  I've done it twice to
enlarge my /u partition at the expense of the MacOS partition on my
external drive, and at uokmax.ecn.uoknor.edu, the Univ. of Oklahoma's
Encore Multimax, when they need to shift some disk space from one
filesystem to another (which they typically do once a year or so, whenever
some FSes are real full and others are real empty or whenever they get a
new disk drive), they do full dump/restores to change filesystem sizes.  

>One can use cpio instead (assuming all will fit on 1 tape):

Well, aside from the fact that cpio doesn't save the access time, nor does
it correctly handle "holey" files such as are created by dbm, the original
poster was complaining that his filesystem *wouldn't* fit on one tape...  

--
Richard Todd	rmtodd at uokmax.ecn.uoknor.edu  rmtodd at chinet.chi.il.us
	rmtodd at servalan.uucp