>>> I looked at the dump/restore command and started a dump of /home that was
>>> about 50 MB.  dump then asked for another tape.  The DAT tape is supposed
>>> to hold 2 to 4 GB with compression so I must be doing something wrong. :-)
>>
>
>Depending on the data you are backing up you may not get much over
>2GB, about 150% (ie about 3G for you...) is average on our systems at
>work using exabytes. 
>
>>They're as good as any other. dump is the fastest way, but is highly specific
>>to the filesystem format (and possibly even endianess).
>
>And a reliance on a quiet file system for a good backup since dump
>writes a table of all the file inodes first and then goes looking for
>the data.
>
>> gnu tar (the tar
>>under NetBSD) is also reasonable.
>>
>
>I believe that gnu tar does not have this problem but to other tars
>you must be very careful if you backup your system using it.

Here is one additional viewpoint on the "dump-vs-tar for system backups" war:

I come from the "old school" back when tar didn't handle names longer than 100
characters, didn't deal with special devices, couldn't do multiple volumes,
etc etc.  Nowadays GNU tar does all that, but there is still one good reason
to use dump over tar.

Dump writes out a map of the filesystem hierarchy at the beginning of the tape
and restore will allow you to browse this structure and pick only the files
you want restored.  You can't do this with tar, as the file structure is kept
with every file, which means you'll need to read the whole tape to get a full
listing.  You can get around this by saving the output of the tar command, but
I don't know of a nice interface that lets you pick what you want to get back
like tar has.

Also, assuming you wrote the inode ranges down on the tapes (a habit from the
days when I used to dumps for the CS department) you can easily tell which tape
a particular file lives on, if you have a multi-tape backup.  With tapes now
in the gigabytes, this isn't the big deal that it once was.

--Ken