macinazo Posted October 3, 2007 Report Share Posted October 3, 2007 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?? Quote Link to comment Share on other sites More sharing options...
rhwalker Posted October 3, 2007 Report Share Posted October 3, 2007 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 Quote Link to comment Share on other sites More sharing options...
macinazo Posted October 3, 2007 Author Report Share Posted October 3, 2007 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 Quote Link to comment Share on other sites More sharing options...
rhwalker Posted October 3, 2007 Report Share Posted October 3, 2007 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 Quote Link to comment Share on other sites More sharing options...
macinazo Posted October 3, 2007 Author Report Share Posted October 3, 2007 THanks for the reply....HOLY CRAP THE CLEANING WORKED!!! I am running a duplicate backup of this tape tonight! Quote Link to comment Share on other sites More sharing options...
rhwalker Posted October 3, 2007 Report Share Posted October 3, 2007 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 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.