== The history of Unix ((*dump)) programs

The idea of a _dump_ program itself goes back to V6
(Research) Unix, which introduced the first, [[rather basic
http://minnie.tuhs.org/UnixTree/V6/usr/man/man8/dump.8.html]] _dump_
program. At the time, Unix had neither _tar_ nor _cpio_, so _dump_ was
your only option for backups. V7 Unix introduced _tar_, and I have the
impression that as a result _dump_ fell out of favour for backups.

My impression is that _dump_ really got popular in 4.x BSD. When
Berkeley revised the filesystem format to create FFS (the Fast
FileSystem), with things like longer file names, they had to revise
_dump_ along with all of the other programs that read the raw
filesystem, but I believe that they did not really revise the _tar_
format, which had been designed in the days of shorter file names and so
on. The net result was that _dump_ became the best and perhaps only tool
for backing up your 4.x BSD system.

(The Berkeley revision of the [[simpler V7 _dump_ arguments
http://minnie.tuhs.org/UnixTree/V7/usr/man/man1/dump.1m.html]] created
the basic dump options and behavior that we can still recognize today,
with all sorts of options for tape blocksizes and so on. Berkeley also
gave us interactive _restore_.)

Then the Unix vendors showed up. Dump has two problems; it reads the
raw filesystem, which means that it has to be modified if you tweak
your filesystem format, and its output format was never created to be
portable. The result was a series of mostly but not entirely compatible
versions of _dump_ in all of the various 4.x BSD derived Unixes, most
importantly SunOS. In vendor Unixes derived from AT&T Unix, things were
more confused; some vendors had no _dump_ at all (the commercial Unix
side of AT&T appears not to have liked either V7's _dump_ or _tar_,
because they went and invented _cpio_), while others decided that 4.x
BSD _dump_ was a good idea but they should call it by another name, such
as SGI's _efsdump_ (to match their EFS filesystem).

(At some point, Sun decided that renaming _dump_ to _ufsdump_ would
be a good idea.)

When people started doing filesystems that were really not derived from
FFS, many of them decided that a _dump_-style program was a [[good
idea ../solaris/WhyZFSDump]] and that there was an obvious naming
scheme for theirs.  However, they often did not bother to make either
the command usage or the output format look anything like traditional
_dump_, and so we got a parade of programs like _xfsdump_ (SGI XFS),
_vxdump_ (Veritas VxFS, available for various Unix flavours), and
_vdump_ ([[AdvFS http://en.wikipedia.org/wiki/AdvFS]]).

(This list is primarily researched from the [[Amanda source
../sysadmin/AmandaRestorePrograms]].)

When Linux ext2 was created, energetic people decided that it too should
have a _dump_, so they wrote one (I am not sure if they started from
scratch or used the 4.x BSD code as a base). Unlike previous versions of
_dump_, they decided to try to make a portable suite: a _dump_ that had
relatively portable output, and a _restore_ that could read and properly
deal with pretty much any 4.x BSD derived _dump_ format. This makes the
Linux dump suite pretty much a [[universal receiver DumpFormatGotcha]],
which is periodically very handy.