Jump to content

Error 519: network communication failed


Recommended Posts

I have Retrospect running backup server scripts on a Mac in order to backup 2 laptops to a network attached storage device (latest versions of Retrospect desktop and client). I set this up about a week ago, and it was working fine until this evening, when all of a sudden, the backup server Mac keeps failing to backup my PBG4: what happens is that Retrospect starts scanning files on my computer, and then, around 5000 or so, it stops with error 519. I swear that nothing has changed in the network or the computers. I even simplified the network somewhat, but that didn't help.

 

Any ideas as to what could be wrong? I guess there are a lot of variables here frown.gif

Link to comment
Share on other sites

Have you made sure that your powerbook G4 is not going to sleep? If it does go to sleep, it will cut the network connection. My experience with retrospect suggests that it can take a while to scan the files on the client computer (depending on network / hardrive / computer speed and or hard disk size), which might give the PBG4 enough time to shutdown (since retrospect is running in the background). You can change the settings under power management in the system preferences(os x) or energy saver in the control panel(os 9) so that your machine does not go to sleep during the backup. Good luck...

 

-Ricker

Link to comment
Share on other sites

No, my PB isn't going to sleep. I think that the problem may lie with the network storage device. If this is true, then the error message is really unhelpful, since the communication interruption occurs while the backup server script is scanning the client's drive, not writing to the backup set!

Link to comment
Share on other sites

Quote:

I think that the problem may lie with the network storage device.

 


 

Why do you think that? What problem do you believe the NAS is causing?

 

> the communication interruption occurs while the backup server script is

>scanning the client's drive, not writing to the backup set!

 

Retrospect will log the same 519 error if it looses contact with a client during scanning or during backup.

 

It's good that you simplified the network for testing. What did the physical network look like originally, and how does it look now?

 

Have you observed the process? Is that how you can be sure it's not a sleep issue on the client?

 

After the error, can you reconnect to the Client right away?

 

Dave

Link to comment
Share on other sites

For reasons that escape me, the ftp server on the NAS was flakey and now it refuses to run at all if I set it up for restricted access (previously, each backup server script would log in with a user name and password). There is absolutely no problem with the Retrospect client computer sleeping since I am using it! Furthermore, the backup server computer and the client seem to communicate just fine ... even when I was looking at the backup server logs, it was through Timbuktu from my computer (client) to the backup server! In addition, this allowed me to verify that the backup server can "see" my computer (client) just fine (though the configure clients dialog).

 

The network looks like this:

 

-- NAS

cable modem -- router -- switch -- backup server (PowerBook G3/500)

-- PowerBook G4/867 (client)

 

(this doesn't look right because these forms don't respect spaces; the NAS, switch, and PowerBook G4/867 are all plugged into the router)

 

