Can't open old tape!

I have an 8mm tape that was dumped back in '96.  The system it was dumped on is an Auspex server running Sun OS 4.1.3 at the time(and I'm quite sure it was dumped with the b 126 option).  The server now runs 4.1.4 and some incantation of an auspex bug package.  

For some reason, I'm unable to restore from this tape using restore on that server, ufsrestore on a Solaris 2.3 machine I have or using dd to manually read.  I can query the tape using mt, and I can extract the Table of COntents using tar.
But when I try to initiate an interactive restore it ends up spitting out:

Media Block Size is 20
tape not in dump format.

I know that this tape is(or was) in dump format as we had restored from it before.

Anyone know how I can determine what is wrong here and/or how I may force the output to a different readable block size?

Thanks for any help!
bgoddenAsked:
Who is Participating?

Improve company productivity with a Business Account.Sign Up

x
 
movvamConnect With a Mentor Commented:
As the user dumped the tape way back in 96
and is well familiar with the os commands.


1) See if the tape needs cleaning. If lights on the drive are flashing, it needs cleaning.

2) make sure you have the correct device name for the tape drive.

3) Try the same command in high density mode, ie /dev/rmt/<device#>h to see
 if the tape was written in high density mode.

4) Try to read the tape in another driveand see what happens. If you can read it on another tape drive, then the current drive is hosed.

5) Ultimately, the tape may be bad, or the write was not complete etc.

6) You can always use dd to copy the contents of the tape to disk. Look up the man pages for dd. I'd recommend using large block size so it won't take too long.

Good luck!

Movva
0
 
ahoffmannCommented:
can you read anything with tar (-b 126) or dd?
0
 
bgoddenAuthor Commented:
No I have been unable to use those commands to read the tape, i.e.
tar -xvfb /dev/rxt0 126
or
dd if=/dev/rxt0 bs=126

Both give an I/O error.
0
Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

 
movvamCommented:
Try using  the tcopy command.
Ex: tcopy /dev/rmt0
It should give some byte information for all formats.

If it does not give any thing then the tape is probly bad.

Regards
Movva
0
 
bgoddenAuthor Commented:
OK, so it returns:

file1: eof after 0 records: 0 bytes
eot
total length: 0 bytes

Doesn't look good. Can I assume that the tape is hosed?
Thanks,
Brian
0
 
bgoddenAuthor Commented:
OK, so it returns:

file1: eof after 0 records: 0 bytes
eot
total length: 0 bytes

Doesn't look good. Can I assume that the tape is hosed?
Thanks,
Brian
0
 
movvamCommented:
Hello Brian,

Definitely i feel that it is bad.

Good Luck !

regards
Movva
0
 
ahoffmannCommented:
Are you reading from a non-rewinding tape device?
then issue several identical tar commands (ignoring the errors reported).
0
 
bgoddenAuthor Commented:
Like this?
tar xvf /dev/rmt/0
tar xvf /dev/rmt/0
etc.
etc.
?
..
0
 
ahoffmannCommented:
Yes.
0
 
bgoddenAuthor Commented:
I apprecited ahoffman's answer as well, although it was unsuccessful and mowam's answer introduced me to a new useful command.
0
 
ahoffmannCommented:
Would be nice to see the working command here.
0
 
bgoddenAuthor Commented:
Sorry, my last comment was a bit ambiguous.  Better stated I would say that both folks helped me out here with great suggestions.  mowwam's tcopy command, of which I was not previously aware, revealed that the tape is probably toast.  ahoffman's suggestion was also freat but didn't get me any results (I'm pretty sure I was using a non-rewinding device).  But at any rate, the end result was that my tape is gone and mowwam had helped me first.  To ahoffman:  DId you have some more suggestions or something else I might try here?
Thanks...
0
 
ahoffmannCommented:
no :(
as mentioned before, if you can't read with dd, you have a problem somewhere (hardware, tape, etc.)
My suggestion about using multiple tar commands is just a workaround for non-rewinding tapes: if you write multiple session with tar, it (tar) is confused while reading and needs an additional try. That's all.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.