>From: Jon Ribbens <jon@oaktree.co.uk>
>
>(Why do mt and tar use /dev/rst0 as a default? Especially for 'mt',
>this seems ludicrous - 'mt fsf 1' will dutifully fast-forward the
>tape one file, then when mt finishes the drive will dutifully rewind
>the tape back to the beginning again. Cunning.)

I've never understood that either, except perhaps the intention is/was
to make sure tapes were returned to a removable position by default --
if the non-rewinding device was the default, the tape would be left in
an unwound state.  An inexperienced user might not know how to fix this,
and try to remove the tape anyway (ouch).

>Anyway, my main question is whether I should use 'dump' or 'tar'
>to backup my data (at least 2GB). I would use 'dump', since it
>seems the obvious choice, but 'restore' seems very unreliable,
>and there is no way I can find to test a 'dump' backup without
>having a blank drive to restore the data onto. ('restore -t' doesn't
>actually read the whole tape.)

The `dump` and `restore` commands are designed for creating system-level
backups, and are good at this job.  The primary problem with them is that
the dump file format varies between unix flavors.  I have never had any
problems with `restore` being unreliable (see my comments below regarding
your example).  A fairly safe way to verify your dump tape without actually
restoring it completely is to extract the last file dumped as returned by
`restore tf`.  If this file can be restored, the rest are (most likely) fine
also.

>I have had a lot of problems with dump/restore, which up to this point
>I have been using to backup to another hard drive, e.g.:
>
>  dump -0u -f - / | gzip >/mnt/backup.gz
>
>When I come to restore the data, I've had various random-seeming
>errors, to do with restore wanting to 'change volumes' (huh?) and then
>coredumping (before setting the permissions on all the directories,
>aargh). 'dump' also seems to randomly say 'Signal on pipe: cannot
>recover', and I have to start the whole thing again.

The problems you are encountering are due to two factors: (1) You need to
tell `dump` that it is dumping to a device as big or bigger than the size
of the filesystem involved so it doesn't think it needs to change "tapes".
To do this, play with the "d"ensity and "s"ize options.  Beware that due to
its age (over 20 years) it cannot really cope with the real numbers, so you
will need to understate the density and overstate the size of the "tape".
(2) I am not sure it is safe to feed the output from `dump` in to `gzip`.
Unless the receiving program properly preserves the block size being output
by `dump`, the resulting file will be corrupt.

>So, I think maybe I'd like to use 'tar' instead. At least it's
>simple, it can cope if the backup file is truncated, and I trust
>it a lot more. My only question is whether it is suitable for
>this sort of thing - will it cope okay with devices, FIFOs, hardlinks,
>symlinks, files with holes, etc? Can I just do
>
>  tar cl /
>
>to backup and later 'tar x' to restore? Do I need the 'S' option
>to handle sparse files 'more efficiently'?

The `tar` program has become increasing able over the years, and may now be
up to the job of handling all the possible complexities of backing up a
filesystem, but beware that it really wasn't designed for this job, and may
fail in subtle and hard to detect ways.

Max