My original question was:
Once in awhile I get a backup tape that is not readable for
one reason or another. How, (if at all) are you checking that
backups are being done correctly after a dump is finished?
I am aware of the (v)erify option of the dump command. This option
though appropriate can be very time consuming, as we backup hundreds
of gigabytes per night. This option will only work on a very inactive
filesystem as well.
Does anyone have any scripts etc. that does a quick sanity check to
see if the tape is at least useable?
Thanks to the many people who responded.
Many different ways were given, most of them are included below.
The general approach is to write a file on the tape and read it
back, or read the table of contents back, or dump the whole thing
to /dev/null using a script for each. A few other ideas were also
given (see below)
+--------------------------------------+
| Kurt Sauter |
| Teradyne Semiconductor Test Division |
| 30801 Agoura Rd |
| Agoura Hills, CA 91301 |
|--------------------------------------|
| ph# 818-991-9700 |
| email sauter@teradyne.com |
+--------------------------------------+
------------------------------------------------------------
I'm not sure that verifying a backup is all that necessary.
If the backup completed successfully, it should be ok.
The only way to verify, that I know of, is to actually
retrieve a file that is stored near the end of the tape, but
this is time consuming.
If you follow a few basic rules on tape usage, the media
should be reliable.
A few rules that I practice:
1) Use data cartridges ONLY.
2) Store and use tapes and their drives in a clean and
climate controlled area.
3) Recycle highly used tapes. And use new tapes for critical
backups.I recycle after about 20 backups.
4) Use a backup strategy that assures data can be found on more
than one tape, if need be.
5) CLEAN THE DRIVES FREQUENTLY.
I have been running backups on 3 tape drives simutaneously for
about 5 years now and have run into a bad read on only 1 tape,
believe it or not. I've had many bad tapes come up during the
actual backup however, in which case, I throw out the tape.
By the way, I run level 0's once a month and keep them for
1 year, level 5's once a week and keep them for 3 months, and
level 9's the rest of the time and recycle every 7 days.
Hope this helps.
.-----------------------------------------.
| Daniel Hurtubise (Systems Integrator) |
>From syoung@cs.Buffalo.EDU Tue May 30 12:53:07 1995
From: Steve Young <syoung@cs.Buffalo.EDU>
Subject: Re: How can one verify backups?
To: sauter@STD.Teradyne.COM
Date: Tue, 30 May 1995 15:48:29 -0400 (EDT)
In-Reply-To: <9505301542.AA27037@fancy.STD.Teradyne.COM> from "Kurt Sauter" at May 30, 95 08:42:02 am
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
It is not to hard to do a quick restore from a backup tape of some known
file - ie. pick some file that always is changing or touch a file before
each dump and then do a non-interactive restore on the file. One
neat thing I did which only says that the tape is read-able and not
that it really has the files you want on it, is to do a "what" after each
dump on the tape and then use that to log what got dumped.
Steve
You could use lldump by Bill Heelan (wheelan@cs.mcgill.ca) ftp from:
ftp.cs.mcgill.ca:/pub/unix/lldump/lldump.tar.Z
Ian.
----------------------------------------------------------------------------
Ian MacPhedran, Engineering Computer Centre, 2B13 Engineering Building,
University of Saskatchewan, 57 Campus Drive, Saskatoon SK S7N 5A9, CANADA
Phone: (306)966-4832 Fax: (306)966-8710 Email: Ian_MacPhedran@engr.USask.CA
>From fetrow@biostat.washington.edu Tue May 30 15:45:11 1995
Date: Tue, 30 May 1995 15:42:55 -0700 (PDT)
From: Dave Fetrow <fetrow@orac.biostat.washington.edu>
To: Kurt Sauter <sauter@STD.Teradyne.COM>
Subject: Re: How can one verify backups?
In-Reply-To: <9505301542.AA27037@fancy.STD.Teradyne.COM>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
It is often adaquate to do something like:
dd if=/dev/st0 of=/dev/null
which will (usually) catch a corrupt tape.
-------------------------
Both at my previous job and here we use cpio for backups. At the previous
place, we just had cpio do a table of contents of each file, with stdout
directed to /dev/null.
Where I am now the byte stream going to the tape is piped through a
little C program that calculates the 32-bit unsigned sum of all the
bytes (also a byte count), and writes it as text to stderr once eof is
reached on stdin. This is captured by the shell, and the checksums for
all the files are saved in an array. Once all the files have been written,
the tape is rewound. Each file is then read by dd and piped into the
checksum program (and from there to /dev/null). These checksums are
compared with the saved values from the backup phase.
Verify Host Partition Time Time Checksum Bytes
------ -------- ------------------------ ----- ----- ----------- ----------
Pass ra ./usr/local/eng 21:49 22:33 2045432523 544332800
Pass ra ./disks/sd2a 22:33 00:03 1558255130 1017159680
Pass ra ./export 00:03 00:05 221345812 13224960
Pass ra ./u2/ejk 00:05 00:10 892066393 50641920
Pass ra ./var 00:10 00:12 785727180 24673280
Pass marvin ./v 00:12 01:12 1494861076 292080640
Pass marvin ./ 01:12 01:42 3330899068 159820800
Pass ludwig ./ 01:42 01:43 157634503 6676480
Pass ludwig ./usr 01:43 01:54 912769816 66821120
[etc...]
-- erp@microplex.com ted@wimsey.com (Ted Powell) Microplex Systems Ltd. Voice: +1 604 444 4232 (x222) Fax: ...4239-------------------------
I would think that all you need to do is cat /dev/tape > /dev/null or something like that. It will at least tell you that the tape is readable. If you have enough disk space, you can dump the whole file system to another disk and then transfer that to the tape, rewind the tape and do a cmp on the tape and the disk file. Alterntaly again, you could pipe your backups through something like "gzip". By then unziping the tape data to /dev/null you can detect tape write problems because the zip data will report problems if the data on the tape is corrupted.
Hope this helps.
--- Tony Jago, System Administrator, E-Mail: T.Jago@fit.qut.edu.au Faculty of Information Technology, Web: http://www.fit.qut.edu.au/staff/~tony Queensland University of Technology. Box 2434, Brisbane 4001, AUSTRALIA. Problems should be mailed to: Phone: +61 7 864-2573 Fax: +61 7 864-1959 duty@fit.qut.edu.au
---------------------------
>From pluto!perryh@qiclab.scn.rain.com Wed May 31 00:33:06 1995 Date: Wed, 31 May 95 00:02:21 PDT From: perryh@pluto.rain.com (Perry Hutchison) To: sauter@teradyne.com Subject: Re: How can one verify backups?
> Once in awhile I get a backup tape that is not readable for > one reason or another ... > > I am aware of the (v)erify option of the dump command. This option > though appropriate can be very time consuming, as we backup hundreds > of gigabytes per night. This option will only work on a very inactive > filesystem as well. > > Does anyone have any scripts etc. that does a quick sanity check to > see if the tape is at least useable?
"restore t" will tell you if the directory portion of the dump is readable. To test the actual data part, you either need to run something like lldump (ask archie) or find the largest i-number in the "restore t" output and extract that file from the tape. These data verifications would take nearly as long as the dump itself, but they do not require an inactive file system and therefore could be run while the system is multi-user during the next day.
---------------------------
If I wanted to at least see if the tape was valid, I'd go to each backup on the tape (mutiple backups per cartridge) and restore one file from each backup. That will at least tell me if the tape is readable and the backup maps are in somewhat good condition.
Or you could just have it give a listing of the file contents with I think the -t option in ufsrestore. Check out the solaris2.x man page if you have it.
Jim
-- James Mularadelis - Unix Systems Administrator Computer Services - SUNY College at New Paltz (914) 257-3130 - jamesm@matrix.newpaltz.edu, james@newpaltz.edu
---------------------------
The backup program that I wrote a few years ago generated a table of contents of the tape after writing the tape. This was not proof that the data was all intact, but it at least gave a high confidence level that what I thought should be on the tape was probably there, and was in the correct format.
Michael Shon (716) 385-5065 michael.shon@East.Sun.COM
-----------------------------
>From z055084@uprc.com Wed May 31 05:56:08 1995 Date: Wed, 31 May 1995 07:50:18 -0500 From: z055084@uprc.com (Kohler R. P. (Robert)) To: sauter@STD.Teradyne.COM Subject: Re: How can one verify backups?
I run the my backups and log the results on the dump command to a file. Upon completion, I scan the file for "DONE". If I see this I assume it is good, and 99% of them are. Very seldom do I get a bad backup. NOTE: We clean drives every week.
-----------------------------
Back at the ranch, Kurt Sauter scribed:
: Once in awhile I get a backup tape that is not readable for : one reason or another. How, (if at all) are you checking that : backups are being done correctly after a dump is finished?
I don't have the scripts anymore as I am no longer using dump for backups, but at my last employer I had the backup scripts do a `restore t` redirected to a listing file. This had the advantage of giving me a grep'able list of files to hasten the restore process as well as confirming the readibility of the tape.
Biggest complication was getting the `mt` commands right for tapes that had multiple nights of incremental backups.
restore t runs after the backups, so doesn't lengthen the time you need a quiescent disk, tho' it +does+ increase the tape (and tape drive) wear ... As Mr. Heinlein said, "TANSTAAFL" ...
-Reto L.- -- R A Lichtensteiger rali@hri.com System Administrator Horizon Research Inc (617) 466-8304
--------------------------------
>From etnibsd!vsh@uunet.uu.net Wed May 31 07:55:51 1995 From: etnibsd!vsh@uunet.uu.net (Steve Harris) Subject: Re: How can one verify backups? To: uunet!std.teradyne.com!sauter@uunet.uu.net Date: Wed, 31 May 1995 10:28:29 -0400 (EDT) In-Reply-To: <9505301542.AA27037@fancy.STD.Teradyne.COM> from "Kurt Sauter" at May 30, 95 08:42:02 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit
Kurt,
Our backup script does incremental dumps on all systems on our net every night (using the non-rewind tape device). After the dumps are done, it rewinds the tape and does a:
restore -t >> logfile mt fsf repeatedly until every dumpset has been processed. A _summary_ of the results is mailed to the sysadmin list. While this does not _verify_ the data, it gives us some confidence that the dumps worked and the tape is readable.
You can adapt this methodology for your own network.
(Actually, what we do is a bit more complex -- we prepend a header to each dump save set identifying it (the host and partition); this header has to be stripped off before doing the restore.)
Sorry, our scripts are too ugly for public consumption. :-(
---------------------------------
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:10:26 CDT