- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: Shadowing on a system disk.
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
тАО11-12-2009 03:35 AM
тАО11-12-2009 03:35 AM
Shadowing on a system disk.
I've recently been made responsible for a DS25 running openvms 7.3. The system disk in this machine 'was' shadowed.
Originally, two disks (DKA0 and DKA100) were in the shadowset DSA0:. Now, DKA100 is the only member of the DSA0 shadowset. It turns out the phsyical disk DKA0 was dead and has been for some time. I'd like to restore that shadowset.
I've replaced the physical disk with an identical disk (i.e. exact same disk, plugged into the spot from which the old DKA0 was removed). I can mount the new DKA0, copy files to it, verify it's working etc.. However when i try to re-add it to the DSA0 shadowset using:
mount/system dsa0: /shadow=($1$dka0:) alphasys
The shadow set attempted to merge but clocked up a large number of errors. I've been using the "Volume Shadowing for OpenVMS" manual as a reference, but have yet to spot what I'm doing wrong.
It appears to me that shadowing the system disks is a 'special case' (as the systartup_vms.com does not explicitly mount the system shadowset on startup, rather OpenVMS just knows to do this). Is there a particular sequence of actions required to rebuild this system shadowset with a new disk?
Thanks and regards.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-12-2009 03:45 AM
тАО11-12-2009 03:45 AM
Re: Shadowing on a system disk.
The systemdisk is a special case during booting, but when the system us up and running adding and removing members from the shadowset is done as with data disks.
regards Kalle
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-12-2009 03:48 AM
тАО11-12-2009 03:48 AM
Re: Shadowing on a system disk.
welcome to the OpenVMS ITRC forum.
OpenVMS shadowed system disks do NOT need to be mounted in SYSTARTUP_VMS.COM, because OpenVMS will form the system disk shadowset with the same members as existed prior to the boot.
Your mount command is correct. I prefer to always use /CONFIRM when doing manual MOUNTs. This will tell you the label of the disk to be added - and overwritten - and still allows you to say NO, if you had specified the wrong disk.
The shadow set attempted to merge ...
The operation you've described is called a SHADOW COPY, not a MERGE. During a shadow-copy all blocks from the existing members are copied to the new member. A MERGE compares all blocks of all members and only updates blocks, which were different by copying it from the 'master member'.
Did you look at the errors being reported ? You will need DECevent (DIAGNOSE) or WEBES (SEA) to do this.
Try an INIT/ERASE DKA0: SCRATCH first, this will write to all blocks of the new disk and should report any problems at that time. This operation will take a while.
Volker.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-12-2009 04:12 AM
тАО11-12-2009 04:12 AM
Re: Shadowing on a system disk.
$ Init/Sys $1$DKA0: ALPHASYS
(label is actually irrelevant). It is possible that the new disk is not actually "New". However, the fact that the disk is accepted into the shadowset and begins to copy, suggests that you used the correct commands, and that the problem is more likely with the new disk.
Anyway, as requested by Kalle, it would be best to cut and paste the actual error messages.
Dave
Dave.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-12-2009 04:18 AM
тАО11-12-2009 04:18 AM
Re: Shadowing on a system disk.
First off, yep, I'm 100% clear that "OpenVMS shadowed system disks do NOT need to be mounted in SYSTARTUP_VMS.COM". That's as per what I've read and my/your comments above.
:) Thanks for the note on /CONFIRM - I had actually used that myself. I too like the assurance of getting the target of the copy confirmed.
Apologies if I was loose with my terminology ('use of merge instead of copy'). You are correct, I am referring to the initial copy when adding a new member to the DSA0: shadowset.
Yup - I initialised the disk (a couple of times!) while playing with it.
I'll go and use DIA to dig out the exact errors from day I first tried this and then post them in short order.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-12-2009 04:21 AM
тАО11-12-2009 04:21 AM
Re: Shadowing on a system disk.
did you do just an INIT DKA0: label or did you also use /ERASE - that makes a big difference here...
Volker.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-12-2009 04:31 AM
тАО11-12-2009 04:31 AM
Re: Shadowing on a system disk.
Copy, not merge, right? Errors on the source or destination disk? If the source disk has forced error flags set on any blocks those will need to be remedied prior to any shadow copy. In any case, you'll probably want to use one of the error log translation tools (DECEvent, WEBES, etc) to decode the event.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-12-2009 04:44 AM
тАО11-12-2009 04:44 AM
Re: Shadowing on a system disk.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-12-2009 05:37 AM
тАО11-12-2009 05:37 AM
Re: Shadowing on a system disk.
Just a small note of clarification. SYSTARTUP_VMS.COM is not the only possible place where a MOUNT can be placed.
The case of the system residence volume is indeed special, and all of the command files invoked during the startup are indeed not germane, however in other cases, it does make a great difference.
- Bob Gezelter, http://www.rlgsc.com
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-12-2009 06:13 AM
тАО11-12-2009 06:13 AM
Re: Shadowing on a system disk.
I actually find it preferable to use BACKUP and make a /PHYSICAL copy of the source disk onto the target, follow that with an INITIALIZE or MOUNT/OVERRIDE=SHADOW to destroy the SCB, and then initiate the shadow copy. Shadow copies then are much faster as the majority of the data on the target disk will not have to be updated and the initial copy was performed with no decision making code involved.