Jump to content

Media Load Failure


Recommended Posts

I am getting a media load failure on my stand alone SuperDLT 600 Drive reading a Super DLT II tape. It has been working fine since 6/2006, but ever since I tried reading it on my SuperLoader 3 DLT S4 drive (which Quantum says is compatible) I am now getting a media load failure on this drive. On another single SDLT drive I am getting an erased indication on the tape. Is there a way to get the data off the tape either with or without retrospect??

Link to comment
Share on other sites

First, the only way you are going to get Retrospect data off this tape is by using Retrospect.

 

Sounds to me, if I understand your post correctly, like the SuperLoader 3 DLT 54 drive has damaged the tape.

 

Please confirm:

Quote:

I am getting a media load failure on my stand alone SuperDLT 600 Drive reading a Super DLT II tape.
It
has been working fine since 6/2006

 


Which "it" has been working fine since 6/2006? The SuperDLT 600 Drive? the Super DLT II tape? both?

 

If you have been using this same tape for over two years, it may be worn out.

 

Quote:

but ever since I tried reading
it
on my SuperLoader 3 DLT S4 drive (which Quantum says is compatible) I am now getting a media load failure
on this drive
.

 


Which "it"? Are you talking about the worn tape?

Which "this drive"? SuperLoader 3 DLT S4? SuperDLT 600?

 

Are you saying that you took a Super DLT II tape that previously had been written on the SuperDLT 600 Drive, put that tape in your SuperLoader 3 DLT S4 drive and simply tried to "read" the tape, and now the SuperDLT 600 Drive gets a "media load failure" when you try to read that same tape that you previously tried to read in the SuperLoader 3 DLT S4 drive?

 

If this is what you are saying, sounds like the SuperLoader 3 DLT S4 drive did something to the tape. Perhaps you did more than just "read" the tape - perhaps you caused the SuperLoader 3 DLT S4 drive to write an incompatible header on the tape that the older SuperDLT 600 Drive cannot understand, or that the tape became broken or damaged by the SuperLoader 3 DLT S4 drive.

 

Have you tried to open the cartridge and inspect the tape?

 

As for the "another single SDLT drive" that shows an "erased" indication on the tape, I believe that Retrospect has an odd algorithm for deciding whether a tape is "erased" - I've seen this issue on our Exabyte VXA-2 1x10 1u PacketLoader (SCSI) with a marginal batch of tapes combined with a certain marginal firmware release from Exabyte last year (corrected this past January), whereby errors at BOT caused Retrospect to think that the tape was "erased". Using a cleaning tape, and ejecting/inserting the tape a few times caused Retrospect to recognize the tape.

 

Russ

Link to comment
Share on other sites

Sorry about that. Yes - "Are you saying that you took a Super DLT II tape that previously had been written on the SuperDLT 600 Drive, put that tape in your SuperLoader 3 DLT S4 drive and simply tried to "read" the tape, and now the SuperDLT 600 Drive gets a "media load failure" when you try to read that same tape that you previously tried to read in the SuperLoader 3 DLT S4 drive?"

 

I will try cleaning the drive and see if I can reload the tape. The wierd think is when I put the tape in the Superloader 3 it was still set to read only (locked) and the Superloader will not write to Super DLT II.

 

Thanks for the quick post!

 

Mark

Link to comment
Share on other sites

Well, with that confirmation, and with your comment that the SuperLoader 3 was set locked to read only, sounds like the SuperLoader 3 might have broken the tape or something similar.

 

Here's what I'd try, and my analysis:

 

You indicate that the tape can no longer be read on the same drive that initially wrote it (the SuperDLT 600), and that the tape shows as "erased" in a third ("another single SDLT") drive.

 

The drive that wrote the tape is always the best hope to read the tape (unless that drive has failed).

 

If cleaning the drive doesn't work, I'd suggest trying to look in to the cartridge and see if the tape is broken or damaged. If broken, you might be able to splice it and get something off, if you know how to splice tape. It's an art.

 

You haven't indicated whether any other hardware changed, or how you are interfacing to the tape drives. There have been some issues reported with the ATTO UL5D and Mac OS 10.4.10. ATTO has posted a new driver (4.20) and firmware for the UL4D, UL4S, UL5D, and UL5D Low Profile, but people have reported different issues with that. This may be a red herring because you haven't mentioned any of the problems seen by people on that front. Here's the ATTO link:

http://www.attotech.com/hottopics.html

 

And you might want to search these Retrospect forums on that topic, too.

 

Good luck.

 

Russ

Link to comment
Share on other sites

Glad I could be of help.

 

Simply FYI why I am so concerned about the, um, "unusual" algorithm that Retrospect uses to decide whether a tape is "erased" (seems to be based on whether there is an error at BOT):

 

Retrospect Mac has a bug that was fixed long ago in the Windows version. The bug has to do with barcoded tapes in an autoloader. Even if you pre-erase and have Retrospect pre-name your barcoded tapes so that they all have the right names for your barcoded inventory and then put them in your autoloader, if Retrospect needs an erased tape (e.g., when a tape member fills up, or when a backup set script does a "new media", etc.), it will ignore the names on the pre-named, barcoded erased tapes, even if an erased tape is in the autoloader that has the tape name it will use for the erased tape it now wants, and Retrospect will whimiscally choose from its available set of "erased" tapes when picking the next tape to use, ignoring the names of the barcoded erased tapes already in the autoloader. This makes management of barcoded inventory impossible, but has the added problem that tapes that are falsely declared to be "erased" could be overwritten in such a situation.

 

Because of this, I have no choice but to not put any prenamed barcoded erased tapes in the autoloader, and must wait for Retrospect to barf during a backup and halt because it needs another tape and has none available.

 

I turned in a bug report under our service contract a couple of years ago, but it's never been addressed even though the code fix is known and the bug fix was implemented in the Windows version long before I turned in my bug report for the Macintosh Retrospect version. Sigh.

 

Just a warning for you; glad you are up and running.

 

Oh, by the way, you shouldn't depend on a single backup set, anyway. You should have alternating sets. Tapes break. You dodged a bullet.

 

Russ

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...