[Info-vax] Backup's processing of directory files

[Alan Frisbie]

On 10/29/2010 10:39 AM, Alan Frisbie wrote:
> My user disk (SCSI) has developed a bad block
> (parity error when trying to read it). This block
> is right in the middle of my 15,000 block MAIL.DIR
> file. :-( Needless to say, this puts a crimp in
> mail processing.

As it turned out, the drive is toast, at least as far
as I am concerned.

In addition to the backups of the previous few days, I
was able to do another one Friday morning.   The only
errors in the log were the same ones, all because of the
one bad block in the directory file.

Since the weather has cooled down a bit, I powered on
the MSA1000 and restored the tape to a spare drive
(RAID-1 set).  It completed without errors.   However,
Backup restored the directory file with the same bad
block in it.   The only difference was that it was
readable, but with garbage data.

I then set the file /NoDirectory and deleted it.
Analyze/Disk/Repair then recovered all the files into
[SYSLOST].   I created a new directory file and renamed
all the .MAI files into it.   Everything was now back
to normal.

However, I wanted to see if I could do the same trick
with the original drive, just for fun/education.
Not wanting to take a chance of the bad block getting
reused, I did not delete the bad directory file, but
just renamed it.   I then ran Analyze/Disk/Repair and
went to bed.   Saturday morning it was still running
with continual errors about not being able to enter
the lost files into [SYSLOST] because of a parity
error in SYSLOST.DIR.   Yup, the drive is toast.

When a drive with an error gets another one during
a repair attempt, it is time to give up.   To quote
Hoff's advice in http://labs.hoffmanlabs.com/node/838
"Get your data off of the device right now" (as I did).

Fortunately I had a spare drive, so I installed it
Saturday morning.   The only problem was convincing
the cat to give up her favorite perch on top of the
XP1000.   :-)

Thanks to everyone who provided valuable hints and
suggestions.

Lessons learned:

0. Actually *do* regular backups (OK here)
1. Test all error paths in my Backup scripts (Oops!)
2. Do "SHOW ERRORS" every so often, just in case (Oops!)
3. Keep spare hardware on hand, because failures happen. (OK here)

Alan "The Other AEF" Frisbie