Unable to consistenly back up to FireWire VXA drive.

[rmann]

We've been trying for over a year to get this process to work reliably, always without success. We have Retrospect Desktop 5.0.236 running on Mac OS X 10.2.4 on a 400 MHz slot-loading iMac with 320 MB RAM. We also have an Exabyte VXA-1 FireWire tape drive. There are three network clients. We run a backup server script that backs everyone up every day, active all day.

 

In general, when you start a backup, things appear to go well. Clients are found, scanned, and backup proceeds. However, within a day or two, the system appears to lose its mind. Retrospect will be stuck "closing", the VXA drive will show that it's writing, and nothing will happen again. The only way out of the situation is to power-cycle the drive, then wait hours while it recovers the tape.

 

We've spent, literally, hours on the phone with Dantz and Exabyte trying to resolve this problem. We've had the drive replaced TWICE. We've cleaned heads. We've tried different firewire cables. I no longer believe it is a drive problem. I think something confuses Retrospect and it never recovers. The log shows very little directly useful information.

 

Does anyone have any idea what's going on? Has anyone experienced this problem? Dantz tells me that it's possible to use Retrospect on Mac OS X with a VXA drive, but no one is willing to assume responsibility for this particular situation.

 

 

[ghoffman]

I have been experiencing this problem, too!

 

 

 

For just about a year, since I first started using Retrospect Workgroup 5 on Mac OS X, I have been experiencing hangs with Retrospect in the phase "Closing.../Updating catalog...".

 

 

 

My environment (which has evolved over the last year):

• Software: Retrospect Workgroup 5.0.238 w/Driver Update 3.3.104

• Operating System: Mac OS X 10.2.4

• Retrospect host: Power Macintosh G4 450 DP 256 MB 30 GB

• Tape system: Ecrix VXA-1 SCSI Ultra w/firmware 2EAE

• SCSI interface: Adaptec 2930U ROM 4.2 rev 3 w/Mac OS X Driver 1.1.0

Clients:

• Tangerine iMac 266 MHz tray-loading 96 MB 6 GB running Mac OS X 10.2.5

• Indigo iMac 500 MHz slot-loading 256 MB 20 GB running Mac OS X 10.2.5

• iBook 800 MHz Combo Drive 640 MB 40 GB running Mac OS X 10.2.5

• PM 6500/250 96 MB 4 GB running Mac OS 9.1 (being retired ASAP, no longer being backed up)

Our backup routine is a daily incremental backup to one of three tapes in an on-site rotation, with a separate incremental backup once a week to one of three tapes in an off-site rotation. A total of 8 incremental backups each week. The daily backups are initiated manually at about 5 AM and take approximately 1.25 hours for 1.5 GB. The weekly takes close to 3 hours for 5 GB. Backups include verify, of course.

 

 

 

I am not experiencing any of the other kinds of errors often reported here: Net retries, assorted Retrospect error codes and internal consistency check errors, bad backup set header found, etc. Not that I have never had any of these errors, mind you.

 

 

 

I have not discussed the hang-during-"closing" problem with Dantz, but have had some limited discussions with Exabyte. I have also been scanning the Forums and the mailing list discussions for a long time, but I have never found anyone else that had the same problem (although sometimes the posted description was close).

 

 

 

I sure hope a solution to this problem can be found. Every time I get a hang, it takes hours to recover, along the following lines:

 

cycle power on tape drive, wait for format recovery, force quit Retrospect, reboot Retrospect host computer (to reset SCSI interface), update catalog, restart backup.

 

 

 

I have had some success in reducing the frequency of the hangs. But I will leave that for another message.

 

 

[AmyJ]

Quote:

---

We have Retrospect Desktop 5.0.236 running on Mac OS X 10.2.4 on a 400 MHz slot-loading iMac with 320 MB RAM. We also have an Exabyte VXA-1 FireWire tape drive. There are three network clients. We run a backup server script that backs everyone up every day, active all day.

 

---

 

First, upgrade to 5.0.238, which is the latest build. http://www.dantz.com/en/support/updates.dtml

 

