Operating System - OpenVMS
1748010 Members
4393 Online
108757 Solutions
New Discussion юеВ

Re: Data Protector and removed Shadow Set members - Catch 22

 
Art Wiens
Respected Contributor

Data Protector and removed Shadow Set members - Catch 22

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
14 REPLIES 14
Bill Hall
Honored Contributor

Re: Data Protector and removed Shadow Set members - Catch 22

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
Bill Hall
Art Wiens
Respected Contributor

Re: Data Protector and removed Shadow Set members - Catch 22

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
Respected Contributor

Re: Data Protector and removed Shadow Set members - Catch 22

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
Honored Contributor

Re: Data Protector and removed Shadow Set members - Catch 22

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
Bill Hall
EdgarZamora_1
Respected Contributor

Re: Data Protector and removed Shadow Set members - Catch 22

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
Respected Contributor

Re: Data Protector and removed Shadow Set members - Catch 22

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

Re: Data Protector and removed Shadow Set members - Catch 22

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
Respected Contributor

Re: Data Protector and removed Shadow Set members - Catch 22

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
Honored Contributor

Re: Data Protector and removed Shadow Set members - Catch 22

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
it depends