To simplify the network, I eliminated the switch and plugged the server directly into the router (the reason why I have the additional switch is that the router's 4 ports are already taken). This made no difference.

Link to comment
Share on other sites

Quote:

Quote:

I think that the problem may lie with the network storage device.

 


 

Why do you think that? What problem do you believe the NAS is causing?

 

> the communication interruption occurs while the backup server script is

>scanning the client's drive, not writing to the backup set!

 

Retrospect will log the same 519 error if it looses contact with a client during scanning or during backup.

 


 

Well, maybe there's a problem with the client. Is there a problem with having the client and desktop software installed on the same computer? How does one remove the Retrospect client (so that I can try a reinstall)?

Link to comment
Share on other sites

Quote:

Have you observed the process? Is that how you can be sure it's not a sleep issue on the client?

 

After the error, can you reconnect to the Client right away?

 


 

I restarted the client, and the problem went away. I wonder why. Frankly, this is the second time that Retrospect had trouble communicating with a client. The first time was with another machine, and the problem was resolved by deleting the client and adding it again.

 

Is this sort of thing not uncommon?

Link to comment
Share on other sites

I have had a similar result with my windows 2000 / XP clients. Retrospect will be able to communicate with them, and then all of a sudden, port 497 will close (revealed using network utility on my OS X machine running the server software) and the client becomes unresponsive (network error). When I stop & restart the client on the windows machines, port 497 becomes open once again (and retrospect is functional). Dantz has not been able to explain this problem to me, but if they ever do, I will let you know...

 

-Ricker

Link to comment
Share on other sites

Quote:

I have had a similar result with my windows 2000 / XP clients. Retrospect will be able to communicate with them, and then all of a sudden, port 497 will close (revealed using network utility on my OS X machine running the server software) and the client becomes unresponsive (network error). When I stop & restart the client on the windows machines, port 497 becomes open once again (and retrospect is functional).

 


 

So you have the built-in firewall on as well? Perhaps it would be worthwhile turning it off to see if the problem goes away? I'm behind a hardware firewall anyway when I'm backing up.

Link to comment
Share on other sites

No firewalls are active when this problem occurs. I am really just testing this with windows 2000 as the client machine (even though I have briefly used XP as a client to troubleshoot), and some type of mac as the server. None of the macs have ever had their firewall active during this catastrophe. frown.gif

 

-Ricker

Link to comment
Share on other sites

  • 3 weeks later...

Let me suggest a different path. Dantz swore that this is a network only issue, but it's not. In several cases I've had clients have this issue occur on some of the machines on the network out of the blue. Turns out, in all of these cases, the network was running just fine. It was Retrospect that was having issues reading from the drive.

 

The solution I found was to install Retrospect on the client workstation and perform a duplicate. Low and behold, Retrospect tagged several files that it could not read (several different errors). Upon removing these files and trying the backup via Retro client again, the operation was successful.

 

Hopefully this helps!

 

Best

 

Jeff

Link to comment
Share on other sites

Quote:

The solution I found was to install Retrospect on the client workstation and perform a duplicate. Low and behold, Retrospect tagged several files that it could not read (several different errors). Upon removing these files and trying the backup via Retro client again, the operation was successful.

 

 


 

A duplicate between the backup set and what?

Link to comment
Share on other sites

Quote:

A duplicate between the backup set and what?

 


 

Anything.

 

I believe the suggestion is to allow Retrospect to run locally, and that whatever errors it logs that way can lead to clues as to files that it will have a problem with when run over the network.

 

An exernal FireWire drive can serve as the Destination; if the Duplicate results in files that can't be read, and deleting these files allows the machine to work as a client, you can erase the FW drive at the end.

 

Dave

Link to comment
Share on other sites

Thinking outside the box is always a helpful way to proceed when you're stuck on a problem. Jeff suggested doing that, and his method of allowing Retrospect to have the opportunity to identify problem files is reasonable.

 

Me, I'm in the box that say it's network hardware/wiring related. Your efforts to forget/re-add the problem are not fixing it, or it would be fixed. Perhaps something you're doing while you "reconfigure" the client is changing something relevant, but I can't tell from the available information what that might be.

Link to comment
Share on other sites

Quote:

Thinking outside the box is always a helpful way to proceed when you're stuck on a problem. Jeff suggested doing that, and his method of allowing Retrospect to have the opportunity to identify problem files is reasonable.

 


 

 

 

Jeff's idea is excellent. However, I observed in the past that Retrospect wasn't failing at the same point in the scan, which would seem to point to a problem other than files....

 

 

 

Quote:

 

 

Me, I'm in the box that say it's network hardware/wiring related. Your efforts to forget/re-add the problem are not fixing it, or it would be fixed. Perhaps something you're doing while you "reconfigure" the client is changing something relevant, but I can't tell from the available information what that might be.

 


 

 

 

I'm not jiggling the cables while I delete and reinstall the client, Dave. My backups have been working perfectly since I did the delete and reinstall. My sense is that when the network client configuration *changes*, i.e. a client goes away for a time, or when the network has simply been down for a period of time (which is what just happened; we were away for two weeks), Retrospect starts to have problems. Now my router is our DHCP server (through NAT); Retrospect doesn't depend on clients always having the same IP address, does it?

Link to comment
Share on other sites

Quote:

Retrospect doesn't depend on clients always having the same IP address, does it?

 


 

It depends on how you Add it to the Client Database.

 

- If you add a client by Address, then it depends on having that same address.

- If you add a client from the Broadcast window, then the address can change (within valid subnets) and Retrospect will still find it.

 

Dave

Link to comment
Share on other sites

My backup issues with my Win2k and WinXP clients disappeared when I took the windows client back to v6.0. Any client higher the clients disappear and reapper at random. Causing various errors that are always blamed on the configuration.

 

This of course is only my experience, but was pointed in that direction (downgrading the client to 6.0) from these forums.

 

-ric

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...