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...

[Nicolau Roca]

Yes, our external backup application is Veritas' NetBackup. But all I have is a BPCD_STARTUP.COM. This DCL script is run by UCX when a BPCD connection is received.

It runs BPCD_AXP.EXE, so I cannot use it to mount/dismount the target disk, as far as I can see.

Thank you anyway Jim

[Wim Van den Wyngaert]

Nicolau,

Why not ?
If you mount the disk just before the run it should work. Unless it does a run/detached ?
Could you post the .com file (as txt) ?

Wim

[Nicolau Roca]

This is the BPCD_STARTUP.COM file. NBU$BPCD is a logical name in the system table which translates to NBU$DIR:BPCD_AXP.EXE

$ !
$ DEFINE/PROCESS SYS$OUTPUT NL:
$ DEFINE/PROCESS SYS$ERROR NL:
$ !
$ ! Netbackup BPCD startup command file
$ ! run by UCX when it receives a connection
$ ! and the BPCD service is enabled
$ !
$ SET PROC/PRIV=ALL
$ !
$ ! define a logical for the netbackup directory
$ ! (you can specify a directory of your own choice)
$ ! THIS DIRECTORY MUST EXIST - CREATE IF NECCESSARY
$ !
$ !DEFINE/SYSTEM NBU$DIR SYS$SYSDEVICE:[OPENV.NETBACKUP]
$ DEFINE/SYSTEM NBU$DIR SYS$COMMON:[NETBACKUP.FILES]
$ !
$ ! define a logical name for the logs file directory
$ ! (you can specify a directory of your own choice)
$ ! THIS DIRECTORY MUST EXIST - CREATE IF NECCESSARY
$ !
$ !DEFINE/SYSTEM NBU$LOGS SYS$SYSDEVICE:[OPENV.NETBACKUP.LOGS]
$ DEFINE/SYSTEM NBU$LOGS SCI:[SCI$BACKUP.NTLOGS]
$ !
$ ! define a logical name for the executable _VAX.EXE or _AXP.EXE
$ ! THIS EXECUTABLE MUST BE INPLACE FOR THE CLIENT TO RUN
$ !
$ ! find out hardware type....VAX, ALPHA or IA64
$ HW$TYPE="VAX"
$ IF F$GETSYI("NODE_HWTYPE").EQS."ALPH" THEN HW$TYPE="AXP"
$ IF F$GETSYI("NODE_HWTYPE").EQS."IA64" THEN HW$TYPE="I64"
$ !
$ DEFINE/SYSTEM NBU$BPCD NBU$DIR:BPCD_'HW$TYPE'.EXE
$ !
$ ! define a logical name for the BP.CONF configuration file
$ ! THIS FILE MUST EXIST - CREATE IF NECCESSARY
$ ! AND MUST CONTAIN THE LINE:-
$ ! SERVER = your_server_host_name
$ !
$ DEFINE/SYSTEM NBU$CONFIG NBU$DIR:BP.CONF
$ !
$ ! define process only logical names
$ ! sys$output/sys$error catch BPCD runtime errors
$ ! assign to file if runtime errors
$ !
$ ! actually run the correct BPCD image VAX or AXP
$ !
$ RUN NBU$BPCD
$ !
$ EXIT

Whenever I interactively try to mount/over=id the target disk and then run NBU, it raises the error "%NBU-E-OPENERR, error opening for input
-RMS-E-DNR, device not ready, not mounted, or unavailable". So I guess running nbu$bpcd implies a detached process...

[Jan van den Ende]

Nicolau,

the end of your procedure:


$ ! define process only logical names
$ ! sys$output/sys$error catch BPCD runtime errors
$ ! assign to file if runtime errors
$ !
$ ! actually run the correct BPCD image VAX or AXP
$ !
$ RUN NBU$BPCD
$ !


This is where you have some control!

First, there may be some useful displays, if you do not discard them.

$ define sys$error NBU.ERR
$ define sys$output NBU.OUT
( if those filenames are already used, pick any other convenient name)

Now, insert:
$ MOUNT/OVER=ID

I _ASSUME_ that in NBU$CONFIG the target defvices of the backup are specified?
If so, you have to remove the shadow set(s) from there, and replace it/them by the dismounted member spec.

I _ASSUME_ that the "%NBU-E-OPENERR, error opening for input
-RMS-E-DNR, device not ready, not mounted, or unavailable" comes from a specification in NBU$CONFIG that does not reflect the private-mounted disk.

And before you can restore she shadow set, you DISMOUNT the member(s) again.
( well, since you mount them process-private, they SHOULD be dismounted if the process finishes, but I prefer to explicitly do it)



HTH.
Success!

Proost.

Have one on me.

jpe

[Volker Halle]

Nicolau,

you would want to check the Veritas Netbackup documentation for references to 'NBU$START.COM and NBU$END.COM' - as mentioned by Jim. These may just be some kind of prologue and epilogue procedures, which Netbackup can run before and after the backup of the disk itself.

Changing the generic TCPIP service startup command file for Netbackup may cause all other possible problems and side effects.

Volker.

[Nicolau Roca]

Bingo!!

Jim (and Volker) were on the right way, so now I'm afraid I submitted only 8 points to Jim's reply :(

Mounting/over=id the target disk in NBU$START (and subsequently dismounting it in NBU$END, following Jan's advice) works properly!!
So I have rewritten our DCL script as there is no need to mount the target disk system-wide, neither changing its label.

Thanks a lot to Jim and Volker, and also to Jan, Wim and John, for your replys, your advices and your time

I'll be closing this thread in a few days

Regards

Nicolau

[Nicolau Roca]

So I finally can use minicopy :)