Jump to content

still losing tape status, tapes appearing as "erased"


Recommended Posts

I thought I had theis solved, but apparently not. Using mac OS X 10.4.7, Retrospect 6.1, Exabyte VXA-2 1 x 10 firewire with firmware 209. I have a backup set which I started as a "new media backup". All tapes were erased, There were no errors in recording. today I went to remove the set and rotate the tapes. There were 5 tapes labelled 2 through 6. The others were labelled as "erased". I rescanned them - still "erased". The first member of the set, tape # 1, is "gone". Where did it go? How can this combination of hardware and software be so unreliable?

Link to comment
Share on other sites

Quote:

Exabyte VXA-2 1 x 10 firewire with firmware 209

 


This must be a typo. There is no "firmware 209", never was. Perhaps you have 2109 firmware? If so, it's out of date.

 

I see this occasionally since the 210E drive firmware. I haven't concluded whether it's the firmware or a batch of tapes, still gathering data. (Exabyte VXA-2 1x10 1u PacketLoader (SCSI) on ATTO UL4D in Xserve G5).

 

I'm not sure whether it is Retrospect's code on getting a new tape or whether it is the Exabyte tape discovery code (the new VXA-320 drive writes different headers), so I'm not sure whether the Retrospect code marks any tape it can't read as erased or whether the drive has a sense bit that denotes that the tape is erased.

 

That said, I have always been able to correct this by running a tape cleaning cycle, then re-inserting the tape into the drive.

 

My suspicion is that the 210E firmware is not as robust in some of its error recovery routines. But it may be the batch of tapes. My most recent batch of X-23 tapes is better than the previous batch.

 

Quote:

How can this combination of hardware and software be so unreliable?

 


If you've got dirty heads in your drive. Have you tried a cleaning cycle?

 

Russ

Link to comment
Share on other sites

Yes, cleaned the drive and re-scanned, same issue. You're right, the firmware was 2109, now i've updated to 210E, also latest Retrospect driver update, trying again. I have a mix of V and X tapes, maybe that is the problem?.

 

Also, I peeled off the barcode labels and then erased the tapes, but the Exabyte still reads the tapes as being barcoded!

 

In Retrosoect there used to be an option to do an extended erase and conditioning on a tape - has this been removed?

Link to comment
Share on other sites

Quote:

Yes, cleaned the drive and re-scanned, same issue.

 


You have to do more than re-scan. You have to move the tape into the drive so that the drive gets a chance to read the header. Again, the workaround that I have found always works is:

 

(a) move tape out of drive (eject back to autoloader) either by Retrospect (Configure > Devices) or by front of autoloader controls

(B) do a cleaning cycle from front of autoloader controls (there seems to be a minor bug in the Retrospect - Exabyte interface if you do the cleaning cycle from Retrospect - leaves a command pending, as I recall, and you have to quit Retrospect and restart it to clear this condition; I turned in a bug report many months ago to the Retrospect support group). I assume that you have designated one of your autoloader slots (10, usually) as a cleaning cartridge slot.

© move tape back into drive either by Retrospect or by front of autoloader controls. Should show as not erased (unless it is) with the proper backup set member name.

 

Let me know if this doesn't work for you; it has always worked for me. Again, I note that the VXA-2 drive seems less robust with its error recovery following the 210D firmware update, and I have been cleaning the drive after about every 10 hours of operation, which has made things much happier on this point. I have never seen errors during normal operation, but something about recognizing the tape headers when the tapes move into the drive is more sensitive since the 210D firmware update.

 

I have a suspicion that Retrospect (or the VXA-2 firmware) declares the tape as erased if it gets a read error on the header.

 

Quote:

I have a mix of V and X tapes, maybe that is the problem?.

 


(1) won't matter that you are using a mix of V and X tapes, except that the V-23 tapes (if that's the version you have) are EOL and no longer supported by Exabyte. I'd consider replacing them. See:

V-23 tapes are EOL

We only use X-23 tapes, so I don't have any experience with the other types.

 

(2) Been there with redoing barcodes when I changed our barcode scheme. See:

Barcode suggestions

 

(3) I strongly suggest keeping the barcodes, makes Retrospect much faster. Sadly, there is no way to quickly update your barcode database. You have to tell Retrospect to forget all of the barcode mappings, then, one by one, put your tapes in, do a brief verify to get Retrospect to associate the Retrospect Backup Set header with the barcode. Fortunately, I only (?) had a couple dozen tapes when I did this, but it took a while. I've put in a feature request to have this database stored in editable text format or to provide an interface for updating the Barcode to Member mapping, but that's for a future version, if ever.

 

(4) The notes I got from Retrospect Support on the barcode updating procedure are here:

KB Article - Rebuild Barcode Database

and here are the corrections I reported back to Retrospect support when I did it:

 

Quote:

The KB article is almost correct, but was enough for me to figure it out. Some of this may be due to differences in the Exabyte 1x10 1u PacketLoader from other autoloaders. Here are the corrections, at least for the Exabyte 1x10 1u:

 

1. (this step is correct in the KB article)

 

2. missing some steps: Configure > Devices, select "Exabyte Library, SCSI-A:0:0" (not the "Library Slots 1 to 10" entry), Command-I (get info), disable barcode support. You get the same window if you "get info" while selecting "Library Slots 1 to 10", but "Disable Barcode Support" button has no effect on the Barcode Support status.

 

3. It's "Option + Unload All/Eject Magazine" (not "Option + Eject All") while "Just Clear Barcode Info" is checked, at least on the Retrospect 6.1 I have. There is no "Eject All" button. (step 4 has the same error).

 

I note that if I do the above, skip step 4 in the KB article, then re-enable barcode support (step 5), then move each newly-barcoded tape to the tape drive so that Retrospect scans the tape and re-associates the barcode with the correct tape member name. If I then eject the tape back into the library and then try to verify the tape, Retrospect asks where the catalog is (seems to have forgotten this catalog with the changed barcode), allows the catalog to be re-selected, and then it moves the newly-barcoded tape into the drive from the autoloader (knows which one it is) and starts the verify.

 

Doesn't seem necessary to rebuild the catalog.

 


 

Quote:

In Retrosoect there used to be an option to do an extended erase and conditioning on a tape - has this been removed?

 


The Extended Erase is still there, but I never use it on VXA tapes. For some odd reason, there are two different variants of the "erase" dialog. You get an abbreviated dialog when you select a tape and click the "Erase" button (Configure > Devices). You get the full dialog (which also lets you name the tape and choose long/short erase) when the tape is in the drive and you use the Erase command in the Devices menu (Configure > Devices). Seems like an interface inconsistency to me, but I just shrug my shoulders and move on.

 

Hope this helps.

 

Russ

Link to comment
Share on other sites

Quote:

On my system there is no option to clear the barcode database anywhere that I can find. There is a button to "clear ID's". not sure what that does.

 


 

Did you exactly follow the steps in the KnowledgeBase article link I provided (e.g., step 2)?

Configure > Devices, highlight the Library (Exabyte Library ...), Get Info (Command I), etc., etc.

 

Russ

Link to comment
Share on other sites

Archived

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

×
×
  • Create New...