Jump to content

Not showing loader slots for Viper 2000


Recommended Posts

I am running Retrospect Server v 6.5.1 on a Windows 2000 Advanced Server. I am backing up to a Viper 2000 LTO (Ultrium) drive. I have 11 tapes I can back up to. I just finished re-configuring our drive so that it is running firmware v. 1.25, and Multiple LUN's are enabled so my server sees the robot arm and the drive properly.

 

 

 

HOWEVER, Retrospect still does not show my loader slots/other tapes in the drive. It just shows the actual drive under the status window. Per the hardware compatibility page, "In Retrospect, the drive's inquiry string is what is displayed in the Storage Devices Environment window. However, when the device is set up properly, loader slots will properly appear in the Storage Devices window."

 

 

 

If I manually load a tape with a backup set on it into the drive (via the display panel on the autoloader), Retrospect does read it and will write to it, no problem. But I'd like to be able to see my full library so I can make sure that Retrospect will be able to run as a fully automated system, backing up the computers on my network to tape nightly, switching tapes each night.

 

 

 

Are there any special configuration adjustments I need to make to my Viper in order to get this to work? Right now we're using NetVault to back everything up to tape (we use Retrospect to backup the clients to the server drive, then NetVault to save those backups to the tape - I just started here last Monday, and am attempting to make sense of this headache) and since I adjusted the BIOS configuration and performed the firmware upgrade, it's having no problem checking all the tapes and seeing everything. However, we use macs in our organization, and we'd like to be able to just use Retrospect to handle that.

 

 

 

Any input or suggestions would be greatly appreciated, either here or via e-mail. Thank you in advance for your help with this!

Link to comment
Share on other sites

Does anyone have any ideas on this? Right now I'm manually flipping tapes around, but I'd like this to be a fully automated process (otherwise I have a very expensive drive going to waste).

 

 

 

Again, I'm running Retrospect 5.6 Server on a Windows 2000 Advanced Server (Dell server, I don't have the specs). I am backing up to a Viper 2000 with firmware level 1.25. I can see the tape in the drive, but can not see any slots in the magazine - it's as if I'm using just a single drive.

 

 

 

I have already fixed the SCSI bios so it recognizes both LU's (the drive and robot arm both come up in the startup screen).

 

 

 

Any suggestions are welcome!

 

 

 

-Suzanne

Link to comment
Share on other sites

Are you using the required Retrospect Driver Update (RDU) for this drive? The Viper 2000 was not supported natively with Retrospect 5.6. Support came only recently with a Driver Update. You can find updates at:

 

 

 

www.dantz.com/index.php3?SCREEN=download_software#WP

 

 

 

Without this driver, Retrospect will be unable to use this loader. If you have previously downloaded the RDU, check the Operations Log in Retrospect to ensure that it is loading. After Retrospect launches, you should see an entry stating that the RDU is loading.

 

 

 

If the RDU is loading, please refer to the following steps for troubleshooting:

 

 

 

Does the loader show up in Configure > Devices > Environment? The drive and the loader should have separate ID's.

 

 

 

Other devices on your SCSI bus can interfere with the tape drive's communication. Make sure your SCSI ID numbers are set correctly. Turn off your computer and the SCSI devices. Disconnect all SCSI devices except for the tape drive.

 

 

 

Was ASPI installed correctly? Run ASPICHK (in the Retrospect Program Files folder) to make sure ASPI is "green." If not, try a reinstall. If you still have problems, consult the Retrospect User's Guide or Adaptec's website.

 

 

 

Uninstall Retrospect, reboot and install a clean copy. It's possible that a file got corrupted during installation.

 

 

 

You could have a bad cable. Replace the SCSI cable that connects the tape drive to the computer after removing other devices and cables from the SCSI chain.

 

 

 

You could be missing a terminator or have a bad terminator. The last device and ONLY the last device in your SCSI chain needs to be terminated. Try replacing the terminator if you already have one on the chain.

 

 

 

The computer may be having a problem. Install Retrospect on another computer and try the tape drive there as the lone SCSI device.

 

 

 

The steps above are the essential outline of our SCSI troubleshooting here at Dantz. Hands on testing of device issues is really still the best method and even getting SCSI logging information is usually only to confirm empirical testing. Note that concluding something is a bad device is the LAST thing we assume after all other components and variables have been ruled out.

 

 

 

"SCSI voodoo", as they call the nebulous symptoms that can plague a SCSI bus, can often lead one to false assumptions of the cause of problems. It's important that once a variable is tested that it be tested more than once for consistency's sake to rule out dumb luck. For example, SCSI voodoo accounts for why a tape drive may work fine for many months without proper termination but then suddenly fail in some way later. Although customers will often cite that nothing has changed with their SCSI bus configuration in months and that it was all working before, this is really a hallmark inconsistency of SCSI voodoo.

 

 

 

The quickest and most conclusive test for most devices is to test it on more than one computer as the only device on the bus and with a different SCSI cable. If the problems can be reproduced on multiple computers, it's more than likely a hardware problem with the device itself.

 

 

 

Of course there a myriad of other specific issues having to do with a device's own hardware settings like with internal jumper cables, dip switches or internal termination that has to be sorted out with the device's manual and/or vendor or manufacturer of the drive but the kernel of SCSI troubleshooting above is a good general guideline.

 

 

Link to comment
Share on other sites

We're all moved in, and I was finally able to take time to look at this. I ran ASPICHK, and lo and behold, it was RED. I ran the install, rebooted, checked again, it was green. I launched Retrospect, went to configure devices, and everything was there!

 

 

 

Amy, you are my hero.

 

 

 

I'm having Retrospect scan the drives now, and it's even moving the media correctly. YAY!

 

 

 

Thank you SO much!

 

 

Link to comment
Share on other sites

Okay, I jumped the gun a little bit on this one.

 

 

 

Yes, I can see all my drives in the loader.

 

 

 

If the drive is empty, and I tell the system to scan the drives, it will pull the first tape from the loader and put it in the drive.

 

 

 

However, it will leave that tape in the drive, and pretend to scan the rest of the tapes (when in reality it's only scanning that one tape).

 

 

 

As there is no way that I'm aware of to change the SCSI settings of my loader separately from the drive (the drive is on 0:4:0, the loader is on 0:4:1), I'm breaking down and calling in for support. At this point it's worth the cost of the per-incident support to make sure I get this completely resolved. I figure, they certified the drive, so SOMEONE has made it work before.

 

 

 

-Suzanne

Link to comment
Share on other sites

  • 1 month later...

After much effort, and a couple calls to support, I am STILL dealing with this. I have now trained myself to switch and check tapes daily (which defeats the purpose of the autoloader). What it finally boiled down to was my having to actually order a new SCSI card for my server. At $300, I hope it works. I'm leaving my support ticket open until it's settled, though.

 

 

 

I'm curious... I remember seeing that when Retrospect updated in the past, some devices were dropped from the "Supported" list. When will we know if our devices are still supported?

 

 

Link to comment
Share on other sites

When a drive has been qualified and is exhibiting the behavior you are seeing, the only way to find the root cause of the issue is to go down the path you are on: Systematically rule out each and every variable involved. The SCSI card could absolutely be causing the problems you are seeing. If the problem occurs with the new card, I would go a step farther and install the card on a different computer and see if the behavior replicates. Make sure you are installing the newest SCSI card drivers provided by the manufacturer, rather then any drivers that may be included in the Windows OS.

 

 

 

Dantz does not make a policy of dropping support for drives - can you be more specific about which drives you believe are no longer supported?

Link to comment
Share on other sites

Archived

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

×
×
  • Create New...