gnutar vs. dump

There have long been arguments between the proponents of tar and dump as archiving utilities. Both applications stem from the early days of UNIX and were designed for different purposes. tar (and its descendants pax and gnutar) will archive files from an arbitrary point in the directory tree, while dump (and its variant ufsdump) backs up filesystems inode by inode. Each holds advantages under certain circumstances, but Amanda allows for both and hides the differences within Amanda itself.

Because dump uses the filesystem information from the block device, and that information is synchronized at a different schedule than individual file writes, the usual recommendation is to run dump on an unmounted partition. If dump is run on an active partition, it is possible to get an un-restorable dumpfile if any files change during the run. In addition, because dump is filesystem specific, it has to be ported to different filesystems and is not yet supported on some of the newer filesystems in use. However, dump contained a mechanism to identify archived files by date so that incremental and differential backups could easily be scheduled and had a more flexible restore system than available with tar.

At this time, however, gnutar has overcome some of the limitations of the original tar, is available on most UNIX systems, and because it is frequently not possible to unmount a filesystem for backup, it is the preferred choice as a backup service for Amanda. Amanda also implements the same mechanism for monitoring incremental backups that is used in dump, and the Amanda restore mechanism transparently restores files and directories in the same manner whether the underlying backup system is tar or dump.

In the end, while gnutar is the preferred backup system, dump is supported and may still be appropriate under specific circumstances.