Browse KB by category:
Go to KB #:
Moving from Retrospect? Information that you need to know before using BRU
Troubleshooting BRU Products on OS X
Retrospect® is not BRU-Friendly
Option 1: If you are coming from Retrospect® 8, many users have reported success of disabling Retrospect® by renaming the application bundle for Retrospect and then rebooting the Mac OS X system.
Option 2: Turning off the Retrospect daemon/process in System Preferences has been found to work as well.
If you are using Retrospect® 8, try these two options above first as it is much faster than the steps below.
Because BRU and Retrospect® use different I/O methods for accessing the tape drive and libraries on a system, it is not possible for both to be run on the same system. Retrospect® installs a monitor and control program at system boot called RetroRun™. This "daemon" is constantly polling the state of your tape hardware and can cause major grief when a BRU job is executed. However, since BRU only accesses the devices when you specifically tell it to, BRU does not affect Retrospect® operations.
The results of the conflict range from "Device Unavailable" messages to failure in tape loading and unloading on libraries when a BRU job is run.
To disable the RetroRun process while keeping Retrospect® installed on your system, use a Terminal and execute the following commands:
The last two commands should return no data.
If all went well, it is now safe to run BRU. To restart the Retrospect® daemon at a later time, you can simply launch the application or execute in a terminal:
If you start the Retrospect application after doing the above steps, you will need to rerun these steps. This is because opening the application will automatically restart the RetroRun daemon.
Are your devices cooperating?
If your tape drive or library is not functioning properly, this can cause the BRU interface to report what appear to be odd errors. Since BRU uses OS X's built in SCSI layer for tape and library control, we are very dependent on that layer working properly. Check that you can communicate properly with your tape and/or library.
A good test to check BRU's operation is to open the interface, set the destination to a Disk File and enter "/dev/null" as the filename. Select your Applications directory for backup, Turn off the AutoScan Verify pass and then click the "Start Backup" button.
If this backup test completes successfully, then BRU is working as it should. This suggests that any problems are probably related to a hardware problem.
Check that the devices are seen by your Mac system:
Of course, your drive info may differ, but, if instead of output similar to what you see above, you see simply:
You definitely have a problem with your system recognizing the tape drive. Normally, BRU will recognize any tape device attached to your Mac via either the SCSI, Fibre-Channel, Firewire , or USB interfaces.
Checking your library is similar:
In either case, If you do not see a device listed, please power down the Mac and the drive, remove the tape drive from the system and double check all of your connections. A bad cable, terminator, or a mis-seated SCSI or Fibre-Channel card can result in a failure.
NOTE: BRU uses the device names returned by the display commands above as the device names for your tape drive(s) and library. By default device numbering starts at 0 (zero) - the first tape drive would be ntape0 while the first library would be changer0. Also, even though your tape drive is inside of your library, the tape drive and library robot are two different devices.
If you can see the drive, but BRU fails when trying to write or read data, check the cabling as above (look for bent pins on SCSI cables). Also, if you are using OS X 10.2.6+, you may need to look for updated SCSI HBA drivers - Check with your SCSI vendor.
You may also try modifying your SCSI card settings - on the ATTO UL3 and UL4 cards, you should disable tagged command queuing and set the sync rate for the tape drive (and library) to 40ST (Single Transition).
You should also examine your System Profiler output to ensure that your SCSI adapter and attached devices are seen. SCSI and Fibre-Channel Tape drives and libraries should appear as "IOSCSIParallelDevice" entries. Firewire and USB tape drives will show up as firewire or USB devices.
Most connectivity problems are corrected by either performing the SCSI HBA changes mentioned or by replacing the cables and/or terminators.
I can see the drive, but BRU fails when checking for a tape or loading/unloading a tape.
The following sequence of tapectl commands will test system communication with your drive:
If this looks correct, you may test motion commands:
If the echo command returns anything other than zero, you have an issue with the tape drive and motion commands.
You can test library commands using libctl.
To unload the tape from the drive and return it to the slot, you must first unload it from the tape drive and then instruct the robot to pick the tape and return it to its slot:
If after running these tests you still have problems, but the tests all functioned properly, please contact TOLIS Group Support with the following information:
OS X Version
Retrospect and RetroRun are trademarks or registered trademarks of Roxio, Inc.