Operating System - OpenVMS
1748283 Members
4020 Online
108761 Solutions
New Discussion

Disk Mount Verification during a backup

 
SOLVED
Go to solution
abrsvc
Respected Contributor

Re: Disk Mount Verification during a backup

There appears to be either a problem with reading the disk itself or there is corruption.  Since the problem shows up with backup, perhaps a physical backup will help here.  At least that will read the blocks WITHOUT interpreting them at all.  This should make an exact copy of the drive.  While this will not address a reading problem, it should allow you to make a copy.  This will give you a back out option by at least having a duplicate disk.  Please note that the copy target drive needs to be an exact match to the source in model and size.

 

If the error messages are changing each time you attempt this, I would suspect a failing drive rather than file corruption.

 

Dan

Steven Schweda
Honored Contributor

Re: Disk Mount Verification during a backup

 
Jeremy Begg
Trusted Contributor

Re: Disk Mount Verification during a backup

Hi Annie,

 

I'd say with some confidence that your DKA100 is faulty.  If you don't see any errors on this disk when VMS is running normally, but only when running you backup procedure, I'd huess that the failed disk blocks are not being touched by your application in normal operation.

 

An easy way to test this is to try running an "online" backup of that disk, i.e. while VMS is running (not booted from the CD-ROM) ...

 

$ MOUNT/FOR MKA600:

$ BACKUP/IMAGE/VERIFY DKA100: MKA600:TEST.BCK/REWIND/LABEL=TEST/IGNORE=(LABEL,INTERLOCK)

 

You will probably see messages about "file is open for write by another user" and maybe "verification error in block ..." but these are expected when you backup a disk which is in active use.  It will be interesting to see if DKA100 goes into mount verification while this backup is running.

 

As has been said earlier, a .DIR;2 file is a problem.  The filesystem is quite happy to create a .DIR;2 file but it will never be treated as a directory: a directory must be a filename ending in .DIR;1.  (There are other attributes also which I won't go into here.)

 

There are all sorts of ways this might come about; I most often see it when an application or software installation creates a temporary or work directory and then tries to rename the new directory to its final name - without first checking to see if another directory of that name already exists.

 

Rather than trying to repair this error using ANALYZE I suggest you simply rename the .DIR;2 file, e.g.

 

$ SET PROC/PRIV=BYPASS

$ RENAME DKA100:[ABC]ORANGES.DIR;2 FREDNURK.DIR;1

 

then see what it contains ...

 

$ DIR/DATE/SIZ=ALL/WID=FIL:30 DKA100:[ABC.FREDNURK]

 

(assuming of course there isn't already a [ABC.FREDNURK] directory!)  You can then decide what needs to be done with the directory and its files.

 

Regards,

Jeremy Begg

 

AnnieLabFish
Occasional Advisor
Solution

Re: Disk Mount Verification during a backup

Thank you all for your help.  The problem is resolved.

 

I tried running an online backup and about 23 minutes into the backup, the tape drive stopped responding and the hard drive light stopped flashing. 

 

I spent yesterday installing the new hard drive.  I was able to restore the drive from a successful backup from 6 months ago.  The only changes on the system were performed a month ago and the files that were changed resided on our development server for the system. 

 

I backed up the server after verifying that it was up to date and the backup performed flawlessly.  The server has been running, in control of the system, for 16 hours with no issue.

 

I looked at the DIR;2 directory and it is an exact copy of the DIR;1 version of itself.  I will be in contact with our vendor as it is a directory that their system uses and the other server in the system has only one copy of that directory.  

 

Thanks again.  All of your troubleshooting suggestions helped immensely and helped me get to the solution.

 

Annie