Very Computer

I've been seeing posters in comp.os.linux.hardware almost exclusively
referring to 'tar' as the way they are doing system backups to tape.

Though I'm fairly new to Linux I've done UNIX sysadmin for years
and have always used 'dump' instead of 'tar'.  I suppose that some of
the reasons I don't use tar are probably historical -- old tar
implementations barfed on really long filenames as well as not knowing
about filesystem boundaries.  Even with the newfangled GNU tar
features, I still see that dump/restore may have a couple advantages
over tar:

  dump uses a master/slave arrangement when writing tapes which (I
  believe) helps to keep the tape buffers full which leads to better
  streaming behavior and thus possibly better performance on the tape
  drive.

  dump seems to be somewhat faster if the output device isn't the
  major limiting factor, such as when using tar or dump to move files
  from one partition to another.  In some brief tests on a (P166,
  2.0.10, AHA2940U) alternately dumping and taring a 200M filesystem
  onto a disk file (on a separate scsi drive) using the '-f' flag I
  found that tar was consistently slower on the order of 20-30%.  I
  don't have a tape drive handy right now to do testing, but I suspect
  that some of these factors could lead to improved performance on
  tape too.

  dump writes a file table at the beginning of the dump which allows
  you to look at the archive contents without having to read the whole
  file.  The 'restore' command also has an interactive mode which
  allows for fast, easy and selective rest*of files.

  dump also has rudimentary concept of incremental backups and
  optionally keeps track of backup dates its own simple database.

As I said above I'm fairly new to Linux so there may be aspects of tar
and dump under Linux which I don't grasp, but it seems to me that
folks should check out the features of dump to see if they don't
better meet their backup needs.

One caveat though, I needed to recompile dump to get it to work
consistently under 2.0.x.  There were problems with the communication
between the master and slave during some dumps which would cause the
dump to fail.  Never did figure-out the root cause, but recompiling
has seemingly fixed it.

David

:I've been seeing posters in comp.os.linux.hardware almost exclusively
:referring to 'tar' as the way they are doing system backups to tape.
:
:Though I'm fairly new to Linux I've done UNIX sysadmin for years
:and have always used 'dump' instead of 'tar'.  I suppose that some of
:the reasons I don't use tar are probably historical ...
[major SNIP]

My own reason is that I also use Linux for my full backups of several
DOS file systems.  Using a fundamentally different method with different
file systems is too much of a PITA.  I do pipe the output from 'tar'
through a process that implements a circular buffer to keep the tape
streaming, and my scripts keep my own version of a "dumpdates" file to
control imcremental backups.  (I had all that working before a stable
ext2 version of dump/restore was available.  If I were setting things up
today, I'd give serious consideration to dump/restore.  Right now my
setup ain't broke, so I ain't fixin' it.)

--


PGP public key fingerprint = 2F E5 82 F8 5D 06 A2 59  20 65 44 68 87 EC A7 D7

Dump tends to be filesystem-specific.

RedHat's RPM system uses cpio instead of tar; cpio has the advantage
of preserving permissions/ownership/special files.  (Recent versions
of tar may now have this feature.)

I'd quite like to see more use made of afio; this is similar to cpio
except that it permits file-by-file compression as well as specific
provision for recovering from corruption.  A single corruption should
only affect one file in the archive.
--

Web: http://www.conline.com/~cbbrowne  SAP Basis Consultant, UNIX Guy
Windows NT - How to make a 100 MIPS Linux workstation perform like an 8 MHz 286