tape catalog resync fails

[mjbolzan]

occassionally retrospect will hang and the mac must be restarted. when that happens, the catalog must be re-synced. i have never gotten this to work (or maybe it would if i waited 900 years).

 

 

 

i've run retrospect 4.3 for serveral years on a backup mac with a DLT autoloader. i've recently switched to retrospect 5 on OS 9.2.2 but only the problem flavor has changed.

 

 

 

on 4.3, retrospect starts from the first tape in the set. in 5.0, he's evidently smarter--he starts from the last used tape in the set. in any case, he reads the whole blinkin' tape or tries to and that takes forever.

 

 

 

this behavior seems real dumb.

 

 

 

has anyone gotten this to work on a large tape dataset?

[AmyJ]

Discerning Types of Freezes 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 using a 4mm cleaning cartridge. Your drive manufacturer recommends that you clean the unit once for every 8-10 hours of run time. Once a week is more than enough for most people. 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.

 

 

 

Regarding the recataloging, there has been no functionality changes from Retrospect 4.3 to Retrospect 5.0 for the Macintosh. Recataloging must begin with the first member, not the the last member. In Retrospect 5.5 and higher for Windows, the recatalog can being with the last member. We hope to improve recatalog support for the Macintosh in a future release.

 

 

 

You may want to consider keeping a backup copy of your catalogs available for situations such as this one. With an older copy of the catalog, you will no longer need to rebuild from scratch. You can use Tools > Repair > Update Existing... to bring the catalog copy up to date.

 

 

[mjbolzan]

thanks for the advice. i will change the scsi cable and terminator to see if that helps. i've changed the scsi card already.

 

 

 

i can't see the mouse behavior because the monitor doesn't wake up. i'm assuming the computer is hung.

 

 

 

two points in your post i did not understand

 

 

 

1) the behavior i observed with the catalog resync in 5 is different from what i had seen in 4. you say there had been no change in that logic though. maybe it doesn't work as expected in 5?

 

 

 

2) why would starting with an old catalog and doing the same long running process which never works yield any better results than starting with the catalog that was active when the process hung?

 

 

 

----------

 

 

 

as an aside, needing to read a whole tape when resyncing a catalog is not a great improvement. i do not see why the catalog cannot know the last good point written to it and proceed in the tape from that point forward.

[AmyJ]

In reply to:

---

1) the behavior i observed with the catalog resync in 5 is different from what i had seen in 4. you say there had been no change in that logic though. maybe it doesn't work as expected in 5?

---

 

The process is exactly the same as it has always been - in order to rebuild a catalog, you must start with the first member, and Retrospect must read each and every tape. This was how Retrospect worked in 4.3 and earlier versions, and now with 5.0.

 

 

 

In reply to:

---

2) why would starting with an old catalog and doing the same long running process which never works yield any better results than starting with the catalog that was active when the process hung?

---

 

If your catalog becomes corrupted, it takes much less time to "update" the older, non-corrupted catalog then to build a new one from scratch.

 

 

 

In reply to:

---

as an aside, needing to read a whole tape when resyncing a catalog is not a great improvement. i do not see why the catalog cannot know the last good point written to it and proceed in the tape from that point forward.

---

 

That is a good suggestion. Thank you. As I mentioned, we are looking at improving recatalog support in a future release.