dumping active file systems

[George Robbins]

In article <384 at vela.acs.oakland.edu> schemers at vela.acs.oakland.edu (Roland Schemers III) writes:
> Hello! I have a question about using 'dump'. How dangerious is it to
> dump an active file system? That is, dumping a file system that is
> mounted, and while the system is in multi-user mode? I have gotten
> various replies from DEC, ranging from "It might corrupt the whole dump",
> or "Only the active files will be messed up".
> 
> For a monthly or weekly dump I see no problem with bringing the system
> down to single user, but every day to do incrementals seems a bit
> drastic. 

There's no really good answer to this question.  If you want dump that
are guarenteed to be restorable without hassle, do *all* of the either
standalone or with the filesystem unmounted.

Many sites compromise by doing the critical (level 0, weekly) dumps in
standalone mode and doing the daily incrementals while the system is up,
ideally during a low activity time period.

This approach means that you can get the bulk of the files back without
difficulty, but you may have to dick around with multiple daily tapes
and/or partial restores to get everything exactly current.  Most of your
user request for file restores will come from a recent daily incremental
dump and restoring individual files always seems to work.

There are "improved" versions of dump floating around that are supposed
to be more rugged in terms of working on active filesystems, however I
haven't heard of one ported to Ultrix.

You can also do something like getting an 8mm drive and doing daily full
tar dumps in the background.  The tar format is stupid and less prone to
the kind of problems that dump/restore encounters when things change during
the dump.  The Gnu version of tar also has provisions for doing incremental
tar dumps, which might give you the best of both worlds.

For System V fanatics, cpio is just about as stupid as tar in this respect. 8-)

-- 
George Robbins - now working for,     uucp:   {uunet|pyramid|rutgers}!cbmvax!grr
but no way officially representing:   domain: grr at cbmvax.commodore.com
Commodore, Engineering Department     phone:  215-431-9349 (only by moonlite)