Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

Problem restoring backup taken in higher VMS version

 
Shay Cohen
Occasional Advisor

Problem restoring backup taken in higher VMS version

I've done a standard backup on a MicroVAX 3100 (on TK50 tape) running OpenVMS V7.2 (before the backup command i've initialized the tape).
When trying to restore the save-set on a V5.5-2 VMS version, the OLD save-set that was on the tape before the Init command is restored. There are no signs for the new save-set on the tape.
11 REPLIES 11
Art Wiens
Respected Contributor

Re: Problem restoring backup taken in higher VMS version

Mount the tape back on your 3100 - Files-11 ie. not /foreign and do a directory listing.

eg.
$ mount/over=id muaxxx:
$ dir/date=(cre,modi) muaxxx:[]*.*;*

What does that show you? Did you do the backup in batch? ie. do you have a log file to verify you actually did a successful init and backup?

Cheers,
Art
Hoff
Honored Contributor

Re: Problem restoring backup taken in higher VMS version

The situation as described is never supposed to arise, barring cases of run-time errors with the INITIALIZE command, or a DLT cartridge mix-up or other such.

This particular day-one behavior of tape processing is entirely version independent.

A successful INITIALIZE clears off the contents of the tape.

Whether or not the INITIALIZE command was accepted and processed, that detail can involve the particular model of drive involved, and in which model DLT drive the cartridge was first written to.

Many of the TK-series drives can read media written in TK50, but can't write to these CompacTape series DLT cartridges, and some cases can require degaussing prior to writing. This media density incompatibility case should produce a write error of some sort, should this case arise. INITIALIZE should fail, or should overwrite the structures.

The particular BACKUP and INITIALIZE commands used for creation and for restoration can be very useful for purposes of troubleshooting.

Outside the matter of whether or not the INITIALIZE command was accepted and processed, it is entirely possible to have multiple files -- BACKUP savesets or otherwise -- with the exact same filename on the exact same tape. Though the INITIALIZE should clear this tape off.

And FWIW, if you specify the saveset restore by filename (and you don't have to specify the filename, you can also restore by saveset tape position), BACKUP will find the first saveset that matches the specification, and restore it.
Shay Cohen
Occasional Advisor

Re: Problem restoring backup taken in higher VMS version

I've done the INIT and BACKUP command interactively. The BACKUP command done with /VERIFY and there were no errors. I've mounted the tape later with MOUNT/OVER=ID and did a COPY drive:*.* and I've got only one file (=saveset) - the old one.
Jon Pinkley
Honored Contributor

Re: Problem restoring backup taken in higher VMS version

Shay,

What you are describing sounds to me like an incompatibility of the two tape drives involved.

I didn't think TK50s allowed multiple partitions, but what you describe sounds like that is effectively what your are seeing.

Andy Goldstein (if I am remembering correctly) once described a similar situation in a VMS Magic session, it involved 9-trk tape and two different drives, a small saveset and a tape that had two "start of volume" markers (the little pieces of reflective foil applied to the start of the tape, and end of tape).

One tape drive scanned forward looking for beginning of tape, the other wound a good bit of tape on the take-up reel, then found the beginning of tape while it rewound.

The effect was that one tape drive was able to create a small saveset between the two beginning of tape marks, and the second drive skipped past it while it was loading the tape. This took engineering a while to determine what the underlying cause was.

I would not expect the same type of problem to be possible with a serpentine tape like TK50.

However, I would try using a different tape to see if the problem goes away.

Jon
it depends
Jon Pinkley
Honored Contributor

Re: Problem restoring backup taken in higher VMS version

Perhaps someone with more hardware knowledge about the TK50 can say if this is a possibility. Perhaps the alignment of the two tape drives is enough different that each can read the tracks it writes, but not the tracks written by the other drive.

Do you have a third TK50 drive? Which saveset does it see?

Jon
it depends
DECxchange
Regular Advisor

Re: Problem restoring backup taken in higher VMS version

Hello,
Did you do try a backup/list command on the tape? I don't know how this could be possible since you intialized the tape, but maybe the backup of the 7.2 system ended up being put on AFTER the OLD save set. I would be interested in finding out what a backup/list command does on BOTH your VAX-VMS 7.2 system and on your VAX-VMS 5.5-2 system.
Steven Schweda
Honored Contributor

Re: Problem restoring backup taken in higher VMS version

> I've done the INIT and BACKUP command
> interactively. The BACKUP command done with
> /VERIFY and there were no errors. I've
> mounted the tape later with MOUNT/OVER=ID
> and did a COPY drive:*.* and I've got only
> one file (=saveset) - the old one.

Show me a transcript instead of a vague
description, and I might believe it.

After INITIALIZE, BACKUP, if it does anything
at all, should put your new save set onto the
tape, at the beginning. What makes you
believe that what you have is "the old one"?

Many things are possible, but extraordinary
claims require extraordinary evidence.
_Some_ evidence, at least, would be nice in
this case.
Wim Van den Wyngaert
Honored Contributor

Re: Problem restoring backup taken in higher VMS version

Also try dir a.b.c to see if error messages are enabled. Check help set mes if no message.

Wim
Wim
Shay Cohen
Occasional Advisor

Re: Problem restoring backup taken in higher VMS version

Sorry for the delay. The machines are on differents sites.

I've tried to read again (backup/list) the tape on the V7.2 machine and failed. The tape driver could not find the start-of-tape (it's an internal TZ30 and after I inserted the tape and close the door, the small lamp was blinking in orange and didn't stop for some minutes until I pressed the Release button).

I took another tape, backup something on it in the V5.5-2 machine (let's call the saveset NARKIS) and took it to the V7.2 machine. Mounting the tape didn't recognize the tape label nor the saveset. I've INIT the tape on the last machine and did a backup. Going back to the V5.5-2 machine and trying BACKUP/LIST, I saw the NARKIS (!!!) saveset (although this tape was initialized on the V7.2 machine).

It's the second tape with the same phenomenon.
Steven Schweda
Honored Contributor

Re: Problem restoring backup taken in higher VMS version

As usual, showing actual commands with actual
output might be more informative than vague
descriptions. I don't know what "Mounting
the tape didn't recognize the tape label nor
the saveset" means. I don't know exactly
what you did, nor exactly what happened when
you did it.

> The tape driver could not find the
> start-of-tape [...]

Assuming that "driver" was actually "drive",
this may tell you something about the
hardware.
Hoff
Honored Contributor

Re: Problem restoring backup taken in higher VMS version

In addition to the previous request for the DCL commands and the text of any errors reported, the particular models of DLT involved would be quite useful here.

Are these TK50 and TZ30 drives, or is this involving one of the other (common) DLT drives?

A TZ30 that cannot read a DLT cartridge is exactly normal and expected behavior -- if the source drive that recorded the contents is of an incompatible DLT format.

A successful INITIALIZE zonks tape contents. Period. (Well, except for the DLT alignment burst, a consideration when dealing with drives of this vintage. Only the drive or a degauss pass can zap that mark.) What OpenVMS can read from the media will be overwritten by the INITIALIZE. Unlike nine track mag, DLT drives won't let OpenVMS skate past the EOT marker, either.