Several gripes

[robertdana]

I'm a small business consultant and have been installing Retrospect as my standard small-office desktop backup solution for a while. I've run into several issues that I'm hoping someone here can at least point me in the right direction on:

 

1. My own office network is unfortunately partitioned by a wireless bridge. My Internet connection and two clients are on one side (one XP, one Mac), my retrospect server and laptop are on the other. Retrospect simply won't complete a backup across the bridge... I inevitably get a -519 errors trying to back up the two clients on the other side of it from the server.

 

I was hoping 7.0 would help, but after upgrading everyone to the newest update, I'm still getting the errors. This wireless connection behaves fine for all other uses and applications - there are occasional short drops of 5-10 seconds in duration due to some non-wifi interference in our area (we live near a military base), but everything else (windows file sharing, http downloads, etc...) tolerates it without a problem. I've watched it happen... Retrospect seems to give up at the first sign of a network hiccup, without any waiting or retries... are there some hidden settings I don't know about? I've searched the forum and seen some folks reference the "Network Retry" window and I've found the configuration setting in the advanced interface configuration options in 7.0, but they don't seem to have any effect. I've never seen one of these mythical retry windows.

 

I know -519s have been discussed here at length... but I'm new and haven't found posts that have been very helpful. Can someone point me in the right direction?

 

2. Does anyone else have problems with the Retrospect schedule stopping for no apparent reason? I've seen this at many of my clients... I'll fire up Retrospect to check the backups and discover they haven't been running for weeks. There are no pending media requests, nothing holding up the jobs. Of course they start running as soon as I open up the program. It's like the launcher service decides to quit working, even though the machine has been rebooted. I've seen it in both server and Professional 6.5... anyone else? Any suggestions?

 

3. Anyone know a source of 6.5 client licenses? I had a customer buy a new computer, and discovered that you apparently can't buy 6.5 clients anymore... all my usual suppliers are out of them, and Dantz says they aren't being sold. In other words, they're forcing the upgrade to 7.0 for folks who need to buy additional client licenses. Perhaps this has been hashed out on this forum already, but I think this is a terribly shady business practice... 7.0 was *just* released!

 

Sorry to pile so much in one post, but I would love any pointers or feedback.

 

-Robert

[Guest]

Hey Robert,

I'm on the phone with tech support now with a similar problem. Based on 25 or so years experience developing fault-tolerant datacom protocols for telecommunications networks, I don't have much hope of a quick solution, but hey, this lets me check out tech support before I purchase.

 

There appear to be two problems here:

 

1) The client is not robust--from watching my wireless access point, it's pretty clear that the master is polling the client and not getting a response after an error. This situation seems to require a reboot of the client machine to resolve.

2) Error code 519 is overloaded. From reading the posts and tech advice here, it looks like there are many differentiable conditions that are all reported as 519 errors.

 

If I were involved in generating product requirements here are the top level ones:

 

1) When backing up through a network with degraded performance, the product shall behave identically to its performance under optimal network conditions, except for reduced throughput.

1.1) The degradation of product performance under degraded network conditions shall bear a linear relationship with the degraded network capacity.

2) Error codes returned during remote backup operations shall explicitly indicate the error condition.

2.1) Network error codes shall only be used for errors in which the network is the proximate error source.

 

Well, still on hold. So far I really like the product--it's hit a sweet spot for SOHO between the toy backups and the Veritas stuff. I guess what I'd like is some indication that management is taking the 519 situation seriously and re-engineering the client. I can live with this for a while, but it needs to be fixed pretty quickly or the product is a non-starter.

 

..... time passes....

 

Well, just got off the phone with tech support. Says to strengthen my network by adding an access point. My laptop is in the same room with the access point, and is showing a steady 45Mb link. I got the party line about backups taking major amounts of network bandwith, however this is the only wireless connection on the network, and I've manually backed up the entire drive over the network with no problems, and a realized rate of about 25Mb.

 

Suggestion for Danz/EMC: admit there's a problem instead of sticking to the counter-productive party line of "backups are inherently different...." -- customers understand that no product is perfect, and I for one would be happier with an acknowledged problem and a fix date than a denial of the problem.

 

Cheers,

 

Dave

[natew]

Hi

 

Retrospect treats all network interfaces the same regardless if they are wired or not. It also operates over standard TCP/IP like any other program. What is does do differently is push a huge amount data in a continuous stream. If there are any weak points/ performance bottlenecks on the network Retrospect will expose them.

 

Error 519 is a basic error - network communication was lost for some reason. Retrospect can't distiguish between the types of errors that happen at lower layers of the network communication model. All it knows is that the connection was lost and could not be recovered. If you want to see the nitty gritty of how the failure plays out you can turn up network logging in the hidden Retrospect preferences (CTRL + ALT + P + P). It's not easy reading I can guarantee you...

 

