dump/restore

[Griff Smith]

In article <262 at mpx2.UUCP>, erik at mpx2.UUCP (Erik Murrey) writes:
> Dump/restore is very quick, and it backs up everything, but I have
> a few questions:   It seems to dump the entire filesystem, including
> the superblock/inode dumps.

It dumps most of the inode information so it can restore file
attributes.  It also dumps a block map so `holes' can be restored
in the right places.

> It also seems to me that it dumps
> disk blocks in order of the disk itself, rather than the order of the
> file.  This means that restoring a filesystem will *not* reduce
> the fragmentation.

Which version of `restore' are you using?  Blocks are dumped in file
order.  The 4.[23]BSD version of restore puts files into a directory
tree using standard `write' and `seek' operations.  Fragmentation IS
reduced, but the original fragmentation seems to be insignificant on
the disks I have seen.

> (Which is often why I backup/restore in the first place.)

Are you using something other than the BSD fast file system?  The
last time I saw studies of the fragmentation of file systems that use
allocation bit-tables instead of free lists, the fragmentation reached
a steady state in about two weeks.  This is much shorter than the
pay-back time for a full dump/restore.

> Does it also require the exact same filesystem to by restored on?

No.  Unless you are talking about 4.1BSD.  I never used `restor'.

> If this is so, then I can't use dump/restore to expand a full filesystem.

No problem.  You can also use `restore' to recover selected trees in a
filesystem.

> The docs I have for dump/restore don't explain details like
> this to me.  Please fill me in!

Do you have `dump(8)' and `restore(8)' in the (Berkeley) UNIX System
Manager's Manual?

> ---
> Erik Murrey
> MPX Data Systems, Inc.
> erik at mpx1.UUCP
> ...!{bpa,spl1,cbmvax,vu-vlsi}!mpx1!erik
-- 
Griff Smith	AT&T (Bell Laboratories), Murray Hill
Phone:		1-201-582-7736
UUCP:		{most AT&T sites}!ulysses!ggs
Internet:	ggs at ulysses.att.com