Is dump dumb?

[Chris Torek]

>In article <170 at cui.UUCP> petitp at cui.UUCP (PETITPIERRE Dominique) asks:
>>- Why doesn't 'restore -t' give you the name of the file system stored
>>on the tape?

In article <23063 at labrea.Stanford.EDU> karish at denali.stanford.edu
(Chuck Karish) answers:
>Besides, what is the true name of a file system?  A block special device may
>have more than one link (name) in the root file system.

Approximately.  At any rate, this is indeed a problem.  It would be nice
for dump to store advisory information in the primary header (along with
the level and date).

>>- Is it true that restored files will have their modification time
>>always set to the time of the restore command?

No.  (The `ctime'---the inode change time---will be set to now, since
the file must be dumped again.)

>>In fact why doesn't dump use all the space available on the tape
>>without being told how much on the command line?

>Because there's no portable, reliable way to sense end of tape on
>UNIX machines.

Change `UNIX' to `some': some hardware refuses to detect EOT.

>>- Why can't dump work on active file systems? ...

>dump does work on active file systems; it's just not as reliable.

Correct.  Even if dump were redesigned not to use a four-pass approach,
a dump of an active file system would still be unreliable: `active'
means `changing'; `changing' means you cannot get a consistent picture
of the whole without looking at the whole simultaneously.  (And then
Einstein gets in the way. :-) )  The only way you could make dumping
an active file system completely reliable would be to freeze the file
system somehow.  With slightly different objectives, freezing parts
of the file system would suffice.

>If you run it on an active file system, the file system will be
>inconsistent when it is restored.  fsck will usually fix this ....

Not so: since restore (with an `e': none of this applies to the old
`restor' program) uses the file system interface, what it writes will
be self-consistent.  It simply may not be the same as what you thought
you saved.

>>- Why is dump always interactive?

>My feeling is that it's an important enough task that it merits the
>attention of a live operator.

I agree: if you want a reliable backup, you need something that can
handle unanticipated situations (e.g., tape drive catches fire).
Perhaps there should be an option for `unreliable automatic backup'
where success/failure is simply logged somewhere (and hope the log
remains intact!).
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris at mimsy.umd.edu	Path:	uunet!mimsy!chris