Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Problem With VMS Backup Save-Set Spanning Tape Volumes

36 views
Skip to first unread message

Richard L. Dyson

unread,
Oct 3, 2001, 12:37:33 AM10/3/01
to
I have been asked to lend a hand in trying to restore some data from a multi-
tape DAT backup (4 volumes I believe) where we may have a spot part way
through
tape #1 that can't be read.

Is it going to be possible to plow through the bad spot and continue on
through
the other 3 tapes, etc.? Or will we just be screwed?

I don't actually have any hard details yet, just a phone conversation asking
for
assistance. :) I have not had this kind of bad luck myself, so I don't have
any
first hand experience on whether or not we can get much from the tapes or not.

Anyone else been there? So far, I just know it was a VAX-based system with a
120m DAT drive and 4 tapes in the save-set...

Is this a topic covered in any of the manuals?

Rick

Mal

unread,
Oct 3, 2001, 7:37:23 AM10/3/01
to
"Richard L. Dyson" <rick...@home.com> wrote in message news:<3BBA960B...@home.com>...

You could do some experimenting with "set magtape/skip=" try skipping
records or files to get over the bad bit. I'm sure I've used this
before with some measure of success. Of course if you can afford to
lose what's on the end of the first tape you could mount up vol 2 and
start the restore from there even if the saveset spans the volumes you
don't have to start at the beginning.

Also I think there's a tape dump utility on the Freeware CD which
might allow you to copy the saveset off tape onto disk.

Richard D. Piccard

unread,
Oct 3, 2001, 9:16:30 AM10/3/01
to

My experience with 9-track tapes, many moons ago, was that if you do a straight
restore (NOT /IMAGE), and put the second tape in, it will generate an
INFORMATIONAL error message about not being the start of the saveset, but will
proceed. It will likely restore a fragment of whatever specific file spans the
volume break, so you may well want to do a BACKUP/LIST and print the first page
to identify the file that may be partial.

I don't know whether $ SET MAGTAPE/SKIP will work to get past a bad spot on a DAT
tape. On the old TS-11 ("TapeStretcher"), when the BACKUP command started
"polishing" the heads (as it kept trying to read the bad part of the tape), I
would CONTROL-Y, then SPAWN, then SET MAGTAPE/SKIP to get it past the problem,
then LOGOUT and finally CONTINUE; BACKUP would typically generate an error
message about the missing blocks, and of course some files were lost and some
only partly restored. (It often took trial and error to determine how many
records to SKIP -- if I didn't go far enough, it would just resume the polishing
action.)

My impression is that commercial services with modified drives and special
software can get past the bad spots on modern cartridge tapes. Can you set a
value on the missing data, to decide whether the commercial services would be
worth it?

RDP


"Richard L. Dyson" wrote:

--
==================================================================
Dick Piccard Academic Technology Manager
pic...@ohio.edu Computer Services
http://oak.cats.ohiou.edu/~piccard/ Ohio University


Hoff Hoffman

unread,
Oct 3, 2001, 11:30:32 AM10/3/01
to
In article <3BBA960B...@home.com>, "Richard L. Dyson" <rick...@home.com> writes:
:I have been asked to lend a hand in trying to restore some data from a multi-

:tape DAT backup (4 volumes I believe) where we may have a spot part way
:through tape #1 that can't be read.

If BACKUP errors out, you MIGHT be able to read the media using COPY
or DUMP. That said, BACKUP is normally pretty good about reading the
media, and you really do NOT want to repeatedly try to read the data
yourself as you'll "scrape off" more of the allowable head passes.

:Is it going to be possible to plow through the bad spot and continue on


:through the other 3 tapes, etc.? Or will we just be screwed?

Unclear. DAT media has a very short lifetime (circa 2000 head passes,
and a typical INIT/MOUNT/BACKUP cycle can generate quite a few head
passes over the tape media under the tape headers), and is thus prone
to failure.

:Anyone else been there? So far, I just know it was a VAX-based system with

:a 120m DAT drive and 4 tapes in the save-set...

Make SURE you use a tape drive that is capable of 120m cartridges -- using
longer media cartridges in older drives is a recipe for problems.

:Is this a topic covered in any of the manuals?

Nope. (If you cannot restore the data using existing tools, this then
becomes a hardware support issue and/or a data recovery service bureau
issue.)

---------------------------- #include <rtfaq.h> -----------------------------
For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com
--------------------------- pure personal opinion ---------------------------
Hoff (Stephen) Hoffman OpenVMS Engineering hoffman#xdelta.zko.dec.com

Martyn

unread,
Oct 3, 2001, 5:46:56 PM10/3/01
to

