Unix Backup and Recovery

Demystifying dump

cpio and tar are filesystem-based utilities, meaning that they access files through the Unix filesystem. If a backup file is changed, deleted, or added during a backup, usually the worst thing that can happen is that the contents of the individual file that changed will be corrupt. Unfortunately, there is one huge disadvantage to backing up files through the filesystem: the backup affects inode times (atime or ctime).

dump, on the other hand, does not access files though the Unix filesystem, so it doesn’t have this limitation. It backs up files by accessing the data through the raw device driver. Exactly how dump does this is generally a mystery to most system administrators. The dump manpage doesn’t help matters either, since it creates FUD (Fear, Uncertainty, & Doubt). For example, Sun’s ufsdump man page says:

When running ufsdump, the filesystem must be inactive; otherwise, the output of ufsdump may be inconsistent and restoring files correctly may be impossible. A filesystem is inactive when it is unmounted [sic] or the system is in single user mode.

From this warning, it is not very clear the extent of the problem if the advice is not heeded. Is it individual files in the dump that may be corrupted? Is it entire directories? Is it everything beyond a certain point in the dump? Is it the entire dump? Do we really have to dismount the filesystem to get a consistent dump?

Questions like these raise a common concern when performing backups with dump. Will we ...