Data Protector and removed Shadow Set members - Catch 22

[Art Wiens]

Surely someone smarter than me has solved this problem before ...

Just getting started setting up backups using DP (v5.5) and my new Alphas. My plan is to dismount one of the three members in a Shadow Set, have Data Protector back it up and then add the member back into the Set. I thought it would be "simple" to have a DP pre-exec command procedure mount the removed member at the start of the backup. Turns out, a seperate VMS DP process does the pre-exec procedure (mounts the drive) and exits (dismounting the drive as it leaves!) The subsequent DP process which will do the backup finds the device "not ready" and fails.

So then the catch-22 is, the removed shadow set member has the same volume name as it's original shadow set and the drive can't be mounted "system-wide", but from what I can see, DP can't keep the drive mounted privately.

Suggestions?

Cheers,
Art

[Bill Hall]

Art,

Mount the split shadow member /override=(identification,shadow_membership). Then $set volume ddcu:/label=. Dismount and then mount/group or mount/system. Unfortunately, you'll end up with a full shadow copy when you add the member back into the shadow set.

I know that TAPESYS will allow you to mount a split shadow set member privately in at least one of their supported pre-processing levels. Multiple post-processing levels available to re-add the member back into the shadow set also.

Bill

[Art Wiens]

I thought about the /over=shadow (or even maybe changing the volume label), but I'm not sure that that is the "right thing to do". Avoiding a full copy for all the shadow sets involved would be "desirable".

Cheers,
Art

[Art Wiens]

What I'm hoping for (but didn't come right out and say) is that there might be a DP solution to this ... ie. why does it have to run a seperate VMS process to do the pre-exec procedure?

Cheers,
Art

[Bill Hall]

Art,

Duh! I might have over thought my first answer. Why can't you use $Mount/group without changing the volume label? Mount defines the DISK$volume_label in the group table and the volume is not dismounted when the mounting process goes away. If you run DP with under a user account with a unique user group, none of the other users on the system will be able to "see" the second DISK$volume_label logical name and access it by "accident" (only a potential factor if you reference files using the DISK$volume_label logical name).

Bill

[EdgarZamora_1]

I haven't tested this so I'm not sure it will work...

Forget the pre-processing. Create a DCL procedure that will dismount your shadowset member, mount it privately, then issue an omnib -data command to fire off the backup specification. If you're lucky, the omni processes that will do the actual backup will be subprocesses of this process. If they can't get to the privately mounted disk then I guess they are separate processes and you're stuck with mounting the member with an override=shadow and incurring a full shadow copy when returned to the shadowset.

If you want a sample DCL script of an omnib backup let me know.

I will test this out when I get a chance. I run DP version 6 on my VMS systems but my disks aren't shadowed. I'll have to turn on hbvs on a test system to test this.

[EdgarZamora_1]

I think Bill's idea has some merit. I was thinking about that too (/GROUP). Good luck.

[EdgarZamora_1]

I quickly tested the MOUNT/GROUP idea and for some reason (that I haven't given thought to yet) the mount is failing when another disk with the same label is already mounted system-wide... even though I used a different group number.

[Art Wiens]

Bill, you really got my hopes up for another "simple" solution, but alas:

$ mount/group $1$dga307: eva_prod1
%MOUNT-F-VOLALRMNT, another volume of same label already mounted

Art

[Jon Pinkley]

See the following thread. It doesn't talk about Data Protector, but Veritas' NetBackup, but perhaps you have some control over what gets done in the command procedures that Data Protector uses.

http://forums12.itrc.hp.com/service/forums/questionanswer.do?threadId=1054171

I know very little about Data Protector. I would have expected it to allow you to have one procedure to make a clean shutdown of applications and a dismount (preferably with /policy=minicopy) of the third member of the shadow set. A second procedure would run at the time the tape drive became available, and this is where you should mount the disk privately (but avoiding the use of /override=shadow, since that eliminates your ability to have the member return to the shadow set without a full copy operation), and then backing up the read-only disk with /NORECORD. Not writing the backup dates to the removed member isn't a big loss, since any changes you would have made would have been erased when the member was reintroduced into the shadow set, e.g. if you would have used /over=(id,shadow) and then mounted the disk with write access, you could have recorded the backup dates on the removed member, but the record dates really belong on the shadow set that the member was removed from. After the backup completes, this same procedure can remount the member into the shadow set, and as long as the node with the master copy of the write bitmap has not shutdown/crashed, the removed member should normalize much quicker than if minicopy were not available.

The above thread also discusses the problems with having multiple volumes with the same label.

Jon

[Art Wiens]

Bill, while your suggestion re: mount/group didn't work out, it did trigger the memory of when mounting a disk "privately" others within the same group could access it. (Perhaps this is specific to the [1,*] group? ... but that's ok because the OMNIADMIN account created by the DP client install is [1,500].) So if [1,x] account mounts the removed shadow set member "privately", the drive is available to OMNIADMIN for backup!