"Richard D. Piccard" wrote:
>
> My experience with 9-track tapes, many moons ago, was that if you do a straight
> restore (NOT /IMAGE), and put the second tape in, it will generate an
> INFORMATIONAL error message about not being the start of the saveset, but will
> proceed. It will likely restore a fragment of whatever specific file spans the
> volume break, so you may well want to do a BACKUP/LIST and print the first page
> to identify the file that may be partial.
>
> I don't know whether $ SET MAGTAPE/SKIP will work to get past a bad spot on a DAT
> tape. On the old TS-11 ("TapeStretcher"), when the BACKUP command started
> "polishing" the heads (as it kept trying to read the bad part of the tape), I
> would CONTROL-Y, then SPAWN, then SET MAGTAPE/SKIP to get it past the problem,

I remember when I was an operator and we needed to restore from a duff
2400 foot 9 track tape on a TE16, it kept bombing out due to a bad spot.
In the end we had to take the drive offline just before the bad spot and
manually wind the tape on past the duff bit, reload the drive and
continue the backup which complained about missing blocks but we only
lost 1 file, you can't do that with these darn new fangled drives..... I
don't know if set mag/skip wasn't available then or whether we were just
so dumb we didn't know about it!

Paul Repacholi

unread,
Oct 3, 2001, 5:35:07 PM10/3/01
to
"Richard L. Dyson" <rick...@home.com> writes:

> I have been asked to lend a hand in trying to restore some data from

> a multi-tape DAT backup (4 volumes I believe) where we may have a


> spot part way through tape #1 that can't be read.

> Is it going to be possible to plow through the bad spot and continue
> on through the other 3 tapes, etc.? Or will we just be screwed?

You really need Save Set Utility, SSU, for this. Copy the save set
to real media and restore from that.

--
Paul Repacholi 1 Crescent Rd.,
+61 (08) 9257-1001 Kalamunda.
West Australia 6076
Raw, Cooked or Well-done, it's all half baked.
EPIC, The Architecture of the future, always has been, always will be.

Robert Deininger

unread,
Oct 5, 2001, 11:01:30 AM10/5/01
to
In article <87r8sk7...@prep.synonet.com>, Paul Repacholi
<pr...@prep.synonet.com> wrote:

> "Richard L. Dyson" <rick...@home.com> writes:
>
> > I have been asked to lend a hand in trying to restore some data from
> > a multi-tape DAT backup (4 volumes I believe) where we may have a
> > spot part way through tape #1 that can't be read.
>
> > Is it going to be possible to plow through the bad spot and continue
> > on through the other 3 tapes, etc.? Or will we just be screwed?
>
> You really need Save Set Utility, SSU, for this. Copy the save set
> to real media and restore from that.

Acrynom confusion...

Save Set Manager reads and writes VMS Backup savesets, and _might_ be some
help in this situation.

SSU is Session Support Utility. It helps you manage two terminal logins
from a single late-model VT terminal.

--
Robert Deininger
rdein...@mindspring.com

Rick Dyson

unread,
Oct 5, 2001, 2:11:46 PM10/5/01
to
"Richard L. Dyson" wrote:
>
> I have been asked to lend a hand in trying to restore some data from a multi-
> tape DAT backup (4 volumes I believe) where we may have a spot part way
> through tape #1 that can't be read.

It turned out there was a "bad spot" parity error, unable to read
past on each of the three full tapes of the volume set. I was told they were
all virgin tapes. The fourth tape finished to completion, but generated some
other error the owner did not remember what it was... :) The original backup
did
not do verify!

> Is it going to be possible to plow through the bad spot and continue on through
> the other 3 tapes, etc.? Or will we just be screwed?

I did try someones suggestion to <crtl>-Y and spawn to set magtape/skip...
and then return and try to continue. I had no success there, so I just always
QUIT
when the parity errors hit.

I was able to restart the backup command with the beginning of each tape.

Does anyone know about TLZ04 drivers? Are they able to use 120m DDS2 tapes
on VAX/OpenVMS v6.2? I found it curious that 3 of 3 virgin tapes all failed to
be
able to read all the way to the end. Though 2 did seem to read much longer than
one
of them.

Thanks for all the help!

The user seemed to be able to get over 2/3 of the data and all of the critical
data,
though that was mostly just dumb luck!

Rick

John Malmberg

unread,
Oct 5, 2001, 3:05:05 PM10/5/01
to
Rick Dyson wrote:

> Does anyone know about TLZ04 drivers? Are they able to use 120m DDS2
> tapes on VAX/OpenVMS v6.2?

The TLZ04 can only use 60m DDS2 tapes. It is a hardware limitation.

> I found it curious that 3 of 3 virgin tapes all failed to be
> able to read all the way to the end. Though 2 did seem to read
> much longer than one of them.

Based on past discussions in this Newsgroup, that is one of the
expected error conditions.