Have you tried this set up on a different computer? You've tried various drives, and I'm assuming you've reinstalled Retrospect on this system. How about a different OS X computer?

 

I'm testing this on a G4/350 with 10.2.5, Retrospect 5.0.238 and the firewire VXA-1, firmware 2A6A. Will post results in a week or so depending on how testing turns out.

[ghoffman]

Quote:

---

I have been experiencing this problem, too!

 

For just about a year, since I first started using Retrospect Workgroup 5 on Mac OS X, I have been experiencing hangs with Retrospect in the phase "Closing.../Updating catalog...".

 

....

 

I have had some success in reducing the frequency of the hangs. But I will leave that for another message.

 

---

Here are some things I have done to my Retrospect procedures that have greatly reduced my "Closing..."/"Updating catalog..." hangs in Retrospect.

 

My major workaround is to divide my large volumes into sub-volumes. When sufficiently divided up, the hangs almost entirely disappear.

 

I tried sub-volumes based on the common recommendation that if Retrospect has trouble backing up a volume and provides no clue to what is wrong, then use sub-volumes to isolate the offending file. I never found an offending file, but the problem did go away. I am living with a less than optimum backups, but at least they are running more reliably. My theory is that Retrospect in some way does not like to backup large numbers of files at one tine.

 

I have three volumes divided up into sub-volumes, out of a total of 13.

 

After defining sub-volumes, the backup script is set up to back up all the sub-volumes, and then the original volume to pick up files not in the sub-volumes.

 

On one of my volumes, I use the sub-volume workaround only during recycle backups. The workaround has not been necessary during the daily incrementals. This makes the daily backups run a little faster since there are fewer individual volumes to scan, backup and verify. Someday I will go back and try incrementals without sub-volumes on the other two volumes.

 

------

 

Another partial solution is to run Disk First Aid periodically on all volumes.

 

In addition, early on in the use of Retrospect 5, we experienced solid hangs on several of our Mac OS X volumes. Only serious volume repair would allow Retrospect to back them up successfully. In several cases we used Carbon Copy Cloner to copy the content of the volume to a scratch disk, and then back to the original volume. After this the problem was gone.

 

----------

 

I have an additional suspicion that Retrospect is having trouble with end of tape. We seem to have a disproportionate number of hangs where the backup would have spilled over to the next tape in the set if it had not hung. It is as if the wrap-up process ("Closing..."/"Updating catalog...") is not robust enough to deal with end of tape. I don't know how I am going to deal with this one, except that if I get tired of fighting it, I will just tell Retrospect to skip to the next tape as the current one nears the full mark.

[mjkobb]

I'm rmann's housemate, so I've been living through this headache for the last year as well. I should point out that we have:

 

1) Replaced the VXA drive (twice)

2) Tried several different computers, both as the network server and for direct-connect backups to the VXA drive.

 

We have similar problems in all cases.

 

I also tried having Retrospect simply back up to a FireWire disk array, with all other items remaining the same. That worked fine. No serious problems (I think maybe it hung once). So, the problem seems to be specifically related to the VXA.

 

We also had no serious problems when we used to back up to a SCSI 8mm drive on MacOS 9.

 

