[VMS backup] tapes not copyable by dd???

[Steve Summit]

In article <184 at larry.sal.wisc.edu> jwp at larry.sal.wisc.edu (Jeffrey W Percival) writes:
>I have a 6250BPI reel-to-reel tape made by the VMS backup program.  VMS
>folks call it a "saveset" tape.  I can't seem to copy this tape onto a
>TK50 with Ultrix.  dd appears to do the job, but when the resulting tape
>is subjected to the uunet-archive program "vmsbackup", it says "end of
>tape" right away.

A backup saveset is not one tape file, but three (or so [1]).
Tapes written by backup are ANSI-labeled tapes, including file
headers and trailers.  Each save set ends up as one labeled
"file" on the tape (but note that a "labeled file" is implemented
as more than one tape-mark-delimited tape file -- ignore this
distraction if you're not interested in ANSI labeled tape
formats.)  A typical save set might look like

	file	recsize	    nrecs	what

	1	80	    3 [2]	header
	2	8192 [3]    *		contents
	3	80	    2		trailer

The "contents" are the actual backed-up information, including
extensive internal structure recording file types, ownership,
file times, redundancy groups, etc. [4].

The best way to copy backup savesets on a Unix system is to use
one of several copytape programs [5] that are able to preserve
arbitrary record sizes and tape marks (i.e. multiple tape files).
You can do it "by hand" using no-rewind tapes and/or the mt
command:

	dd if=/dev/nrmt0 of=/dev/nrmt1		[6]
	dd if=/dev/nrmt0 of=/dev/nrmt1 bs=8192
	dd if=/dev/rmt0 of=/dev/rmt1

Beware, though, that backup's default record- and block-sizes may
well be different for 9-track magtape and TK50's, so the TK50 you
create by such maneuvers may not be identical to one created by
using backup itself to write directly to a TK50.  Whether such a
media-transferred saveset can be successfully read by a backup-
format reading program depends of course on the robustness of the
reading program.  Unix is very device-independent and a program
can barely tell if it's talking to a magtape or a TK50, so I
wouldn't expect a Unix backup program to have any difficulty.
True VMS backup might complain, although it shouldn't reject the
tape outright.

                                            Steve Summit
                                            scs at adam.pika.mit.edu

Notes:

1. When there are multiple savesets on the tape, the header and
   trailer records are, as I recall, coalesced, so that a tape
   with two savesets on it might look like

	file	recsize	    nrecs	what

	1	80	    3		header
	2	8192        *		contents #1
	3	80	    4		trailer/header
	4	8192        *		contents #2
	5	80	    2		trailer

2. Later versions of VMS backup write a more elaborate header
   file with more records.

3. Don't treat the number 8192 as gospel; my memory on this is
   imperfect.  It may be a backup command-line parameter.

4. This internal structure used to be documented as an appendix
   to the backup section in the VMS utilities manual.  In the
   new, revised VMS documentation, with a standalone manual for
   the backup utility, this information may no longer be
   documented.

5. Several have been posted and are probably available from the
   source newsgroups or their archives.  I've written one, but
   it's not handy; mail me if you'd like a copy.

6. No explicit block size is specified for the copying of the
   header and trailer files because versions of dd I'm familiar
   with correctly preserve record sizes as long as they're less
   than or equal than dd's blocksize, which is by default 512.
   You could use bs=80 for the headers and trailers if necessary
   or to be self-documenting.