Tape Name Problem

[jamestho]

I am reposting this here so that it is in the right forum, the copy that I mistakenly posted in the desktop and workgroup Macintosh forum can be removed.

 

 

 

During a EZSCRIPT New backup ID doing a full backup of a server which requires 4 tapes, I encountered a problem with a Seagate Scorpion 240 (firmware 8240) Tape Library. The tape caddy had 5 DDS4 tapes all erased and one cleaning cartridge (in slot six marked in the tape library function in Retrospect as a cleaning slot). Retrospect server 5.6 with plugin 3.0 running on windows 2000 server.

 

 

 

The procedure seemed to work flawlessly up until it started the compare process and found that it did not enter the name for the second tape in the series into the library and also did not attempt to rescan so it sat for 2 days over the weekend waiting for some attention. When I manually loaded the tape from the drive it did automatically propperly recognize the name so retrospect did write the propper name to the tape it just didn't enter it into the library and so could not select it in the autochanger. The backup started with slot 5 and continued to 4,3,2 leaving 1 erased. The tape that did not propperly get named was in slot 4. The series name was only 6 uppercase characters with no special formating (ASCPDC). Retrospect was running in unattended execution mode.

 

 

 

Hmm, I don't think I have any more useless info for you. Obviously, in order for autobackups to work it must be able to sucessfully complete the process. Even worse, it missed its next scheduled update of the backup set because it was stuck on a compare (set to log on errors, not stop on errors).

 

 

 

Is this a known problem? Does it happen frequently if it is? (I have not ben using the product enough I am still evaluating it trying to decide whether to use it or go elsewhere) If it is a known problem can a timeout be issued to have it rescan the library when it can find a tape or can it be intelligent enough to override a compare when a backup event is scheduled?

 

 

 

James

 

 

 

 

[AmyJ]

Have you been able to reproduce this problem? Does it always occur on the same tape? This is not a known problem, and would initially appear to be a faulty tape, although other variables can certainly come into play (cables, termination, etc.)

 

 

 

If you replace the tape and continue to experience this issue on other tapes, you should run through standard SCSI troubleshooting to help isolate which variable is causing the problem.

 

 

 

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

 

 

 

You 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 are missing a terminator (SCSI) 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.

 

 

 

Update the driver software for your SCSI card(s) at their manufacturers' websites.

 

 

 

Was ASPI installed correctly? Run ASPICHK (in the Retrospect Program Files folder) to make sure ASPI is "green." If not, try a reinstall (ASPIINST.exe).

 

 

 

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

 

 

 

The drive may be defective. If you have implemented all of the preceding steps and get failures on multiple tapes after changing cables terminators and computers then the drive (being the only factor that has not changed) is the culprit--send it back to your vendor for repairs.

 

 

 

The steps above are essentially the outline of our device troubleshooting here at Dantz. Hands on testing of device issues is really still the best method and even getting device 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 indicative of the 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.