dennett@kodak.com (08/14/90)
I have some people around here that were brought up in the VAX world. In that dimension you can run a verify pass on a backup tape you just made to ensure that the backup tape is good. These people (including a supervisor) are insisting that I make sure our Sun backups are verified. I tell them that other than looking to see if /etc/dump complains about anything, there is really no way I can verify a dump tape. However, they keep bringing up the subject. Just so I can hopefully put this issue to rest, is that true? Is there anything else I can do verify that a backup tape is good? About the only other thing I could think of is to run an interactive restore and read the table of contents, but I believe that does not read the entire tape. It only reads the table of contents from the tape. Thanks for any help. Charlie Dennett | Internet: dennett@Kodak.COM Mail Stop 01816 | Phone: (716) 588-6078 Eastman Kodak Company | -- This space under construction -- Rochester, NY 14650-1816 | -- Be prepared to stop --
epstein@uunet.uu.net (Jeremy Epstein) (08/15/90)
> I have some people around here that were brought up in the VAX world. In > that dimension you can run a verify pass on a backup tape you just made to > ensure that the backup tape is good. I've never seen a verify on a UNIX system with two exceptions: * When I worked for a hardware vendor, we added a verify option to cpio. Our tape controller had a habit of dropping bits, which was very annoying. Once it happened when we were making the master release tape...after that we always verified the release tape! I've never seen anyone else add that option. Perhaps this would be an idea to forward to POSIX??? * I added a verify option to a database backup program...same reason as above, but a different hardware vendor. Who wants to discover an error 500MB into a database backup, when you're doing the restore. Any other experiences with verify options? Jeremy Epstein UUCP: uunet!trwacs!epstein Trusted X Research Group Internet: epstein@trwacs.fp.trw.com TRW Systems Division Voice: +1 703/876-8776 Fairfax Virginia
knutson%SW.MCC.COM@mcc.com (Jim Knutson) (08/16/90)
We verify the root partition backup by restoring a file that is updated daily and comparing the result of the restore with the original. This is running SunOS 4.0.3 and works with other vendors equipment and OS versions as well. SunOS 4.1 offers an option on dump that allows you to verify the entire backup rather than just one file. It takes an extremely long time to perform this since it almost like performing a restore of the entire dump, but it does check the whole dump. Jim Knutson knutson@mcc.com cs.utexas.edu!milano!knutson
rmilner@zia.aoc.nrao.edu (Ruth Milner) (09/21/90)
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@zia.aoc.nrao.edubob@morningstar.com (Bob Sutterfield) (09/21/90)
GNU Tar has a verify option (-W). The Info section comments that "Verification requires that the archive be on a back-space-able medium. This means pipes, some cartridge tape drives, and some other devices cannot be verified."
Andrew.Michael@brunel.ac.uk (Andrew J Michael) (10/08/90)
In article <1990Sep20.204529.2184@rice.edu>, bob@morningstar.com (Bob Sutterfield) writes: > GNU Tar has a verify option (-W). The Info section comments that > "Verification requires that the archive be on a back-space-able medium. > This means pipes, some cartridge tape drives, and some other devices > cannot be verified." Yes, but if you make a second pass using the -d option to report differences between the tape and the original you can use any device, including cartridge drives. I use this quite a lot .... Regards Andy Michael (eesrajm@cc.brunel.ac.uk)