How to copy a save set on magnetic tape to a disk?

[Andy Bustamante]

As discussed by Volker and Shriniketan, the supported BLOCK size on tape is larger than on disk.

There is a layered product, SAVE SET MANAGER which will copy backup save sets and allow adjusting the block factor. Save Set Manager requires additional licensing.

[John Gillings]

Also note...

I recall that (for reasons opaque to mere mortals) copying savesets directly from magnetic tape using COPY is NOT supported.

I've never heard of it actually failing, but apparently the possibility exists, even apart from the block limits. YMMV, but don't complain if it doesn't work.

The supported mechanisms are BACKUP and SAVE SET MANAGER.

[John McL]

Further to JG's comment, from the start of chapter about Backup in the Sys Mgr Utils Manual Part 1 ..."(A save set stored on a Filesâ 11 disk is a standard OpenVMS file, however, and can be copied, renamed, deleted, or backed up. A save set stored on magnetic tape should only be processed with the BACKUP command; do not use the DCL command COPY to copy a magnetic tape save set to disk.)"

Also ... "By default, BACKUP treats an input or output specifier referring to a Filesâ 11 disk as a file specification. Therefore, to identify a save set on a Filesâ 11 volume, you must include the /SAVE_SET qualifier with the specifier (see /SAVE_SET). BACKUP treats input and output specifiers referring to magnetic tape as save sets."

In case you are tempted to try $ BACKUP :XXX.SAV :XXX.SAV/SAVE (i.e. using Backup to copy the saveset onto the disk) the documentation says ..."You cannot specify a save set for both the input and output specifier of a BACKUP command. For this reason, you cannot perform a BACKUP operation from one magnetic tape to another."

[Steven Schweda]

> I recall that [...]

My dim (possibly defective) recollection is
that this had something to do with BACKUP's
sophisticated error handling, which might
cause it to rewrite some blocks to a tape in
ways which would confuse COPY.

> I've never heard of it actually failing,
> [...]

Nor I, but I haven't done it in recent years.
Can't recall having seen a tape write error
in a long time, either.

The biggest problem I ever had was doing any
tape copying as user SYSTEM, whose default
directory involves a search-list logical
name, causing everything to get done twice.
(Pain in the butt with a TK50. (As I said,
it's been a while.))

[P Muralidhar Kini]

Hi John,

You are right. The OpenVMS System manager's Utilities manual does say that
the saveset present on tape should be copied to disk using the BACKUP
command and not the COPY command.

Its a long time since I have played around with the savesets on tape.
I did not have to copy savesets from tape to disk many times but on occassions
when I had to, I remember getting in trouble when I did a MOUNT/OVER=ID of
the tape followed by a DIR and COPY command. I used to think that the
problem might be with the tape. But then when i do a MOUNT/FOR and use the
BACKUP command it used to work. The BACKUP command would
successfully copy the saveset from tape to disk.

>> $ BACKUP :XXX.SAV :XXX.SAV/SAVE
May be this command needs a slight change.
Since we only have to copy the saveset from the tape to disk, i dont think the
/SAVE qualifier is required at the destination. In general, for the BACKUP,
if it should perform a copy operation then the "/SAVE" is not required in the
source or destination.

So the command for FOX2 would be -
$ MOUNT/FOR
$ BACKUP :XXX.SAV :XXX.SAV

Regards,
Murali

[Shriniketan Bhagwat]

Hi,

I did a small test and below are the results.
I created a saveset on tape and copied it to disk through BACKUP. When I tried to list the saveset on disk, it gave me the error %BACKUP-F-NOTSAVESET. I tried to repair the saveset but of no use. Then I used DCL copy command to copy the saveset from tape to disk and its working. Please refer the attached log for more details.

Regards,
Ketan

[Jon Pinkley]

Ketan,

Your test wasn't doing what you thought it did; it didn't copy the saveset to disk.

From your test:
-------------------------
$ backup/log PHYSICAL.LIS;2 $2$MGA5:test.bck/save/ignore=label
%BACKUP-S-COPIED, copied SYS$SYSDEVICE:[BACKUP]PHYSICAL.LIS;2
$
$ backup/log/rewind/ignore=label $2$MGA5:test.bck []test.bck
%BACKUP-S-CREATED, created SYS$SYSDEVICE:[BACKUP]TEST.BCK;2
$ dir test.bck

Directory SYS$SYSDEVICE:[BACKUP]

TEST.BCK;2

Total of 1 file.
$ backup/list SYS$SYSDEVICE:[BACKUP]TEST.BCK;2/save
Listing of save set(s)

%BACKUP-F-NOTSAVESET, SYS$SYSDEVICE:[BACKUP]TEST.BCK;2 is not a BACKUP save set
-------------------------


The command: $ backup/log/rewind/ignore=label $2$MGA5:test.bck []test.bck

is restoring PHYICAL.LIS;2 from the test.bck saveset to a specified file name []TEST.BCK

The version ;2 is coming from rms parsing from PHYICAL.LIS;2

$ set def sys$sysdevice:[backup]
$ write sys$output f$parse("TEST.BCK","[]PHYSICAL.LIS;2")
SYS$SYSDEVICE:[BACKUP]TEST.BCK;2
$

If you would have issued the command:

$ differences physical.lis;2 test.bck;2

you would have gotten


Number of difference sections found: 0
Number of difference records found: 0

DIFFERENCES /IGNORE=()/MERGED=1-
SYS$SYSDEVICE:[BACKUP]PHYSICAL.LIS;2-
SYS$SYSDEVICE:[BACKUP]TEST.BCK;2
$

If the save set would have had more than a single file in it, what was happening would have been more obvious.

Backup is powerful, but it isn't always obvious what a command is doing.

Jon

[Shriniketan Bhagwat]

Hi,

Yes Jon, you are correct.

Regards,
Ketan

[Volker Halle]

As far as I recall, continuation tape handling, which could be different between BACKUP and COPY, could also be a problem and may be a reason, why COPYing savesets from tape is not supported.

Volker.

[Jon Pinkley]

FOX2,

As Ketan demonstrated, the commands that were given by Murali,
------------------
$ MOUNT/FOR
$ BACKUP :XXX.SAV :XXX.SAV
------------------
do not copy a saveset from a tape device.

BACKUP treats files on tape devices as savesets. It is implicit; when the device (either source or destination) is a tape device, the /SAVE_SET is implied.

The only way to duplicate backup savesets using backup is to extract the contents to files, and then recreate a new backup saveset from the restored files.

Backup does not allow savesets as both source and destination in the same operation.

That is why Save Set Manager was written.

Copying saveset does not work in the general case, but if the blocksize is under the RMS max, and the saveset was created on a modern tape drive that has error correction built in (DLT, LTO), then you can probably get away with copying the savesets.

You should verify that the savesets can be processed by backup after they are copied. Backup/list=temp.file (or even nl:) will verify the consistency.

See Tape to Tape copy

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

for a list of requirements that must be met to be able to copy a saveset from tape mounted with the magtape ACP. (i.e. mount without /foreign).

You may also want to see the following threads:

Restore SAVESET from tape

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

Saveset blocksize on tape to allow COPY to disk

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

Jon