Jump to content

Recommended Posts

I have an Exabyte VXA-2 1x10 loader, Mac OS X server 10.4.6, Retropsect 6.1. I go into device config, select all the tapes, erase selected, it goes through them all. When done, it still shows their old volume labels! Quit Retrospect, restart it, same thing. What's going on?

Link to comment
Share on other sites

I bet it's because Retrospect caches volume labels by barcodes (see pages 40-43 of the Retrospect Users Guide (Retrospect 6)). We've got an Exabyte VXA-2 1x10 1u (SCSI autoloader with drive), and the only way I've been able to rename the backup tapes is to manually move each one to the drive (Configure > Devices; then, from Devices menu on menu bar, Move Selected to Drive), then erase, and it gives you the option then to specify a new name for the tape. However, this will not do you any good at all because of Retrospect's behavior. If a tape is erased, Retrospect ignores the tape name when searching for a blank tape, and there is no guaranteed order in which it will use erased tapes in the autoloader. I consider this a bug, EMC/Dantz considers it a "feature", but it is the behavior documented on page 43 ("Tape Library Media Requests") of the User's Guide, which states that, "if a new or erased tape is required, Retrospect will load and use the first one available." This is the behavior, regardless of what the tape is named.

 

This behavior makes it impossible to barcode label erased tapes as they are purchased and pre-name them and have Retrospect respect the names you have given for pre-named, barcoded, erased tapes. Makes inventory control and tape management/logging impossible, even if you order sheets of barcode labels that match the naming scheme that Retrospect uses for its tapes ("Backup Set Members", which is the current politically correct terminology, different from Retrospect 2.x and 3.x).

 

I've put in a feature request (September 2005) to have Retrospect respect the names of barcoded pre-erased tapes if a tape of the needed name exists in the autoloader when it goes to look for new/erased media. I suggest that you do so as well.

 

Russ

Link to comment
Share on other sites

Quote:

BTW some of them were barcoded and some weren't - didn't seem to make any difference.

 


Yea, that was implied in my comments above. Retrospect only uses the barcoding as a "hint" (guess) as to which tape is where in the autoloader without having to read each tape. To me, this defeats the whole purpose of barcoded tapes, and I would prefer, if you go to the trouble of making up barcodes that match how you want the tapes labeled, that the barcodes be respected. As an alternative, if you pre-name the tapes to match the barcodes, that those pre-named, erased tapes have their names respected if barcoded. It's really only an issue for sites that rigorously enforce barcoding for tape inventory and management, as we do.

 

Note that there is another somewhat related problem with Retrospect and the Exabyte VXA-2 interaction, in that Retrospect can believe that the tape is "erased" if the tape is in the drive but not at BOT when Retrospect starts. Reasonable minds may differ as to whether it's a Retrospect problem or an Exabyte problem. For that reason, we have Retrospect set to rewind on quit and to eject the tape back to the autoloader. It's still possible to see that error if, for example, there is a power failure during a backup that causes the server to shut itself down (even if done gracefully while on UPS), leaving the tape not at BOT, which is how we saw it the first time. I've put in a feature request for a future version of Retrospect to have a preference to do a "rewind on start" before looking at the tape as a workaround, to ensure that the tape is always at BOT when Retrospect goes out to do its initial device scan (in other words, to repeat the device scan after an iniitlal rewind). But somehow the Exabyte drive's status bits report back to Retrospect that the media is erased when starting away from BOT, I suspect because of some confusion because some expected BOT header information isn't there to allow the drive to tell what type of tape is in there (with the recent firmware updates, the drive looks at header information to determine the VXA-1, 2, 3 type of the tape and other info such as whether the tape has been marked as WORM). When in this mode, the drive (or Retrospect, I don't know what the exact source of the error is) will cruise past logical EOT onto blank tape, and keep trying to find something, with tape motion in both directions during this period of confusion. Only cure seems to be to manually tell Retrospect to eject the tape from the drive and quit, with the preference set for rewind, causing the tape to rewind. On next insertion the tape will be at BOT, and the tape won't appear as erased.

 

I've seen another way to get the Exabyte autoloader/drive into this mode where Retrospect believes that the tape is erased, and that's to run diagnostics on the autoloader/drive, leaving the tape away from BOT, then to run Retrospect.

 

Hope this helps.

 

russ

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...