Directory listing of a Multi volume encrypted tapes on OpenVMS 8.3 integrity server

[vikasyadav]

I have a full data backup for an openvms 8.3 server integrity server on two tapes that are encrypted.  If I mount the first volume and try to do a directory listing the process goes on indefinately; without giving any output and eventually I have to kill the process. e.g.

DEV_DAISY> sh dev mk

Device                  Device           Error    Volume         Free  Trans Mnt

Name                   Status           Count     Label         Space Count Cnt

PLUTO$MKC200:           Online               0

DEV_DAISY> mount PLUTO$MKC200: dat801

%MOUNT-I-MOUNTED, DAT801 mounted on _PLUTO$MKC200:

DEV_DAISY> dir PLUTO$MKC200:[000000]

The process goes on indefinately at this point.

However If I mount the second volume and do a directory listing, It executes and gives me the required output as :

Directory PLUTO$MKC200:[]

DAT801.BCK;1 294976 31-MAR-2015 00:00:00.00

Total of 1 file, 294976 blocks.

I want to ask is it possible to do a directory listing on first volume of an encrypted tape. If not; is it possible to read tape header information from the first volume of an encrypted tape (i.e saveset name and date on which backup was taken) without specifying the encryption key.

[Hoff]

BACKUP encryption should not be particularly involved here, as that is a file or saveset-level operation, and not volume-level operation — I'd expect unencrypted savesets would show the same behavior.

Are your operator consoles receiving any OPCOM messages, with MOUNT requesting volume switches?  I'd expect to encounter these messages here.  As a quick test, REPLY /ENABLE to turn on all requests, or maybe REPLY /ENABLE=(TAPES) or such to reduce the numbers of OPCOMs arriving.

...If not, then I'd consider this a bug, and you'll want to report it to HP.

...If there are OPCOM messages requesting the media swappage, then please load the continuation volume when requested by OPCOM, and use REPLY /TO or (usually) allow the automatic completion of the requested swap.

The interaction of MOUNT and OPCOM here is quite primitive by present-day standards, but it does usually work.   For details on what I'd expect to happen here, please see the documentation for REPLY /ENABLE, REPLY /TO, MOUNT /ASSIST and related DCL commands, as well as the volume-related details in the System Manager's manual.

[Volker Halle]

Please note that a DIRECTORY command on a tape volume only reports the files after completely reading them, i.e. after the end of the file. This might explain, why you 'never' get a file name displayed, if the file continues on a continuation volume and if multi volume handling does not seem to work.

Does the DIRECTORY command continue to do IOs (type CTRL-T) or is it stuck ? Maybe waiting for the TAPE OPERATOR to load the 2nd tape volume ?

You can easily DUMP the 4th block from a BACKUP tape and you will be able to see the BACKUP header (look at the first 512 bytes):

$ MOUNT/FOR MKC200:

$ DUMP/BLOCK=(START:4,COUNT:1) MKC200:

Volker.

[H.Becker]

>>> I want to ask is it possible to do a directory listing on first volume of an encrypted tape. If not; is it possible to read tape header information from the first volume of an encrypted tape (i.e saveset name and date on which backup was taken) without specifying the encryption key.

Yes, there is a tool to do that: bcksum.

$ init lma9: label
$ mount/for lma9:
%MOUNT-I-MOUNTED, LABEL mounted on _SEMMEL$LMA9:
$ backup login.com lma9:x.bck/ignore=label/encr
Enter key value: 
Verification: 
$ dism/nounl lma9:
$ mount/for lma9:
%MOUNT-I-MOUNTED, LABEL mounted on _SEMMEL$LMA9:
$ backup lma9:/list
Listing of save set(s)

%BACKUP-F-ENCSAVSET, save set is encrypted, /ENCRYPT must be specified
$ backup lma9:/list/encrypt
Enter key value: 
 Interrupt 

$ reca dism
$ dism/nounl lma9:
$ mount/over=id lma9:
%MOUNT-I-MOUNTED, LABEL mounted on _SEMMEL$LMA9:
$ bcksum lma9:x.bck
Backup summary from OpenVMS backup savesets, V0.9.3
Save set:          x.bck
Written by:        HARTMUT     
UIC:               [000100,000100]
Date:              11-AUG-2015 18:37:54.40
Command:           ******
Operating system:  OpenVMS Alpha version V8.3
BACKUP version:    V8.3
CPU ID register:   80000000
Written on:        _SEMMEL$LMA9:
Block size:        8192
Group size:        10
Buffer count:      124
Saveset Encrypted
$ 

[Hoff]

---

@H.Becker wrote:

$ backup lma9:/list
Listing of save set(s)

%BACKUP-F-ENCSAVSET, save set is encrypted, /ENCRYPT must be specified
$ 

---

That's a bug.   BACKUP should still dump the tape header — even if it can't list the contents — and then "fatal" out.  It'd be be nice if there was a way to just dump out the BACKUP header, and not the contents — akin to what that bcksum tool does.  But that's fodder for another time.

[H.Becker]

>>>That's a bug. BACKUP should still dump the tape header — even if it can't list the contents — and then "fatal" out.

Requiring the encryption key looks like a feature: the command in the header is encrypted as well (that sort of explains the *s in the output of bcksum). But to me it looks like FATAL is not the appropriate severity level. Printing all the unencrypted data and exit with a WARNING seems better, here. On the other hand, it looks unusual to ask for key validation in case of decryption as in /LIST /ENCRYPT (and one can argue that the qualifier should be /DECRYPT, here).

>>>It'd be be nice if there was a way to just dump out the BACKUP header, and not the contents — akin to what that bcksum tool does. But that's fodder for another time.

From the website where you can get bcksum, for Linux, Windows and VMS: "This tool is useful if you only need/want to see this meta information where the OpenVMS BACKUP utility with /LIST shows too much. (On VMS, users then usually press ^Y to stop backup processing.) Obviously it is just a SMOP to implement such a functionality within BACKUP itself. As long as that isn't available this tool may be of some use, even on VMS."

[Hoff]

>>It'd be be nice if there was a way to just dump out the BACKUP header, and not the contents — akin to what that bcksum tool does. But that's fodder for another time.

From the website where you can get bcksum...

---

I'm familiar with the topic.   I was referring to using BACKUP here, not an add-on.  (But then I find BACKUP is a quagmire of confusion for most users, and with more than a few issues — not the least of which are an utterly befuddled user interface, more than a few missing capabilities, and it's all based on an archival strategy that fundamentally doesn't scale.)