Jump to content

twickland

Members
  • Content count

    1,684
  • Joined

  • Last visited

  • Days Won

    39

Everything posted by twickland

  1. In the Retrospect Directory window, go to Special : Preferences : Media Erasure and check the box for minimal erase confirmation.
  2. I believe that Retrospect 5.1.177 already incorporates the SCSI update, as the SCSI Update Installer says it's the "wrong version" to update. I am using 68 pin cables throughout. I have swapped out cables and terminators; zapped PRAM, etc As a test, I just installed a basic version of Retrospect 6.0. In its device configuration window, Retrospect 6 shows both tape drives with their proper SCSI targets, and will identify tapes inserted in either drive. However, it is only able to read or write from the first drive in the SCSI chain (the same drive that is the only drive that Retrospect 5.1 can see). When attempting to access a tape in the second drive, all appears to be well at first, but then the "rotating gear" cursor spins forever and the drive never starts up. Sounds like I need to turn the heat up on ATTO's tech support.
  3. In trying to access SCSI DDS tape drives In Retrospect 5.1.177 using an ATTO UL4S SCSI adapter and Panther 10.3.4, I find that all devices in the Device Status window show the SCSI target ID as 0. Only one drive shows as being accessible in the Available Storage Devices window. The drives display the correct SCSI target using the ATTO Configuration Tool, but no target ID appears in Apple's System Profiler. ATTO claims that the System Profiler is unreliable, and that the problem the drives do not appear in Retrospect is the fault of the Retrospect software. I am using the latest versions of the ATTO driver (3.1.0) and firmware (1.4.2f1). I also have an Adaptec 29160 SCSI card installed. Using this card and the most recent available driver (1.2, not certified for Panther), the target IDs of the tape drives are visible in both the System Profiler and in Retrospect. Question: Does what ATTO is saying regarding Retrospect 5.1 and the System Profiler make sense, or are they just shifting blame? Incidentally, I upgraded to Retrospect 6.0, but then downgraded back to 5.1.177 for two reasons: I was not ready to start a new catalog file (as 6.0 requires), and I was unable to successfully restore from version 5.0 tapes.
  4. I should have noted that I was previously running v 5.0 release 205 without experiencing the problem on quit. I did uncover a third-party software conflict that consistently triggered my problem with release 236. When I updated, I thought the problem had gone away. Unfortunately, it has only gone from consistent to sporadic. I am currently suspicious that it may be related to simultaneously running several Microsoft applications that use the same shared libraries. (These applications occasionally interact with one another such that, for example, I cannot delete a mail message in Outlook Exchange until I quit Word.)
  5. I recently updated to release 236, running on OS 9.2.2. The good news is that this release may finally have solved the communication problems we've been having with our OS X clients. There has been one peculiarity, however. When quitting Retrospect, if I have the program check media (DAT tape) at quit, the entire quit process seems to proceed normally, except that I then get a Finder message saying that Retrospect unexpectedly quit with a Type 2 error. This is true even if, after checking media, I click "Don't Quit," go back to the Directory, and then finally quit without rechecking media. If I quit without checking the tape, no error message is generated. When the Type 2 error message is generated, it's non-fatal and there seem to be no residual problems. Retrospect will autolaunch and automatically shut down the computer as normal, even if the computer is not restarted after the error. Has anyone else experienced this issue?
  6. We are experiencing the same problem here with an OS X (10.1.3) workstation client. Actually, we're experiencing a whole constellation of problems discussed in other threads. These are: 1) Retrospect Client spontaneously turns itself off. This appears to be initiated by the pitond process quitting. There seems to be no obvious pattern to this, but pitond won't stay running for more than a couple of hours. If Retrospect attempts access, we either get error 541, client not running, or error -1028, client not visible on network. 2) If we can manage to keep the client running until the backup of the client begins, the backup consistently fails after a few hundred MB have been backed up. The log indicates error 515, piton protocol violation. 3) If we attempt to reaccess, we then get error 505, client reserved. The client status on the client machine shows "In use by [backup script name]," and the pitond process is occupying 89-99% of processor cycles. The client status from the backup computer displays "Busy." It's remained in this state for 12+ hours, and I suspect it would stay that way forever unless pitond is killed. This is our only OS X client at the moment, and the reason we updated to 5.0 from 4.3. We have tried the known "fixes:" making sure that ethernet is listed first in the OS X network ports; turning off speed threshold in the backup script; reinstalling the client. We have not yet been able to back up this machine since switching to OS X. It backed up fine when booted in 9.2.2. (The Retrospect Client control panel is disabled in Classic, so presumably there's no possibility of a conflict there.) The OS X client is in a different subnet from the backup computer, which is running Retrospect Server 5.0.205 under 9.2.2. All of our clients have either a fixed address or a DHCP reservation, except for the ones in the backup computer's subnet. All regular MacOS and Windows clients have backed up flawlessly since we switched to 5.0. This is very frustrating, and is the worst problem we've experienced with Retrospect in 10 years of use.
×