error 212

[Brendanroos]

We are using Retrospect Workgroup with the OnStream ADR 50GB drive. We

 

backup the host Macs HD and a few client HDs. All was working fine with

 

Retrospect version 4.2.

 

 

 

Now after installation version 4.3C even from scratch the host Mac does

 

back-up fine, the first network client does back-up fine when only a

 

subvolume gets backed-up but on the 2nd network client we get 212 errors on

 

the verify. If we try to back-up the hole volume we get 212 errors already

 

on the first network client.

 

 

 

We have tried different OnStream drives, ADR tapes, scsi cables and adapters and have tried different Networks.

 

 

 

How do we overcome the problem?

 

 

[AmyJ]

Error 212 (media erased) occurs when the content of the backup set medium is erased. If the drive is falsely stating the the medium is erased, this is usually indicative of a hardware failure. The drive generates the error and Retrospect reports it. Standard SCSI troubleshooting should help you isolate the problem. Sometimes you will have to retest variables to find the actual cause of the issue.

 

 

 

A incorrectly reported media erased error can be caused by one or more of the following:

 

1) a dirty tape drive or bad tape. Try a new tape. If other tapes work, you have a faulty tape.

 

 

 

2) 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 SCSI devices. Disconnect all SCSI devices except for the tape drive.

 

 

 

3) 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.

 

 

 

4) you are 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.

 

 

 

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

 

 

 

6) 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 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.