Retrospect Server skipping disconnected user

[krajcd5]

Hello everyone.

 

Here is my problem. When my backup script is running and it starts backing up a user's computer if they leave the network for any reason, went home, unplugged their laptop, etc, Retrospect is always looking to reconnect to that user not matter what. Is there a way to set a specific amount of time that Retrospect should continue to look for a user on a given IP address and if they are not found just simply move on to the next person. It is not really a big deal but it has held up a couple of my scripts. Any help would be greatly appreciated.

 

Thanks in adavance.

 

Daniel Krajc

[natew]

Hi

 

Retrospect should retry for 5 Minutes and then move on to the next operation. Is that not happening?

 

What version of Retrospect do you have?

 

Thanks

Nate

[krajcd5]

It is not skipping them if the user starts to backup and then disconnects it keeps looking for that user for longer than 5 minutes. I am using Retrospect Backup Version 6.0.193. Is there a setting in the Preferences to make sure that I have this set up correctly.

 

Thanks.

 

Dan

[natew]

Hi

 

First, update to Retrospect 6.0.204.

Then option click on the preferences button on the special tab in Retrospect. That will let you set a throughput threshold to get around this problem.

 

Thanks

Nate

[anachron]

Hi, I'm running 6.0.204 under Mac OS X 10.3.9 and have tried this (setting a client threshold of 10MB/minute in the "special" secret preferences) and still I have a problem where, during the indexing phase of a backup, if a client (such as a laptop) is disconnected from the network, retrospect will A) freeze at that moment and remain frozen until I click or move the mouse, sometimes hours or days later, whereupon the "Net Retry.." window appears. I then have to cancel that by hand in order to get the Backup Server and scripts working again.

 

What gives? You would think that this problem, which ought to be a 1-hour programming job to fix, would be permanently resolved by now. Instead it remains, and is a serious threat to data integrity (through causing multiple hours or days of backup events to be delayed.)

 

Retrospect *really* ought to be robust enough to handle any anomaly a client throws at it, esp. something as simple as a lack of response.

 

What other suggestions do you have for fixing this problem?

 

Is this problem *conclusively* and permanently fixed in the Tiger-compatible release of Retrospect? I don't want to bother with the hassle of upgrading to Tiger only to find that the problem continues.

 

Thank you.

[natew]

Hi

 

Under normal circumstances Retrospect will give up on the backup of that client and move on.

 

There are some things we should try to troubleshoot in your environment. Can you run the following test please?

 

Move (not copy) your Retrospect preferences to another disk.

Relaunch Retrospect and enter your license code.

Log in one client and create a test backup set.

Run a backup of that client and disconnect it from the network during the scan.

 

Long story short - Does the same problem occur with clean Retrospect preferences?

 

Thanks

Nate

[CallMeDave]

Nate wrote:

 

Can you run the following test please?

 

Move (not copy) your Retrospect preferences to another disk.

 

 

But he actually meant move the Retrospect preference file (Retro.Config (6.0)) to another _location_ on the disk; you don't have to move it to another actual volume!

 

Dave

[natew]

Thanks Dave!

 

Nate

[anachron]

Thanks for your quick response. I will try this and see if, during the coming several weeks, the problem disappears. I'll also try staging a test where I have a laptop user pull their laptop off the network while an indexing / pre-backup scan is in progress.