Tape to Tape copy

[Kevin Raven (UK)]

Hi ...Quick question ....

We have a two node cluster running OpenVMS 7.3-2 on both servers.

I have remote operators on a cluster I don't manage , telling me they want to duplicate a tape.
The tape have 8 savesets on it.

They are convinced that the following instructions have been run in the past and worked.
I don't agree ....
Unless I'm missing something ...this will not work ...

The commands they intend to run are as below ...

Performing a tape to tape copy:

Place the original BC backup tape back into
NODE01 then do the following from NODE01::
NODE01>MOUNT/OV=ID NODE1$MKB600:

Put a blank SDLT into NODE02 and do the following on node NODE02:
NODE02> INIT NODE02$MKB600: TAPE2
NODE02> MOUNT/OVER=ID NODE02$MKB600:

Then from NODE01 only do:
NODE01> COPY/LOG NODE01$MKB600:*.*;* NODE02"USER1 PASS1"::NODE02$MKB600:[]

Input welcome ....

Thanks

[Hoff · Accepted solution]

This stuff never worked reliably, and the success depended on various factors including tape errors and block sizes.

The TAPECOPY tool or the Saveset Manager product are the usual tools, or the hosts are clustered, or (where there's a SAN or such) the tapes are served via SAN.

Here's an older write-up on this area:

http://labs.hoffmanlabs.com/node/810

[Andy Bustamante]

Saveset Manager works very well for creating duplicates of VMS backups. We use that to create off site tapes copies.

Just curious, if HP added encryption support to Saveset Manager would there be more interest in the product?

Andy Bustamante

[Volker Halle]

No, this doesn't work. Apart from the possible problems mentioned by Hoff, you cannot access a mounted tape via DECnet. You would need to put the MOUNT command into LOGIN.COM of USER1 on NODE02 and execute it in F$MODE().EQS."NETWORK" - not a good idea !

I had once written auf COPYTAPE program doing QIOs with an option of forwarding the QIOs via a DECnet API to another node, this worked fine, so it can be done.

Volker.

[marsh_1]

..or you can use products like thruway for remote tape, but otherwise agree with the other guys here.

[Jon Pinkley]

For TAPE to TAPE copy of savesets, if both tapes drives can be seen from the same node, then the basic procedure below will work with some restrictions:

The tape label, etc. are not copied, only the savesets, so things like tape protection and expiration must be done when the target tape is initialized.

The input tape must not have any savesets with blocksize greater than 32256.

All savesets must be completely contained on a single tape. Continuation volumes will not work.

The output tape must be able to hold all the savesets to be copied without reaching the end of tape.

The destination tape drive must hide any media write errors, i.e. if there are any write errors, the operation stops.

The source tape drive must present perfect data to copy, i.e. if there are read errors, the operation stops. This also implies that the original backup must not have left any bad records on the tape, i.e. either created with BACKUP/INTERCHANGE or written with a tape drive that hides media write errors.

$ mou/ov=id/nowrite/nounload tape1:
$ init tape2: label /own=... /prot=... /media=...
$ mou/ov=id/nounload tape2:
$ copy/log tape1:*.* tape2:*.*
$ dism tape2:/nounload
$ dism tape1:/nounload
$ mou/for tape2:/nounload
$ backup/list[=outfile] tape2:*.*

In a cluster, the remote tape could be TMSCP served, and that is more transparent than FAL, but not everything that works for a locally connected drive will work for a TMSCP served device.

TAPECOPY has fewer restrictions (most notably it will duplicate the tape volume header, and it will handle blocksizes up to 65024. But it still is limited 1 tape to 1 tape operation.

Another question, what does Save Set Manager's SSMgr Validate do that backup/list doesn't?

From the article Hoff referenced in http://labs.hoffmanlabs.com/node/810 under Saveset Manager

http://h71000.www7.hp.com/openvms/storage/ssmpage.html


--------------------------------------------------------------------------
SSMgr Validate

This function validates the internal consistency of a specified save set. This is very useful if you have older tapes with critical backups on them. SSMgr Validate can tell if the tape has bad blocks, can identify those blocks, and can determine if that data can be recovered by using the CRC and XOR information. If it can, the SSMgr Copy function recovers the data as it copies the save set to another tape.
--------------------------------------------------------------------------

Sounds very similar to what backup/list does, except that backup list also creates a listing of what is on the tape. Also, I can't understand why you would perform a validate of "older tapes with critical backups on them" instead of just using SSMgr Copy to move to newer media. If the data can't be recovered, you will find out during the SSMgr Copy, and you won't put extra stress on the "older tapes with critical backups".


Jon