It may sound like "party line" but I can assure you that if the network and network hardware are reliable Retrospect client will work well. This is true even if the throughput of the network is slow.

 

Thanks

Nate

[jhg]

Quote:

---

 

It may sound like "party line" but I can assure you that if the network and network hardware are reliable Retrospect client will work well. This is true even if the throughput of the network is slow.

 

 

---

 

-519 is certainly "overloaded" (see my related thread)

 

I heartily second the motion that Dantz needs to recognize and admit it has problems, especially with

the 7.0 release. I've been a loyal user of Retrospect since its early Mac days, and am extremely

concerned with the decline in quality of each successive release.

 

I currently have egg on my face for recommending to my company that they purchase Retrospect

Multi-Server. We can't even get it installed on Win2003 and all Dantz tech support can say is

"well, it's a problem with InstallShield - we can't do anything about it".

[natew]

Hi

 

Install shield can indeed become corrupt and fail. I've seen it a few times myself. It's not a problem specific to Retrospect/Dantz.

 

In the past install shield had detailed information about fixes for installer problems. What's the error message you are seeing?

 

Thanks

Nate

[Guest]

Hey Nate,

 

I agree that the client backup works well over a clean network--in fact, I've been so impressed with Retrospect during the evaluation that I just bought licenses for all of the office systems, and I'm running the first set of real backups now I looked at a lot of backup packages, from Ghost to Veritas, and I'm extremely impressed with Retrospect. The backup paradigm, user interface, installation, documentation and web support are excellent, and the performance I'm seeing tonight is really good.

 

Network-level protocols such as TCP/IP aren't able to handle all classes of errors--that's why it took ISO seven layers to model a protocol stack. Typically, you need a session-type layer to implement supervisory and error recovery functions for complex operations such as backups or multi-part transactions. The Retrospect client is going to have to become more robust, or Dantz/EMC is in for a very expensive and unpleasant bout of support activities as 802.11g SOHO networks are implemented in environments where 2.4GHz legacy wireless phones are still being used. My particular network fading problem appears to be caused by my neighbor's 2.4GHz phone, for example, so my converting to 5.8GHz phones didn't solve the problem--and I'm in a free-standing house, not an apartment or office complex. I suspect that a *lot* of people are going to be seeing the same type of network problems during the next 2 years or so.

 

Cheers,

 

Dave

[seanbreilly]

I had a major problem with the ubiquitous 519 error in my wireless Network:

 

 

 

- W2K Pro across the board (all upates) - 2 desktops, 1 laptop

 

- Wirless B

 

- Retrospect 7 (all updates to server and client).

 

 

 

The error came at different times every night - never the same place. Looked in

 

here and tried a few of the hints:

 

 

 

- I upgraded to Wireless G - no difference.

 

- made sure nothing was running, no scheduled antivirus, etc.

 

- tried playing with the client priority slider - no difference.

 

- I finally took a suggestion from someone who said downgrade the client to 6.5

 

THAT WORKED (for the most part - had one 519 error so far).

 

 

 

I fully believe this product would run fine in a land line environment. But what might

 

be going on with wireless?

 

 

 

- Sean Reilly

[Chimaera]

Retrospect 7 server and client

 

I have had error -519 on a couple of occasions during a long running backup over a 1Gbit wired, switched network.

This has occurred during an immediate backup and all further operations relating to the backup of that client then fail. From recognition of an error to complete failure of all further operations (i.e. backup 12 more volumes) took 2-3 seconds.

 

When I tried to preview the selected files, prior to restarting the backup, I got a message (sorry I didn't make a note) telling me the client was busy with another operation/backup.

 

So -

1) the Retrospect server recognised the error, the client did not;

2) the server was unable to communicate the error and any kind of restart to the client;

3) the client 'believed' it was still running the original job (in my case - compare stage);

4) the server was unable to establish contact without a stop/start of the client service.

 

I'm going to guess that the client is holding a job or sub-job internal sequence number and all further operations are disallowed until the server used that number in communication with the client, which of course won't happen because the server doesn't re-try a failed operation.

 

It seems something could be done to prevent that situation occurring, though clearly it would be dangerous to expect Retrospect to continue to attempt to re-run the job for an indefinite period.

[Guest]

Just installed 7.5. No progress on 519 error. Can't even complete a browse operation in the volumes screen without it failing. This is really frustrating--it seems like a single retry when a packet drops would solve 99% of these cases. BTW, it isn't my network. Everything else works fine: file transfers, printing, browsing, cross network installs.

[dthede]

"In a world without walls and fences who needs Windows and Gates?"

Window washers and gate keepers.