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 (
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 ...