-John
Personal Opinion Only
malm...@dskwld.zko.dec.compaq

John Malmberg

unread,
Oct 5, 2001, 3:07:13 PM10/5/01
to
Correction:

The TLZ04 can only use 60m DDS tapes. It is a hardware limitation.

Joe Heimann

unread,
Oct 5, 2001, 4:16:42 PM10/5/01
to
Rick Dyson <Rick-...@uiowa.edu> wrote:
> "Richard L. Dyson" wrote:
>>
>> I have been asked to lend a hand in trying to restore some data from a multi-
>> tape DAT backup (4 volumes I believe) where we may have a spot part way
>> through tape #1 that can't be read.

> It turned out there was a "bad spot" parity error, unable to read
> past on each of the three full tapes of the volume set. I was told they were
> all virgin tapes. The fourth tape finished to completion, but generated some
> other error the owner did not remember what it was... :) The original backup
> did
> not do verify!

Sounds like a problem we had with a bum TLZ06 drive. It would write what
would be reported in the error log as a soft error, but when it came time
to read through that point on the tape, it was a hard error that could
not be read past.

>> Is it going to be possible to plow through the bad spot and continue on through
>> the other 3 tapes, etc.? Or will we just be screwed?

> I did try someones suggestion to <crtl>-Y and spawn to set magtape/skip...
> and then return and try to continue. I had no success there, so I just always
> QUIT
> when the parity errors hit.

> I was able to restart the backup command with the beginning of each tape.

> Does anyone know about TLZ04 drivers? Are they able to use 120m DDS2 tapes
> on VAX/OpenVMS v6.2? I found it curious that 3 of 3 virgin tapes all failed to
> be
> able to read all the way to the end. Though 2 did seem to read much longer than
> one
> of them.

TLZ04 drives are only able to handle 60m DDS tapes. The 90m and 120m ones
are too thin for the drive's transport to handle reliably. The drive can
stretch or snap the longer tapes in the worst case, and in the best case
they may not be written properly. You need at lease a TLZ06 drive for 90m
tapes, and a TLZ07 for 120m tapes.

As for new tapes, they have the highest oxide loss on first use, so that
can dirty up the heads and interfere with both writing and reading.

> Thanks for all the help!

> The user seemed to be able to get over 2/3 of the data and all of the critical
> data,
> though that was mostly just dumb luck!

> Rick

Joe Heimann

hei...@ecs.umass.edu

Rick Dyson

unread,
Oct 5, 2001, 5:54:31 PM10/5/01
to
> TLZ04 drives are only able to handle 60m DDS tapes. The 90m and 120m ones
> are too thin for the drive's transport to handle reliably. The drive can
> stretch or snap the longer tapes in the worst case, and in the best case
> they may not be written properly. You need at lease a TLZ06 drive for 90m
> tapes, and a TLZ07 for 120m tapes.

Great. I didn't read ahead, and just asked about the TLZ07... Thanks
for the confirmation. It *should* have worked, but apparently didn't very
well...

> As for new tapes, they have the highest oxide loss on first use, so that
> can dirty up the heads and interfere with both writing and reading.

This is what I have always known about video and audio tape and then
I assumed was true for DAT, 8mm, DLT, etc. Virgin tapes were the worst for
"fuzz".

Rick

Rick Dyson

unread,
Oct 5, 2001, 5:51:27 PM10/5/01
to
John Malmberg wrote:
>
> Rick Dyson wrote:
>
> > Does anyone know about TLZ04 drivers? Are they able to use 120m DDS2
> > tapes on VAX/OpenVMS v6.2?
>
> The TLZ04 can only use 60m DDS2 tapes. It is a hardware limitation.
>
> > I found it curious that 3 of 3 virgin tapes all failed to be
> > able to read all the way to the end. Though 2 did seem to read
> > much longer than one of them.
>
> Based on past discussions in this Newsgroup, that is one of the
> expected error conditions.

I just found out I was wrong on the tape drive model. He had a
TLZ07 drive. Are 120m DDS2 tapes OK for it?

rick

Tim Llewellyn

unread,
Oct 12, 2001, 1:03:22 PM10/12/01
to

Rick Dyson wrote:
>

> Does anyone know about TLZ04 drivers? Are they able to use 120m DDS2 tapes
> on VAX/OpenVMS v6.2? I found it curious that 3 of 3 virgin tapes all failed to
> be
> able to read all the way to the end. Though 2 did seem to read much longer than
> one
> of them.

Only 60m tapes are supported in the TLZ04. That MAY be your problem. Of
course,
lack of verify when making the backup was the first problem.
--
Tim.Ll...@cableinet.co.uk

Standard disclaimer applies. My views in no way represent those of
my employers or service provider.

0 new messages