This article can also be found in the Premium Editorial Download "Storage magazine: Learning data retention lessons from Warner Bros.."
Download it now to read this article plus other related content.
|Five key questions about dump|
The following questions are the ones most asked concerning the dump Unix backup utility.
If we dump an active filesystem, will data corruption affect individual directories/files in the dump?
The following three scenarios can occur if your filesystem is changing during a dump:
A file is deleted before Pass I. The file is not included in the backup list because it doesn't exist when Pass I occurs.
A file is deleted after Pass I but before Pass IV. The file may be included in the backup list, but during Pass IV, dump checks to make sure the file still exists and is a file. If either condition is false, dump skips backing it up. However, the inode map written in Pre-Pass III will be incorrect. This inconsistency does not affect the dump, but restore will be unable to recover the file even though it is in the restore list.
The contents of a file marked for backup change (inode number stays the same); there are really two scenarios here. Changing the file at a time when dump is not backing it up does not affect the backup of the file. dump keeps a list of the inode
numbers, so changing the file may affect the contents of the inode but not the inode number itself.
Changing the file when dump is backing up the file probably will corrupt the data dumped for the current file. dump reads the inode and follows the disk block pointers to read and then write the file blocks. If the address or contents of just one block changes, the file dumped will be corrupt.
The inode number of a file changes. If the inode number of a file changes after it was put on the backup list (inode changes after Pass I, but before Pass IV), when the time comes to back up the file, one of three scenarios occurs:
- The inode is not being used by the filesystem, so dump will skip backing up this file. The inode map written in Pre-Pass III will be incorrect. This inconsistency will not affect the dump but will confuse you during a restore (a file is listed but can't be restored).
- The inode is reallocated by the filesystem and is now a directory, pipe, or socket. dump will see that the inode is not a regular file and ignore the backing up of the inode. Again, the inode map written in Pre-Pass III will be inconsistent.
- The inode is reallocated by the filesystem and now is used by another file; dump will back up the new file. Even worse, the name of the file dumped in Pass III for that inode number is incorrect. The file actually may be of a file somewhere else in the filesystem. It's like dump trying to back up /etc/hosts but really getting /bin/ls. Although the file is not corrupt in the true sense of the word, if this file were restored, it would not be the correct file.
This was first published in August 2007