To ANALYSE/DISK/REPAIR or not before BACKUP?

[Clark Powell]

At every VMS (5.5-2 to 7.3-2) site for which I've worked, I've always run ANALYSE/DISK/REPAIR before running the backup. Over thousands of backups, I've never encounted a significant short comimg to running ANALYSE/DISK/REPAIR. Now I'm at a site that's never done this and I'm forced to justify the practice. As far as the effect on BACKUP, that's positive but, the question is, is there a reason why running ANALYSE/DISK/REPAIR in an automated, unattended way is not advisable? Have I unknowingly been loosing data that might have been salvagible? Have I been exposing the system to a melt down from the destruction of a disk? Not to my knowledge but, I would like to know if anyone else has had problems with using ANALYSE/DISK/REPAIR in this fashion?
thanks,
Clark

[Jon Pinkley]

I am not aware of any problems with running ANALYZE/DISK/REPAIR. There may have been some issues with backlinks of the VMSCOMMON directory being incorrectly set in ancient versions of VMS, (and I do consider 5.5-2 to be ancient), but if ANALYZE/DISK/REPAIR detects a problem like multiply allocated blocks, there is another problem that is causing that, and it is better to know about that kind of a problem as soon as possible.

The most common thing that happens is that things like spooled files can have entries placed in SYSLOST and those will become dangling entries when the file is deleted, but that is a harmless side effect. It will correct things like free space drift and quota discrepancies (if you are using disk quotas), so in that respect periodic anal/disk/repair are good.

I believe /repair implies /lock_volume, but I can't see that in the online help. I just tried (Alpha VMS 7.3-2) and you can specify them both.

If you never use /confirm when running analyze/disk/repair, then I see no additional risk of running it in an automated fashion.

[Doug Phillips]

You should never actually lose data with a successful ANALYZE/DISK/REPAIR, and your automated procedure would (hopefully) trap a failure and not continue with the backup step -- or the failure would be such that the backup would also fail.

However, because of learned-paranoia, I prefer that automated procedures do the backup (garbage and all) before doing anything that changes anything on the disk, even though the backup might perform better had it "cleaned-up" the disk before-hand.

Different sites have different needs, though, so there's no universal "right way."

[Hoff]

If you're looking for stuff to worry about, I'd be more concerned with the consistency and the ability to recover an on-line BACKUP than with the prolog ANALYZE /DISK [/REPAIR].

[Guenther Froehlin]

ANALYZE/DISK/REPAIR implicitly locks disk space allocation/deallocation while it is running and eventually repairing things.

While ANALYZE/DISK and the XQP are close brothers when it comes to maintaining the correct FILES-11 on-disk structure, BACKUP is a distant cousin (codewise). With a software structural problem on a disk volume the XQP (file system) very likely bugchecks and ANALYZE/DISK reports/fixes the problem. BACKUP more likely 'stumples' over the problem and may or may not report a problem.

In general I think it is a good idea to run ANALYZE/DISK/REAPIR before a backup. It might fix a problem were BACKUP would have exited with a severe error. Even if such a situation does not occur it wouldn't hurt anyway.

/Guenther

[John Gillings]

Clark,

As Guenther said, it won't hurt (apart from potential impact of locking allocations and deallocations on the volume for the duration), BUT if you're finding that it does repair stuff, it's fairly important to find out what and why.

A "normal" disk under "normal" usage should not accumulate any errors. If you do perform the analysis "in an automated, unattended way", make sure you check the logs, or include a check for errors that sends you mail containing a list of any unexpected messages.

In more recent versions, there's ANALYZE/DISK/LOCK to check a disk without actually repairing it. In older versions you can still ANALYZE/DISK, but becuase it isn't locked it can give spurious results.

A prudent system manager will want to perform periodic checks to detect and correct any sources of data corruption. Incorporating those checks into other periodic activity, like BACKUP, makes sense, even if it's not really related to the backup itself.

[Doug Phillips]

As I said, there's no one way that's right for every situation. If doing ANALYZE/DISK/REPAIR first lets a person sleep better at night, then do it. If doing BACKUP first does, do that.

My "paranoia" learned from lessons taught by experience with Mr. Murphy's Law lets me sleep better knowing I have at least tried a backup before doing anything else.

Thinking "interactive" rather than "automated", if I see a disk that's starting to throw errors, the first thing I do is a backup. I don't do an ANALYZE/DISK or anything else that might further stress the drive. I want whatever I can get from the disk in case/before it fails, even if that's only some percentage of the data. I'll have to see what I have and decide then if it's usable. If the failing disk crashes during the backup, there's a chance it might have crashed during the analyze and I'd have nothing.

If an organization's data is extremely fragile, then there needs to be more than just simple backups protecting it, and if it is properly DT protected by mirror or replication or however, and the data is taken off-line for backup, then do clean-up it up before the backup.

I feel that while ANALYZE/DISK should be run regularly, a /REPAIR should only be done when needed and only after further investigation of any problems reported. (That's a whole 'nother discussion.)

Except for tapes-gone-bad or where there's been backup-path hardware failures (show-stopping SCSI tape drive errors are also an entirely different discussion) I've always been able to restore usable data from a backup -- even ones with verification errors caused by a failing disk. After restoring from a backup, an ANALYZE/DISK is most certainly important. Having data-file verification procedures is also important.

Like I said: Whatever let's you sleep at night. I'm not arguing for everyone to do it either way -- I'm just sharing my experience and saying each organization needs to consider their own circumstances and decide what works best for them.