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 restore has a -N flag that causes it to not write anything to disk, so you can do a 'dryrun' restore that reads the entire archive with something like restore -x -o -N -f ....

  Linux's restore can generally read the output of dump from non-Linux systems. In particular, we have tested it with Solaris 8 ufsdump and 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 dump usually 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.)