- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Disk Mount Verification during a backup
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-12-2012 03:39 AM
06-12-2012 03:39 AM
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-12-2012 05:18 AM
06-12-2012 05:18 AM
Re: Disk Mount Verification during a backup
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-13-2012 09:12 PM
06-13-2012 09:12 PM
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-14-2012 04:31 AM
06-14-2012 04:31 AM
SolutionThank 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
- « Previous
-
- 1
- 2
- Next »