Is dump dumb? (Was: Contest: dump(8) parameters for DC300XL 1/4" ...)

[Chuck Karish]

In article <170 at cui.UUCP> petitp at cui.UUCP (PETITPIERRE Dominique) writes:
>	- Why doesn't 'restore -t' give you the name of the file system stored
>	on the tape?
  dump stores only the contents of the partition, not any external information
  like the name by which the operating system knows the disk device.  
  This is in accordance with the minimalist UNIX traditions.
  I agree that it's frustrating that the paper label on the tape is so
  important.

  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.

>	- Why isn't it possible to specify many file system to be stored
>	on the same tape (cartridge).
  What happens when you want to re-use the first part of the tape, and the
  file system you want to dump has grown?  You're not able to use the tape
  efficiently unless you dump both file systems again.  If you take seriously
  the purpose of dump, which is to provide security of your users' data,
  you may appreciate that it's better to put backups on separate tapes, so
  that failure of a single tape does not destroy two backups.

>	- Is it true that restored files will have their modification time
>	always set to the time of the restore command? (no 'p' option like
>	for tar). Thats what happend to me with a level 0 dump.
  I just tried a restore -i, logged in to an Ultrix system as root.  The
  correct dates were restored.

>	- Why isn't it possible to specify the size of the tape in (mega) bytes
>	rather than this cumbersome combination of density, length and
>	mysterious 'c' option?
  dump was written with the assumption that everyone was using reels of
  9-track tape.  This was fairly accurate at the time.  It wouldn't be a bad
  idea to have dump accept a size parameter in megabytes.  The operator will
  still have to account for changes in tape capacity when the block size
  is changed (different number of inter-record gaps).

>	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.  On machines on which this is possible, the vendor is
  free to add such a capability.

>	- Why can't dump work on active file systems? At least for incremental
>	dumps that would be quite useful to run dump in multi-user mode!
  dump makes four passes through the file system.  If the file system is
  active while this is going on, information gathered on the early passes
  will not be valid by the time the final pass is complete.  dump does
  work on active file systems; it's just not as reliable.  If you run it
  on an active file system, the file system will be inconsistent when it
  is restored.  fsck will usually fix this, with some unavoidable loss of
  data.  In extreme cases, the restore will fail.

>	- Why is dump always interactive? Especially because you have to
>	wait till every user logs out, it would be nice to have dump
>	run at night, unattended, and properly coping with tape errors, as a
>	big boy (and mail to 'root' the results).
  It should be possible to write a script to make dump run unattended.
  It's a bit tricky to make it smart enough to unmount the file system
  for you. As for automatically coping with tape errors, I think you're
  dreaming.

  My feeling is that it's an important enough task that it merits the
  attention of a live operator.  If you're thorough about doing the
  dumps, you'll unmount the file system and run fsck first, at least
  for level 0 dumps.

Chuck Karish	ARPA:	karish at denali.stanford.edu
		BITNET:	karish%denali at forsythe.stanford.edu
		UUCP:	{decvax,hplabs!hpda}!mindcrf!karish
		USPS:	1825 California St. #5   Mountain View, CA 94041