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

[AEF]

On Nov 1, 6:54 pm, Alan Frisbie <Usenet02_REM... at Flying-Disk.com>
wrote:
> 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 inhttp://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

I am glad to hear everything turned out all right. It is lucky that
you did /IMAGE backups; otherwise, a file whose name or FID was on the
bad block would not have made it to the save set. I realize now that
to be safe, an /IMAGE restore is also necessary to restore any files
that were missed during BACKUP's directory walk, although without
being associated with any directory. A regular /SELECT restore would
have missed such files. An /IMAGE restores them, but you need to run
ANAL/DISK to get them, as you did. OK.

Your middle initial is "E"? Really?  :-)  &-)

AEF