KB Logo

TOLIS Group Knowledge Base

Browse KB by category:
Go to KB #:
Email   Bookmark

Moving from Retrospect? Information that you need to know before using BRU

Views: 29598
Votes: 8
Posted: 03 Oct, 2007

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:

sudo ditto -rsrc /Library/StartupItems/RetroRun/RetroRun /sbin/RetroRun
sudo killall -KILL RetroRun

(wait 1 minute for RetroRun to exit)

ps -ax | grep RetroRun | grep -v grep
sudo rm -rf /Library/StartupItems/RetroRun

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:

sudo nohup /sbin/RetroRun &

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:

$ tapectl display
Available Tape Devices:
ntape0: EXABYTE VXA -2 1005

Of course, your drive info may differ, but, if instead of output similar to what you see above, you see simply:

$ tapectl display
Available Tape Devices:

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:

$ libctl display
Available Tape Changers:
changer0: EXABYTE Exabyte EZ17 1.11

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:

$ tapectl -v -f ntape0 status
Vendor = EXABYTE , Model = VXA-2
Revision Level = 1005
No barcode support
Medium Type: 0x82 (loaded)
Density Code: 0x81 - VXA-2 or DLT 15GB comp
BlockSize: 131072
At block 4000

If this looks correct, you may test motion commands:

$ tapectl -f ntape0 rewind
$ echo $?

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.

$ libctl -v -f changer0 status
Vendor = EXABYTE , Model = Exabyte EZ17
Revision Level = 1.11
No barcode support
Robots: 1 (86), Drives: 1 (82), Tape Slots: 7 (1 - 7), No Import/Export slots.
Drive 0: Full : Tape From Slot 1
Slot 1: Empty
Slot 2: Full : Ready : No Bar Code
Slot 3: Full : Ready : No Bar Code
Slot 4: Full : Ready : No Bar Code
Slot 5: Full : Ready : No Bar Code
Slot 6: Full : Ready : No Bar Code
Slot 7: Full : Ready : No Bar Code

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:

$ tapectl -f ntape0 rewoff ; libctl -f changer0 unload
$ libctl -f changer0 status
Vendor = EXABYTE , Model = Exabyte EZ17
Revision Level = 1.11
No barcode support
Robots: 1 (86), Drives: 1 (82), Tape Slots: 7 (1 - 7), No Import/Export slots.
Drive 0: Empty
Slot 1: Full : Ready : No Bar Code
Slot 2: Full : Ready : No Bar Code
Slot 3: Full : Ready : No Bar Code
Slot 4: Full : Ready : No Bar Code
Slot 5: Full : Ready : No Bar Code
Slot 6: Full : Ready : No Bar Code
Slot 7: Full : Ready : No Bar Code

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
Mac System Type (G4, Xserve, et al)
Tape Drive Type and MFG
Library Type and MFG (if appropriate)
BRU Version (Command-A)
Contact Phone Number (near the system is important)
A thorough description of your issue


Retrospect and RetroRun are trademarks or registered trademarks of Roxio, Inc.

Others in this Category
document I have a new Fibre-Channel drive/library, but BRU Server is having a hard time using it, why?
document How do I control tape devices with tapectl(tm)?
document BRU Server is not writing to my external disk on Mac OS X, why?
document I have two NIC/Ethernet cards in my system, how do I tell BRU Server which one to use?
document Using USB Tape Drives on BRU Server for Linux
» More Articles

Powered by KnowledgebasePublisher
Page Load Time: 0.047052 seconds / 47.052 milliseconds.
Page File Size: 36088 bytes.