ver. 4.3 Verify hangs OS/8.6

[metrologuy]

I am doing backups with a Yamaha CRW8424SXZ CD drive with Retrospect 4.3 on a Mac OS 8.6 system. Each time I do a backup, I do it twice to two different, but identical, backup sets – just in case. Yesterday was one of those "cases".

 

 

 

The first backup on Set A proceeded with no problem. I added about 100MB to the file size to make the total about 1.1GB. During the second run to Set B, I got an error message "error 209 (media content damaged)" and was instructed to insert another disk, which I did. The backup then proceeded normally to the end, including the comparison process.

 

 

 

Just to be sure everything was OK with Set B, I performed a Verify operation. Of course, I had to start at the beginning of the 4-member CD set and let it run through to the 3rd disk, where the problem occurred. With 300MB left to verify, out of the 1.1GB file size, the verify started to spin its wheels. Note that this location is not in the newly-added section, since I only added 100MB. The currently-being-examined file indicator went blank and the green lights continued to operate on the front of the drive. I let it run overnight to see if it would bypass the problem. It did not. It was still doing the same thing in the morning. I stopped the process, but then the program hung the system with the drive lights still flashing. A force quit failed, so I had to reboot the system.

 

 

 

I tried the Verify again and the same thing happened.

 

 

 

Why did the initial backup to Set B finish after I inserted the 4th disk? It must have done the comparison correctly at this point. Why does the Verify process fail and hang up the system? Is there not a timeout function that skips over bad sections? I have the latest firmware installed on the drive. Also, is it possible to salvage the data from before the bad spot by copying it to another file on the hard drive without having the system hang when it reaches the bad spot?

 

 

 

Thanks for any light you can shed on this problem.

 

 

 

--Peter Z.

 

 

 

 

[AmyJ]

Short answer - If the drive can't read a bad spot on a disc, the software can't force it.

 

 

 

Long answer - If this backup system has been working well, but has recently started to fail, take a look at what has changed:

 

 

 

Have you changed media brands?

 

Added different devices to the SCSI chain or changed the order?

 

Changed the termination?

 

 

 

The errors you outline point to problems on the SCSI bus. Whether something has changed, or something is now failing, the goal is to find the variable. With a little troubleshooting you should be able to find the cause of the problem.

 

 

 

1) Try a different brand of media, such as TDK, Sony or Verbatim. If other CD's work, then you may have a bad batch of discs.

 

 

 

2) another device on your SCSI bus is interfering with the drive's communication. Make sure your SCSI ID numbers are set correctly. Turn off your Mac and the SCSI devices. Disconnect all SCSI devices except for the burner.

 

 

 

3) you have a bad cable. Replace the SCSI cable that connects the 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 Macintosh and try the 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 CD's 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.