Verification of backups.

[Ruth Milner]

The v option on the 4.1 dump is essentially useless for root and /var, and
for other filesystems if you prefer not to dump single-user. *Any*
difference found, even something as trivial as the access time on a file,
will cause the verification to fail and dump will attempt to rewrite the
volume. It would be nice if it simply reported the difference and prompted
for whether to rewrite, continue, or quit the verify. I understand that
Sun wants to be on the safe side, but sometimes it's nice to have the
option of taking the responsibility for your own decisions :-). 

What I do to verify crucial backups (e.g. immediately before an upgrade or
some such) is an interactive restore. I look at the inode numbers (dump
appears to put the files on in inode order), pick a file with a very high
inode number compared to the rest, and restore just that. In this way I
can force dump to read through 90-100% of the dump and see if there are
any errors getting there. I have also seen restore report errors in
something like the expected file size, without crapping out on the whole
job. So things aren't necessarily hopeless even if the dump isn't perfect.

I used to think that the table of contents listing was in the same order
as the dump, but once when I restored the last file in the table of
contents, the tape ended up only about half of the distance through the
reel that it had been when the dump finished. When I looked at the inode
numbers, it appeared to be in the middle of the range. 

Does anyone know for sure what order dump uses?

Ruth Milner
Systems Manager                     NRAO/VLA                  Socorro NM
                            rmilner at zia.aoc.nrao.edu