-519 Errors Driving Me Crazy

[ChrisW76]

Hi!

 

I am using Windows Server 2003 x64, Retrospect Multi Server 7.7.325 with Driver Update/Hot Fix 7.7.3.102 and am getting seemingly endless issues with -519 errors backing up clients.

 

In particular I have one server in our DMZ that I often have to try three to four times to get a backup to run. Part of the problem is, is that it is a server with 2m+ small files (about and so the scan takes a long time. By the time the server gets around to actually backing up what it needs to, it can no longer communicate.

 

However, if I try again it sometimes works - no particular reason. In fact I usually don't have to force quit the client and restart it; the client is ready to go again after a short break.

 

On another server I have to terminate the retroclient process and manually restart (or simply restart the service on a Windows machine).

 

In reading through the archives, the results suggest that it is a network issue and that I try connecting the backup server and the machine directly. This simply isn't practical for a production server and I need another method for getting to the bottom of the process.

 

Can anyone help?

 

Cheers, Chris W.

[53cT3ch]

I'm having the same issue with a certain workstation. All my other PCs backup fine. Just this 1 PC gives me -519 errors.Immediate backup works. I can schedule the backup to run (as im standing in front of the server) and it will backup just fine. So far I ran chkdsk on the c:\ of the client PC. chkdsk did recover lost files. I also wonder if the user is leaving files open on their PC. I'm going to allow the backup to run tonight as scheduled, to see if chkdsk repaired the -519 issue. I'll let you know how it goes. Does an immediate backup work on the client you're having issues with? You could also schedule the backup to run while you're there looking at it. Does it happen only at night? Can you re-create the -519 error? hope this helps a bit

[Lennart_T]

In reading through the archives, the results suggest that it is a network issue and that I try connecting the backup server and the machine directly. This simply isn't practical for a production server and I need another method for getting to the bottom of the process.

Some kind of network "sniffer" that logs the network traffic to and from the offending server as well as to and from the backup server. Especially look for lost packets.

[railes]

I just discovered some network settings which may help - deeply buried:

 

Go to Configure > Clients > Select client from the pick list > Properties > Access Tab > Change... > Interface > Configure Interfaces > Edit > Advanced

 

In that section there are a few configs that might help.

[53cT3ch]

Chkdsk didn't work & the user isn't leaving any files open. I'll let you know what else I come across.

[53cT3ch]

Hi Chris,

Have you been able to solve your -519 error? I've still had no luck.

 

Thank you

[ChrisW76]

Nope. In fact I just set up a brand new Windows XP machine (acting running SQL Server 2008), installed all of the latest patches, MS Security Essentials, latest Retrospect Client and nothing else, and have not been able to conduct a successful backup. Essentially the server starts to copy files (about 1-2GB) and then fails with -519. I then have to start and restop the Retrospect service on the new machine to try the backup again. Both the backup machine and the new machine are on the same Gb switch. After four attempts I have given up. Very frustrating!

 

Cheers, Chris W.

[53cT3ch]

:omg: WOW Chris, That really sucks! I still haven't been able to solve my -519 error either, I'm gunna keep pounding my head against the wall. I'll let you know if by some miracle I solve this problem.

 

Thanks for all your help!

[53cT3ch]

Hi Chris, I finally figured out why I was getting the -519 errors. I made a real dumb move. I had the PC scheduled to shutdown 30 minutes into the backup. Whoopz! I changed my shutdown script to a later time & now everything works ok. I hope this helps.

[Lennart_T]

Sometimes we do miss the obvious.

 

Thanks for letting us know what the problem was.

[Ramon88]

Hehehehe, good thing it was something logical in the end and not a vague bug!

 

Now if Restrospect had a functioning "sleep client" option you wouldn't have to deal with these shutdown scripts. Setting up clients to make sure they don't sleep or shutdown at the wrong time can be bothersome sometimes...