Retrospect 6.0 less usable than 5.1?

[twickland]

I was wondering whether other users find Retrospect 6.0 less functionally usable than 5.1.

 

We have been running 5.1 on Panther, putting up with the inability to autolaunch, until it was time to create new backup sets (we do this at the time change).

 

Since upgrading to 6.0.204, we've had a variety of problems that did not appear under 5.1:

 

• Lots of 515 piton protocol errors with OS X clients, which were rare under 5.1. Does 6.0 use different networking protocols than 5.1?

 

• Retrospect often hangs when adding a DDS tape member with Windows 6.5 clients. Shame on you, Dantz, for not spreading the word on this bug! We updated all of our Windows clients to 6.5 just before upgrading to Retrospect 6.0. Reverting clients to v 6.0 through Retrospect is a hit-or-miss prospect.

 

• After reboot, one Windows client looked like it had successfully reverted (it showed as client v 6.0 via Retrospect). However, at the client itself, the only visible version of the client software was 6.5, and the control panel said it had not loaded. After conducting a search of the hard drive, which showed no other versions, we were forced to uninstall v 6.5, which apparently eliminated the invisible 6.0 client as well, and then manually reinstall the 6.0 client.

 

•It looks like we will need to manually uninstall and reinstall the client software for most of our Windows computers.

 

• When Retrospect hangs, rebuilding the catalog has caused problems.

 

• After one catalog rebuild (which claimed to be successful), we could not add to the backup set, apparently because, although it had been named, the latest DDS member (where Retrospect had hung) was otherwise still blank. Error 212, media erased (DUH!)--a new one on me. I thought, "No, problem; just forget that last member." Wrong. Forgetting the last member reset the entire catalog, which then had to be reconstructed from the tapes.

 

• After another catalog rebuild, we couldn't add to the backup set because the "catalog was locked." Luckily, quitting and relaunching Retrospect fixed that one.

 

It seems like every Retrospect upgrade has had problems, but 6.0 seems worse than most.

[twickland]

• Lots of 515 piton protocol errors with OS X clients, which were rare under 5.1. Does 6.0 use different networking protocols than 5.1?

 

I have discovered the source of all the piton protocol errors. These are generated when Retrospect changes to a new media member while backing up OS X clients (at least with client v 6.0.108).

 

Clearly, Retrospect 6.0.204 does not handle DDS media changes gracefully with either Mac or Windows clients. Comments, Dantz?

[CallMeDave]

Quote:

---

Lots of 515 piton protocol errors with OS X clients, which were rare under 5.1

 

---

 

Although rarely, you still had these errors with 5.1?

 

- Were they across media requests, too?

 

- Did you do anything to try and address the errors?

 

No matter what specific stage the software is in when the error occurs, the most likely underlying cause is your physical network.

 

If you can reproduce the error every time there's a media request, you should test with a direct network connection (cross-over ethernet) to try to find out if the switc/port/patch/run etc are involved.

 

If the problem goes away when you drop these physical components, you've isolated them as playing a role.

 

If the problem persists, you may still have an issue with the remaining physical networking components (ie the network interface in the machine(s)).

 

I just successfully backed up an OS X client to a CD/DVD Backup Set (using CD) across a Media Request window without any error. And while my test conditions may differ from yours, it shows the the program is not unable to acomplish this task.

[twickland]

Dave:

 

You raised an interesting question about piton protocol errors, so I checked the logs and found that the only piton protocol errors we have gotten since 10/29/2003 occurred at the time of media requests with OS X clients (though not every media request during an OS X client backup generated an error). These errors happened with Retrospect 5.0 under OS 9.2.2, and Retrospect 5.1 under OS 10.2.8 and 10.3.x.

 

Of the 66 media requests under Retrospect 5.x between 10/29/2003 and 10/29/2004, 12 occurred while backing up OS X clients, with half of those generating piton errors.

 

Of the 11 media requests under Retrospect 6.0 since 11/1/2004, 4 occurred while backing up OS X clients, and all 4 generated piton errors.

 

Due to the hassle of dismantling client computers and dragging them down to my office, and due to the relative infrequency of the piton error problem under Retrospect 5, we did not pursue an investigation at the time.

 

Since the problem has occurred with clients in four different subnets, and assuming it is not due to a bug in the Retrospect software, the problem would seem to lie either with the backup computer itself or its subnet router, unless there is some issue affecting all of our routers, such as how they are configured.

 

If the problem persists, I may change my mind about investigating further. However, since the error is fatal only to a single night's backup of an individual client and, unlike the Windows client problem, does not stop the execution of the rest of the script, we may just live with it.