2007-08-09
A gotcha with the format of dump archives
Most archive formats, such as tarballs, cpio archives, and zip archives,
interleave the file names (and their directory structure) with the file
contents. The dump filesystem backup program such as Solaris ufsdump
do not. The dump archive format starts with an index that has all of the
filenames and the directory structure; after this comes the actual file
content, labeled by inode number.
This has an important consequence for detecting damaged archives. In an
interleaved format like a tarfile, getting a full file listing requires
reading the entire archive and thus checks that it's intact. However, in
dump's format getting a full file listing only requires reading the
first bit of the archive; it does not guarantee that anything past the
index is uncorrupted or that all of the listed files are actually present
in the archive.
There are two ways of verifying dump archives; one is general and
the other requires the Linux version of restore.
- Linux's
restorehas a-Nflag that causes it to not write anything to disk, so you can do a 'dryrun' restore that reads the entire archive with something likerestore -x -o -N -f ....Linux's
restorecan generally read the output ofdumpfrom non-Linux systems. In particular, we have tested it with Solaris 8ufsdumpand it works fine. - you can use a full file index to work out the highest inode
number in the dump archive and then restore just it. Because
dumpusually writes out files by increasing inode number, this generally forces the restore program to read the entire archive.(However, I don't know if this will detect missing files, things that are in the index but not in the file contents.)
If neither of these are workable or good enough, your only option is to do a full restore to a scratch partition somewhere.
(For reference, the home of the Linux dump and restore is here. While dump requires ext2 specific
header files and libraries, I believe that restore can be compiled on
most any system with some work.)