Just a bit different than what I wanted to code for, but should be fine.

Thanks,
Art

[Jon Pinkley]

Art,

Does the OMNIADMIN account have SHARE privilege? The only special privilege I remember that UIC groups LE the value given to the SYSGEN parameter MAXSYSGROUP get is SYSPRV. The default value of MAXSYSGROUP is 8(decimal), and that is why we have MAXSYSGROUP set to 1. Processes with SHARE privilege may assign channels to non-shared devices, so I am guessing that is the mechanism at play.

Jon

[infra-sanfunc]

Migrating ABS/MDMS OVMS backup to DP 6.0

Short description of current situation MDMS/ABS full backup on 4 node VMS cluster with shadowdisks.


- Starting ABS/MDMS backup specification
- Pre: shutdown databases
dismount second shadowset members (/policy=minicopy)
startup databases
mount private second shadowset members
- Backup second member
- Post: dismount second member
mount second member (/policy=minicopy)

To get the same functionality with the use of DP6.0 and to avoid a full copy operation as decribed in this case we used the following solution:

- create backup specification with Pre and Post (Pre: shutdown DBâ s, dismount second member, startup DBâ s. Post: not used)
- add for each disk (object) a Pre and Post (*1) (Pre: mount private, Post: dismount, mount / cluster / minicopy)
- modify job specification setting â file system options / otherâ select: .

* 1:
Both object Pre and Post string have a which relates to the second member. This usable option is not mentioned in documentation, but very handy. E.g. get_disk.com $1$DGA2010: , free_disk.com $1$DGA2010:


Modify the OVMS OMNIADMIN user privileges to:
BYPASS CMKRNL DIAGNOSE NETMBX PHY-IO SETPRV
SHARE SYSNAM SYSPRV TMPMBX VOLPRO

This method did solve several issues described in this case

By default the backup specification type is named â Filesystem Unixâ . In the Help text regarding â objects propertiesâ the use of is referred to as a Unix option, but this is also effective for VMS to avoid write error log messages.

As mentioned this is a short description without full context of the VMS qualifiers and used scripts.


Best regards,
Gerke Grashuis
Harry de Jong

[Art Wiens]

"- add for each disk (object) a Pre and Post (*1) (Pre: mount private, Post: dismount, mount / cluster / minicopy)"

Unless v6 is different, are you refering to the Filesystem Options | Advanced window? This doesn't appear to be a per disk setting, but the help says it runs before/after each "backup object" which I assume is each disk that I have checked off on the previous window? So one common procedure that runs for each disk. What kind of logic am I to put in there? I think it's the same situation where it's not the same process backing up each disk, so different processes will run the same pre and post procedures.

Hmmm,
Art

[infra-sanfunc]

Sorry for the delay. Last Friday the siet was off-line.

When configuring the backup specification you will find in Backup Object Summary the scanned disks.
Rightclick on disk, Properties, select Options.
This is the place to enter the Pre / Post for each disk (object) including the parameter. (note *1)
So each disk (object) has its own process due to the subbision of .

Recapitulate:
In pane Backup specification / options / general, you have Pre and Post for the overall backup (stop DB etc.)
In the pane mentioned above you have the specific Pre and Post for the object.
The creating of the scripts is very system specific so I cannot give comment on that.

Harry de Jong