Hi,
I got exactly two replies to this posting. One from
alan_at_nabeth.cxo.dec.com who said:
>From alan_at_nabeth.cxo.dec.com Fri Jan 10 13:41:55 1997
I don't think if any of the dump family of programs do
verify passes. And, since the directory is typically
stored at the beginning of the dump, a 't' listing only
reads part of the tape. Using dd(1) to read the archive
will verify that the drive claims it to be readable, but
if the drive is passing back corrupt data, you need
something better.
The only sure way is to compare the backed up data with
the original. Short of special program to do it, the only
easy way is to restore all or part of the backup and then
compare with the original. If the [v]restore operation
preserves the modification time, you can take a short cut
of only comparing files with the same modification time.
Thanks Alan for pointing that out. BTW: I've noticed today that the
Solaris 2.5 "ufsdump" does have a -v verify option which effectivly
rewinds the tape and does a compare. Would be good for 'vdump' as well :-)
The other answer was from "Martin J. Laubach" <mjl_at_CSlab.tuwien.ac.at>
who suggested to use something like that:
vdump ... | tee /dev/rmt0h | sum
followed by a:
dd if=/dev/rmt0h | sum
Well: Inspired by that, I've modified my backup scripts like that:
TAPE=/dev/nrmt0h
BSS=60
DUMP="vdump -v -0 -F 64 -b $BSS -f -"
BTEE="/usr/local/bin/btee $BSS"
BS=${BSS}k
echo Rewinding tape
rsh $HOST mt -f $TAPE rewind
#--------------------------------------------------------------------------
# BACKUP
#
echo "Backup /"
s0=`($DUMP / | rsh $HOST "$BTEE $TAPE | cksum") 2>$LOG`
......
#--------------------------------------------------------------------------
# VERIFY
#
echo Rewinding tape
rsh $HOST mt -f $TAPE rewind
echo "Verifying /"
v0=`(rsh $HOST "dd if=$TAPE ibs=$BS obs=$BS | cksum") 2>/dev/null`
echo Checksums: $s0 $v0
if [ "$s0" != "$v0" ]; then
echo "***** ERROR: VERIFICATION FAILED........"
fi
.......
I do this for all of the save-sets on my tape and it works without
problems.
'btee' is a small 'tee' look alike program I wrote today for blocking
output. This is required in order to read the save-set directly
with 'vrestore' rather than with
dd if=/dev/rmt0h ibs=60k obs=60k | vrestore if -
When 'tee' is used, the above command needs to be used for restoring.
So I'm quite happy with this solution.
Thanks -- Tom
Here is my original posting:
> After a rather bad experience with our HP C1533 DAT streamer today
> (it had silent read errors: each time the tape was read, different
> single bytes were corrupted in the read data stream) I decided to
> make my monthly vdump backups more secure. Currently after vdump'ing
> everything to the tape, I just do a
>
> vrestore -t -f $TAPE >/var/adm/bck/bck$TODAY.log
>
> for every save-set just in order to get a listing of the files on the tape.
>
> Needless to say that this is not sufficient. I use GNU Tar for my daily
> backups and its -d option (compare) does exactly what I want: It reads
> the complete backup and compares all files with the files on the hard-
> disk and complains if a single byte is different.
>
> Question: Is something like that possible with vdump/vrestore? I've
> already checked all options but could not find anything.
>
> Is it possible by some hacks to use vrestore for comparing ? What if I
> vrestore everything to a TMP directory and write run a second
> concurrent process which grabs the restored filenames from stderr,
> compares and finally deletes the files? Did anyone write something like
> that?
--------------------------------------------------------------------------
T o m L e i t n e r Dept. of Communications
Graz University of Technology,
e-mail : tom_at_finwds01.tu-graz.ac.at Inffeldgasse 12
Phone : +43-316-873-7455 A-8010 Graz / Austria / Europe
Fax : +43-316-463-697
Home page :
http://wiis.tu-graz.ac.at/people/tom.html
PGP public key on :
ftp://wiis.tu-graz.ac.at/pgp-keys/tom.asc or send
mail with subject "get Thomas Leitner" to pgp-public-keys_at_keys.pgp.net
--------------------------------------------------------------------------
Received on Fri Jan 10 1997 - 14:20:33 NZDT