- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: Backup Issues
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
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
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
тАО03-18-2008 08:43 AM
тАО03-18-2008 08:43 AM
Re: Backup Issues
This is one of the most arcane and cryptic areas of OpenVMS, and there are very few "blade guards" here; data can get clobbered. BACKUPs can get trashed.
For purposes of a hand-entered BACKUP command, you need not use the logical name on the MOUNT command.
The logical name parameter on MOUNT is useful within a command procedure however, as it can be used as the target for all subsequent device references within the procedure. MYCORP_TARGET and MYCORP_SOURCE could be used as the logical names for the output and input devices, for instance.
The volume label must be the assigned volume label found on the volume, or you must use the MOUNT /OVERRIDE, or you're using (as is often the case) MOUNT /FOREIGN.
Are there any bound-volume sets here?
Again, this area is data-hazardous. Please take the time to read and understand the DCL command syntax, and please consider practicing in a testing configuration where an errant command can trash data without harm to production. Do also look at the BACKUP command examples in the back of the BACKUP manual, as these provide many examples of the various sequences with BACKUP, and you can find and choose the particular command associated with what you want to do.
There are example BACKUP command procedures around that can be used as starting points, as well.
As for another potential hazard here, I see Rdb referenced. (Rdb itself isn't hazardous, but there are specific RMU commands needed to perform a successful and restore-able backup of an Rdb database. You can't use OpenVMS BACKUP directly on an Rdb database and expect to restore the database.)
And FWIW, the existing backup archives here potentially (probably?) contain silent data corruptions, too. (Those file interlocks that are being overridden were implemented for a reason, after all. Not because the engineers wanted to force folks to use another qualifier keyword on BACKUP.)
This whole area is comparatively ancient technology -- and not all that much past what RSX11M+ implemented. The UI and the tools are such that it is accordingly very easy to unintentionally corrupt critical data.
Stephen Hoffman
HoffmanLabs LLC
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-19-2008 08:00 AM
тАО03-19-2008 08:00 AM
Re: Backup Issues
DPA300: (NRCAVB) MntVerifyTimeout 3598 DEVDISK1 3758040 39 1
DPA301: (NRCAVB) MntVerifyTimeout 3598 DEVDISK2 646806 15 1
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-19-2008 08:14 AM
тАО03-19-2008 08:14 AM
Re: Backup Issues
You need to use appropriate $ RAID SHOW commands to find out about the structure of your RAID sets and the physical disks involved.
You can use $ RAID ANALYZE/ERROR_LOG to find RAID-related errlog entries.
There should also be a SYS$MANAGER:RAID$DIAGNOSTICS_nodename.LOG file with diagnostic messages.
Volker.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-19-2008 08:20 AM
тАО03-19-2008 08:20 AM
Re: Backup Issues
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-19-2008 09:40 AM
тАО03-19-2008 09:40 AM
Re: Backup Issues
All the units have had a lot of errors reported against them.
Please look at the diagnostics file mentioned earlier and try to find out what happened when.
The HP RAID Software for OpenVMS - Guide to Operations can be found here:
http://h30266.www3.hp.com/odl/vax/sysman/raidv30/raid_ops_guide.pdf
You will at least need to dismount the DPA: devices, which are in MntVerifyTimeout, then re-mount them with the MOUNT commands to be found somewhere in your system startup procedures. But first try to find out what happened.
Consider to obtain qualified help to prevent damage to your data, if you're uncertain what to do...
Volker.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-19-2008 10:34 AM
тАО03-19-2008 10:34 AM
Re: Backup Issues
%SEARCH-I-NULLFILE, file SYS$SYSROOT:[SYSMGR]ADDOPER.COM;2 contains no records
%SEARCH-I-NULLFILE, file SYS$SYSROOT:[SYSMGR]ADDSYS.COM;2 contains no records
I got this error when I attempted to remount.
******************************
SYS$SYSROOT:[SYSMGR]NRC_MOUNT_DISKS.COM;21
$ Mountxx/noass/sys/rebuild DPA302: DEVSCRATCH1 DEVSCRATCH1
******************************
SYS$COMMON:[SYSMGR]SYSHUTDWN.COM;18
$ dismountxx/abort/over=check DISK$DEVSCRATCH1 !dpa302:
$ Mountxx/noass/sys/rebuild DPA302: DEVSCRATCH1 DEVSCRATCH1
%MOUNT-F-MEDOFL, medium is offline
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-19-2008 10:43 AM
тАО03-19-2008 10:43 AM
Re: Backup Issues
Can you currently access DPA300: and DPA301: without problems ? Is only DPA302: giving you problems ?
Did you look at the drives behind the Mylex controller. Any yellow or red lights ?
Volker.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-19-2008 10:53 AM
тАО03-19-2008 10:53 AM
Re: Backup Issues
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-19-2008 11:04 AM
тАО03-19-2008 11:04 AM
Re: Backup Issues
As you are using a partitioned RAID 0 stripeset, the failure of ANY physical DRA disk will cause the whole array to become inoperative !
First make sure to check for your last GOOD backup of these 3 DPA: devices !
Volker.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-19-2008 01:58 PM
тАО03-19-2008 01:58 PM
Re: Backup Issues
If that succeeded do a RAID UNBIND
Did all DRA devices dismount? If not issue DISMOUNTs for the DRA devices not dismounted yet.
Mount all DRA devices with MOUNT/OVER=ID/NOASSIST. If that fails...fix a DRA underlying problem.
If that worked for all DRA devices dismount them and do the RAID BIND command (parameters are somewhere in SYSTARTUP:*.COM - hopefully).
/Guenther