Using minicopy for backing up data

[Nicolau Roca]

We are running OpenVMS V8.2. We have a three member shadow set, and one of the members is removed daily with the minicopy option (after ensuring data consistency) for backup purposes.

I would like to mount this removed member system wide in order to allow a network backup (mounting the device /over=id does not work, as it remains allocated to the process). Also, it should be mounted write locked to preserve the minicopy bitmap.

Such a mount (mount/system/nowrite) fails as VMS detects it is a shadow member, and I can't find a workaround in the documentation :(

Any suggestions?

Thank you

[Volker Halle · Accepted solution]

Nicolau,

I don't think this will work.

You cannot mount this disk system-wide, as another disk with the same label is already (or still) mounted (the remaining 2-member shadowset).

If you would mount the disk privately and change the label, you modify the shadow generation number and can't bring that disk back into the shadowset without a full copy.

Volker.

[John Abbott_2]

If you're looking to perform multiple backups etc. reading the privately mounted write protected removed member... then the only thing I can think of is for your master pid to mount the disk /over=id and then to spawn/nowait/input=x /... procedures to perform multiple b-up etc. tasks.

Watch you're pgflquota tho.

Your master pid can then wait until your process count = 0 i.e. f$getjpi("","PRCCNT")

Heop this helps
John.

[Jim_McKinney]

> a network backup

Is the code for the network backup in your control (or perhaps it has hooks that you can attach to)? Is there some reason that it couldn't handle a dismount from the shadow set and private mount of the volume just prior to backup and then return the disk to the shadow set when complete?

[Jan van den Ende]

Nicolau,

if there are _NO_ options to have your Backup procedure MOUNT the device (as per Jim's solution), then perhaps this would work:


This is a purely theoretical thought experiment. It has to be tried first in a non-production environment.

Anybody with pertinent info to FORBID or to ALLOW this scenario please chime in.

Anybody with the hard- and software environment to DO this experiment is kindly requested to try.

Would it be possible, _AFTER_ you dismount one member, to do a
$ SET VOLUME/LABEL= for the remaining shadowset, on ALL nodes of the cluster,
Thereafter,
$ MOUNT NOW, clusterwide,
$ SET VOLUME/LABEL=
and mount the dismounted member into the set again?

Or would the SET VOLUME also affect the generation number (Volker??)

Again,
a purely theoretical thought experiment, but my knowledge is unsufficient to validate, nor to INvalidate this scenario; and I have no equipment to test it.
But I am rather curious...

Proost.

Have one on me.

jpe

[Volker Halle]

Jan,

your suggestion does not work: Changing the volume label without re-mounting the shadowset (clusterwide) does not change the volume lock name, so you still get the %MOUNT-F-VOLALRMNT message, if you try to mount the removed member system-wide.

I have tested this.

Volker.

[Jan van den Ende]

Volker,

Thanks for testing.
I am not really very surprised that something or other would prevent my little scheme.
Too bad though that it IS not working! :-(

Oh well, at least now I know (as well as anybody else doing some well-phrased googling).

Proost.

Have one on me.

jpe

[Wim Van den Wyngaert]

If you are unable to modify the backup procedure, you might do the mount of the disk in login.com of the (dedicated) user doing the remote backup (e.g. test if the disk is not mounted and if not, mount it).

Fwiw

Wim

[Nicolau Roca]

Volker, you are right. Just like you said, I cannot mount the disk system-wide as another disk with the same label is already mounted (the remaining 2-member shadowset)

John, I can't see spawnning processes to be a solution for my particular case, as I just need a single backup (performed via network)

Jim, unfortunately I don't have acces to the code of the network backup. It is an external application, so all I have is the executable

Jan, I have already implemented a solution similar to your idea. This is what I actually do: the idea is to overpass the minicopy, and just make use of a full copy to add the 3rd member to the shadow set. The steps are:

1- Add the 3rd member with a full copy
2- Ensure data consistency (in my case by issuing an "ALTER DATABASE BEGIN BACKUP" SQL statement)
3- dismount $device
4- ALTER DATABASE END BACKUP, the database instance continues operating in normal state
4- mount/over=(shadow,id) $device (this zeroes the disk's shadow set generation number, so it eliminates the possibility of using minicopy to add back the member to the shadow set)
5- set volume $device /label=mynewlabel
6- dismount $device
7- mount/system $device mynewlabel
8- ... and I finally can perform a netbackup on $device!!

Now I have a consistent hot backup of the physical data files of a database in the backup server, or at least I think so. And it doesn't matter much waiting a few more minutes for the full copy instead of the minicopy

Thank you all for your help!!

Nicolau

[Jim_McKinney]

If this external backup application is Veritas' NetBackup then you should be able to utilize NBU$START.COM and NBU$END.COM command procedures to accomplish the ancillary work you need to get the state of the target disk in order. If this is some other commercial backup solution posting its name may lead to suggestions from others...