Mac/Retrospect freeze during recycle backups

[jbirdski]

We're using Retrospect Workgroup 4.3 on a PowerMac G4/dual 450 to back up six Macs (two beige G3s, two iMacs, and two G4s) over an Ethernet network. All of the computers are running OS 9.1 with all software updates applied; Retrospect is also fully updated. The backup device is a second internal hard drive (IDE) in the main backup computer.

 

 

 

This exact setup used to work perfectly when performing automated nightly backups of all six Macs. Now Retrospect (and the backup Mac) crash every night during the backup. Even after the computer is restarted, Retrospect will not perform any scheduled backups until it's launched manually. The crashes are not reported in the Retrospect log, but they appear to be linked to recycle backups (or maybe just large backups). In the log, the recycle backup appears to have completed successfully (final data transfer statistics are present), but subsequent jobs do not occur and the computer hangs. Only one recycle backup is scheduled each night, and it doesn't seem to matter which source computer is being backed up. Networking issues don't seem to be the problem, since the hang also occurs while backing up the backup computer to its second hard drive.

 

 

 

I've seen the hang-on-recycle-backup during an immediate backup as well. The copying portion was successful, but near the beginning of the verification phase, the grid cursor disappeared, the progress bar and statistics stopped advancing, the computer time froze, and application switching was no longer possible. The only thing that continued to "work" was Retrospect's scrolling through file names, which continued for the standard period of time, although I couldn't hear any hard drive access noise.

 

 

 

Our Macs are all shared by the 25+ people in the lab, so strange stuff happens from time to time. Shortly after the Retrospect problem started, someone managed to delete some important system files from the main backup computer, rendering it completely unbootable. We reinstalled the system software and Conflict Catcher, which had mysteriously disappeared. Retrospect was still broken, so we also reinstalled it. All software updates were applied, but Retrospect still dies during automated backups. Plenty of RAM is allotted to Retrospect. I've also tried trashing Retrospect preferences, creating new backup sets, and messing around with extensions, but so far, no dice. For the time being, I've turned off verification for all of the backups, but that doesn't seem like a reasonable solution. (I'm also not yet sure that it helps.)

 

 

 

I realize that we probably have an extensions problem here, but tracking it down seems utterly daunting. The Retrospect freeze occurs more than an hour into automated backups (can only run at night, since they pretty much take over the client computers), making a systematic search through the extensions a real bear. Are there any known extension conflicts between Retrospect and OS 9.1 or various other software? We don't have any really exotic extensions on the backup computer, and I've already tried disabling all of the semi-questionable ones. I set up Retrospect originally and don't remember having to play the extensions game then... Any suggestions??

 

 

 

Thanks,

 

Jessica

[AmyJ]

With a lock up on the backup Macintosh, you want to try moving the mouse to see if the ADB bus has locked up as well. If the mouse moves, but the Mac is hung up, it's most likely that your SCSI bus is hung, and you have a SCSI problem. If the mouse doesn't move, that means that the Mac's processor is hung, and you should look at System Software and extensions. More often than not, you will find that the mouse moves and you can force quit the program (at which point the Mac may or may not completely crash).

 

 

 

A SCSI hang can be caused by one or more of the following:

 

1) a dirty tape drive or bad tape. Clean the drive. Try another tape. If other tapes work, then you just have a tape with a spot that's bad enough to crash your backup.

 

 

 

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 Mac 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 Macintosh 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.

 

---------

 

 

 

If this is an ASIP machine, please see the following statement. Although not specifically referenced, the issues stated are applicable to Retrospect 4.3 as well as 5.0.

 

 

 

http://www.dantz.com/index.php3?SCREEN=kbase&ACTION=KBASE&id=26688