dump is a powerful tool to back up Unix files. However, the dump utility isn't intuitive and can produce some unexpected results, especially during a restore. Here's how dump works.
Using the dump utility to back up Unix-based files can be a tricky undertaking. The following excerpt from W. Curtis Preston's new book, Backup & Recovery: Inexpensive Backup Solutions for Open Systems, explains how dump works and tells what can go wrong at various stages of the dump backup process.
cpio, ntbackup, and tar are filesystem-based utilities that access files through the 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--in a Unix-based operating system, an inode is a stored description of an individual file--(atime or ctime).
Backup & Recovery: Inexpensive Backup Solutions for Open Systems by W. Curtis Preston ISBN: 0-596-10246-1 Copyright 2007 O'Reilly Media Inc. |
Requires Free Membership to View
When you register for SearchStorage.com, you’ll also receive targeted emails from my team of award-winning editorial writers. Our goal is to keep you informed on the hottest topics, the latest news and the biggest challenges you face as a storage professional today.
Rich Castagna, Editorial Director
| Used with the permission of O'Reilly Media Inc.
Available from booksellers or direct from O'Reilly Media at www.oreilly.com/catalog |
dump, on the other hand, does not access files through 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 works is not well known. The dump manpage doesn't help matters either, since it creates FUD (fear, uncertainty, and doubt). For example, Sun's ufsdump manpage 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 isn't clear what the extent of the problem is if the advice isn't 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 or the entire dump? Do we really have to dismount the filesystem to get a consistent dump?
This was first published in August 2007