When we first got the VXA, our server was running MacOS 9 (we replaced the 8mm with the VXA and moved the server to the iMac for FireWire support). As I recall, this configuration worked fine for many weeks, although it periodically would hang the system (we've always had that problem with Retrospect -- it just hangs the server computer every week or two). If we had another FireWire Mac lying around, I would be very tempted to just set up MacOS 9 as our server and be done with it. Of course, the idea with OS X was that it should be more stable.

 

I know that rmann tried to back up his machine locally last night and was not successful with it. He had a crash, a "hardware error 203" and a hang while closing. Perhaps he can post more details.

 

Given that the VXA comes bundled with Retrospect, I had expected a more stable solution. However, it really seems as if Retrospect doesn't talk to the drive properly. Even when we get a successful backup, often the "writing" light on the VXA will remain lit until the next backup starts, at which point the drive goes back into a proper idle state and then the backup begins. My strong suspicion is that Retrospect is getting somehow out of sync in its communication with the drive. I will look forward very much to the results of your testing, and any other suggestions you may be able to provide. Thanks a lot!

[AmyJ]

I've been testing this for over a week on my G4 and have yet to see any problems - catalog out of sync or otherwise. I'm happy to hook it up to a Imac for a week and see what happens.

 

Quote:

---

He had a crash, a "hardware error 203" and a hang while closing. Perhaps he can post more details.

 

 

---

 

This error is being generated by the drive indicating a potentially serious hardware problem. That it worked fine for many weeks, and is now gradually failing is the hallmark of hardware failure.

 

Check to make sure you have the latest USB or FireWire firmware update for your computer. Apple often releases firmware updates that may help to resolve FireWire issues. Search the Apple Software Updates Web site for relevant updates.

 

Try a new piece of media to see if the problem is related to a faulty or damaged medium.

 

Clean the heads with a cleaning cartridge.

 

Isolate the device. Another device on the chain may be interfering with the backup device's communication. If your backup device is connected to your computer through a hub, adapter or another FireWire device, unplug it and connect it directly to a port on the computer. If it is already connected directly to the computer, try changing ports.

 

You may have a bad cable. Replace the cable that connects the device to the computer.

 

Update or reinstall the FireWire adapter drivers and/or firmware. Corrupt drivers can cause issues that may not be otherwise detectable. Check the manufacturer's or vendor's website for updated drivers.

 

Completely uninstall any other third-party backup software that may be on your machine, including any drivers that software may have loaded for the device.

 

Leave the machine idle while backing up - do not use the mouse, keyboard or other applications.

 

The VXA-1 is a pretty solid drive overall.

[mjkobb]

Hi Amy,

 

If you wouldn't mind testing on the iMac, on 10.2.4, we'd really appreciate it.

 

Quote:

---

This error is being generated by the drive indicating a potentially serious hardware problem. That it worked fine for many weeks, and is now gradually failing is the hallmark of hardware failure.

 

---

 

Actually, this drive is brand new. The first (of the three we've had) was the one that worked fine for weeks on OS-9. After connection to OS-X, it became unreliable.

 

Quote:

---

Check to make sure you have the latest USB or FireWire firmware update for your computer. Apple often releases firmware updates that may help to resolve FireWire issues. Search the Apple Software Updates Web site for relevant updates.

 

Try a new piece of media to see if the problem is related to a faulty or damaged medium.

 

Clean the heads with a cleaning cartridge.

 

Isolate the device. Another device on the chain may be interfering with the backup device's communication. If your backup device is connected to your computer through a hub, adapter or another FireWire device, unplug it and connect it directly to a port on the computer. If it is already connected directly to the computer, try changing ports.

 

You may have a bad cable. Replace the cable that connects the device to the computer.

 

Update or reinstall the FireWire adapter drivers and/or firmware. Corrupt drivers can cause issues that may not be otherwise detectable. Check the manufacturer's or vendor's website for updated drivers.

 

Completely uninstall any other third-party backup software that may be on your machine, including any drivers that software may have loaded for the device.

 

Leave the machine idle while backing up - do not use the mouse, keyboard or other applications.

 

---

 

All excellent suggestions, and all troubleshooting that we have tried already.

 

Quote:

---

The VXA-1 is a pretty solid drive overall.

 

---

 

Yes, that's its reputation, and why we bought it. However, that reliability has not been evident in our configuration, sadly.

 

Thanks again,

--Mike

[shadowspawn]

Quote:

---

In general, when you start a backup, things appear to go well. Clients are found, scanned, and backup proceeds. However, within a day or two, the system appears to lose its mind. Retrospect will be stuck "closing", the VXA drive will show that it's writing, and nothing will happen again.

 

---

 

Are your clients running Mac OS X?

If yes, are you backing up "client desktop"?

If yes, look in the log. Has Retrospect just tried to backup a mounted CD or disk image?

 

If yes, the work-around is not to use "client desktop" which somewhat erroneously now includes read-only media, or better, just turn off "Set source volumes' backup time" in the backup script settings (it is on by default).

 

If you answered no to any of the above, do you see a Net Retry dialog on screen at any point while unsticking Retrospect?

[shadowspawn]

Quote:

---

The only way out of the situation is to power-cycle the drive, then wait hours while it recovers the tape.

 

---

 

Have you tried force-quiting Retrospect, and then hitting the eject button on the VXA drive? i.e. getting the tape out before power-cycling the drive?

 

I ask because although more than one person said here they needed to power-cycle the drive with the tape inside, I have not needed to do that in similar sounding situations. I have needed to force-quit Retrospect lots of times, had to reboot a few times, but with the exception of a complete hardware failure have always been able to eject the tape before trying power-cycling the VXA unit. I still need to do the catalog repair thing, but have not suffered the hardware format-recovery.

 

[mjkobb]

Quote:

---

Are your clients running Mac OS X?

 

---

Yes

Quote:

---

If yes, are you backing up "client desktop"?

 

---

Not sure, I'll check.

Quote:

---

If yes, look in the log. Has Retrospect just tried to backup a mounted CD or disk image?

 

---

I'll check that as well.

 

Thanks!

 

Also, I believe that we tried just killing Retrospect and hitting the eject button on the drive, but in most cases where everything was hung up, the drive's "writing" light was still on. I don't remember for sure, but I don't think it wanted to eject. I'll definitely try it when it crashes next time.

[daspit]

Same problem here with VXA-1/Firewire and OSX. For a while I could get past

the hung client by rebooting it, but now it just sticks at "Closing..."

I can't see how it could be read-only media (CD or Zip disk) holding it up

because it hangs half-way through the harddisk's backup (different places).

I've got a dozen Macs with no complete backup on hand for any of them

and I need to get this resolved ASAP!!!!! I've deleted/rebooted/reinstalled

and recreated my scripts, no help. Checked that it's the latest version of

the firewire drivers, tried different tapes. Force-kill of Retrospect does

not allow eject of tape. Power-cycle of tape drive and rebuild of tape set

usually does NOT work. Any suggestions appreciated. Thanks, JD in Colorado.

[shadowspawn]

daspit, you will need to post your configuration details for more specific help. Mac OS version on server, on clients, Retrospect version on server, on clients, VXA firmware, the more the merrier.

 

Quote:

---

For a while I could get past the hung client by rebooting it

 

---

 

Is it only one client that shows the problem? Is there anything in common about the clients that hang? (if more than one)

 

Quote:

---

I need to get this resolved ASAP!!!!!

 

---

 

Remember that you can open a technical support incident with Dantz. This forum is primarily for free support from fellow enthusiasts although Dantz experts do certainly chime in too.

[etiffany]

I've been having almost this exact problem as well.

 

Configuration:

 

Server:

Powermac MacOS 9.1, 350MHz G3, 384 MB RAM, 300MB free disk

Retrospect Desktop 5.1.175

VXA-1 Firewire

 

Client:

Powerbook G4, 1.25GHz, MacOS X 10.3.3, about 13G used on disk

Retrospect Client 6.0.108

 

Symptom:

Retrospect server stalls during updating catalog. Server non-responsive (does not respond to mouse clicks, mouse stuck in 3x3 grid icon, menubar clock stuck), have to Command-Option-Escape to quit retrospect. At that point, the VXA drive is also nonresponsive and must be powered off (upon power on it commences its lengthy format recovery)

 

Note that this setup will work successfully about 1/2 of the time. Furthermore, it always succeeds in backing up a Powerbook G4 running MacOS 10.2 (client 5.1.109) just prior to backing up the 10.3.3/6.0.108 machine that causes problems.

 

Actions:

I have verified the operation of the VXA drive extensively on several different machines, and the Exabyte support people seem convinced that the drive is good. I have jumped through all the normal suggestions that are mentioned on this thread, to no avail. I don't have any mounted CDs or disk images, the server machine is idle apart from Retrospect, all the software is latest version, etc.

 

The one thing that has been successful is to downgrade the problem client from 6.0.108 to 5.1.109. Using that older client, the backup still stalls for about an HOUR in the "updating catalog" phase (about 300000 files) but eventually it completes and moves on to the verification pass.

 

This is really frustrating, and it seems like there are a couple of problems:

 

1. Retrospect interaction with the VXA can leave the drive in a hung state that ultimately results in the tape performing format recovery and loss of data

 

2. Retrospect client 6.0 on 10.3.3 seems to communicate badly with the 5.1 server.

[natew]

Hi

 

How much ram have you allocated to Retrospect on the backup server? Try at least 32 MB up to 70 or so. Make sure to leave the minumum size low at about 6 MB or so.

 

Is virtual memory enabled on this machine? If you have a CPU upgrade card make sure you have the latest firmware and drivers installed. Do you have trouble even if you use base extensions + Retrospect?

 

Thanks

Nate

[etiffany]

Quote:

---

 

How much ram have you allocated to Retrospect on the backup server? Try at least 32 MB up to 70 or so. Make sure to leave the minumum size low at about 6 MB or so.

 

 

---

The memory allocation seems to be the default. I guess I didn't change it after my last Retrospect update. I noted that Retrospect allocated 192M (according to About this Mac).

 

Quote:

---

 

Is virtual memory enabled on this machine? If you have a CPU upgrade card make sure you have the latest firmware and drivers installed. Do you have trouble even if you use base extensions + Retrospect?

 

 

---

VM is on, and the CPU upgrade/drivers/etc is latest (which is to say, last) from ~3 years ago. System has been pretty stable for a while. The change to 10.3.3 on the *client* seems to be most correlated with the troubles. Note: my previous post regarding success with the 5.1 client on 10.3.3 was overly optimistic -- it croaked the server and tape drive with that client version too.

 

However, relentless pestering of Exabyte has resulted in a new firmware version for the VXA-1 Firewire drive. This claims to address a problem of the drive losing it's mind if communication from the host stops for more than a minute (which might happen if the server is trying to write a catalog with 300K files). It seems that other VXA users were reporting similar problems.

 

I have not tested the new firmware with my OS 9 server configuration yet. I got tired of the whole thing, so I am currently using the Windows 6.5.343 version trial as a temporary workaround. I'll try upping the memory allocation on the Mac -- perhaps that plus the firmware will make things happy again.

[aleigh]

Previous statements:

 

"The VXA-1 is a pretty solid drive overall. "

------------------------------------------------------------------------

"Yes, that's its reputation, and why we bought it. However, that reliability has not been evident in our configuration, sadly. "

 

I concur the VXA-1 drive itself IS very reliable - its Retro which has been screwball ever since OSX/Retro 5

 

I've had pretty good luck however WITH the following adjustments/workarounds:

(BEAR IN MIND I ONLY BACK UP LOCAL DISKS - no Clients so YMMV)

 

I've had success running Retro under following conditions running VXA-1 FIREWIRE via OSX 10.24, & 10.28

 

1. Don't even think about turning on the drive then running a Backup - YOU MUST RESTART first.

2. Disable all forms of sleep in Energy Saver in particular don't allow Hard Drive Sleep.

3. Don't run System Prefs while Retro Runs - not sure why seemed to screw things up

4. Partition Drives/ and or set up SubVolumes (as mentioned in previous post) - THIS IS A MAJOR CONFUSING PAIN - I don't really know if it's neccessary - but above post seems to indicate others have had luck going this route.*

 

*ASIDE: I SURE HOPE this Isn't really neccessary-- something's really backwards when you need to organize your disks just to please one (increasingly) finicky program.

 

Other than the 1rst item: can't verify the necessity of the others, but after numerous headaches, the combo seems to work for me - Have yet tried Panther - am waiting for comments to a previous post to see if this will be safe to upgrade - can't imagine what I'd do if upgrade made it impossible for me to access my backups.