Thanks to Damon Goforth, Werner Hahling, Jesper Nemholt, Alex Harkema, Dr
Thomas Blinn, John Seel, alan_at_nabeth.cxo.cpqcorp.net
<mailto:alan_at_nabeth.cxo.cpqcorp.net>
& sysadmin_at_astro.su.se <mailto:sysadmin_at_astro.su.se> for the input to the
question (see below).
All the suggestions and recommendations pointed to things we had already
tried or (should) have tried. Checking the error log using uerf or dia did
not reveal any states of error from the tapes other than some "tape not
available" errors. Checking the tapes using alternative methods such as "dd"
provided no new information either.
Dr Blinn suggested the use of "/usr/field/tapex -m". It's in the base OS
"System Exercisers" subsets. Simply install and run. It reads the tape. I
haven't done this yet but intend to. He also recommended that a check be
done on software upgrades. None had been done.
Basically, the resolution turned out to be,
you guessed it,
clean the tape drive!
The units are supposed to indicate when a head cleaning tape is to be run. I
am here to tell you that you should ignore that and institute a regular head
cleaning policy. We will be running the head cleaners every week from hence
forth on our major production system and monthly on the other systems. Your
kilometerage may vary.
But whatever you do CHECK YOUR BACKUPS before you get caught out!!
Wayne Blom
Systems Specialist
F H Faulding & Co Limited
E-mail: wayne.blom_at_au.faulding.com
S-mail: Building D, 115 Sherriff St, Underdale SA 5032
Ear-mail: 0419808496
"Someday, we'll look back on this, laugh nervously and change the subject."
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Hoping someone out there may have seen something similar and have one of
those great (wished I though of that) solutions?
We are running 4.0F trucluster on a GS140 pair. Patchkits 4 + bits of 5 are
on both.
The backup tapedrives are a pair of TL800 with a pair of TZ89s in each and
we are using DLT IV tapes.
Backup has been working fine until about a month ago. Since then the
validity of the backups has varied from no sets valid to all sets valid.
Even this mornings tapes, 2 backup tapes were totally worthless but one has
the first 3 backup sets valid but the forth is corrupt.
Compaq has replaced the tapedrive where the symptoms were first noticed
(drive 0) and compaq will be brought back into the loop again now that all 4
tapedrives are producing the same problems. I will be looking in the
archives today as well.
The difficulty is that VDUMP is writing successfully (or so it thinks). We
only find the problem when trying to vrestore from the tape. Just shows that
you should always double check your tapes and backups.
Is it;
1. The tapedrive library
2. The SCSI cards
3. The tapedrives themselves
4. The VDUMP command
5. The VRESTORE command
6. Other
With all the testing and swapping of tapedrives between systems, I am
leaning toward the tape libraries themselves.
Any suggestions would be greatfully accepted.
Wayne Blom
Systems Specialist
F H Faulding & Co Limited
E-mail: wayne.blom_at_au.faulding.com
S-mail: Building D, 115 Sherriff St, Underdale SA 5032
Ear-mail: 0419808496
"Someday, we'll look back on this, laugh nervously and change the subject."
Received on Wed Apr 10 2002 - 23:56:30 NZST