Jump to content
minidomo

error -519 network communication failed

Recommended Posts

I'm having an odd problem at multiple sites with Retrospect intermittently failing to communicate with clients. For example, here are some excerpts from one log -- the automated backup ran fine on 8/14 but failed on 8/15. During that 24-hour period, nothing changed -- neither computer was shutdown or restarted. In fact -- and I don't have enough examples to verify this -- my impression is that the remote backup will run once, and then fail to run until at least the client Mac is rebooted, and possibly the host Retrospect Mac as well.

 

+ Normal backup using Spectrum at 8/14/12

To Backup Set spectrum-v2...

8/14/12 3:05:00 AM: Recycle backup: The Backup Set was reset

- 8/14/12 3:05:00 AM: Copying Domainer on Spectrum

8/14/12 3:05:14 AM: Snapshot stored, 70 KB

8/14/12 3:05:15 AM: Comparing Domainer on Spectrum

8/14/12 3:05:16 AM: Execution completed successfully

Completed: 2 files, 4.8 MB

Performance: 72.4 MB/minute (41.4 copy, 289.8 compare)

Duration: 00:00:15 (00:00:07 idle/loading/preparing)

 

+ Normal backup using Spectrum at 8/15/12

To Backup Set spectrum-v2...

Can't access volume Domainer on Spectrum, error -519 ( network communication failed)

8/15/12 3:07:32 AM: Execution incomplete

 

All installations are running the latest version of Retrospect -- 9.0.2 (107) and client 9.0.2 (102). In both cases, Retrospect is running under Mac OS X 10.6.8 and the clients are running Mac OS X 10.7.4. I'm planning to upgrade those two 10.6.8 installations to 10.7.4 but just haven't gotten around to it yet. Not sure that would matter anyhow, but maybe it does.

 

Anyone know why this keeps happening?

Share this post


Link to post
Share on other sites

Can't access volume Domainer on Spectrum, error -519 ( network communication failed)

That error will be logged if the computer was once visible to the Retrospect engine but is no longer visible. This includes those cases where the client was originally added by direct address and is asleep or is otherwise not visible on the network at the time of the scheduled backup.

 

How were the clients added to the source list?

  • Like 1

Share this post


Link to post
Share on other sites

Yes, you're right! I just checked -- every single client that I'm having problems with was created via multicast, and all the ones that never have this problem were direct IP. I guess I just have to set them up again using direct IP and hopefully that will fix things.

 

Although doesn't this mean there's a multicast bug in Retrospect 9? These clients that are backing up once and then failing are not: 1) going to sleep, 2) disconnecting from the network, 3) getting a new IP address assigned. So if Retrospect "sees" the client once and backs it up, why can it no longer "see" the client on the next day, even if nothing has changed?

Share this post


Link to post
Share on other sites

So far, recreating sources using direct IP appears to have solved the problem. Thanks for the suggestion, Tim! Would still like to know if this is a bug likely to be fixed at some point or if I should always remember to use direct IP instead of multicast in the future -- so if anyone knows, please chip in. Thanks!

Share this post


Link to post
Share on other sites

The success (or failure) of multicast discovery can be effected by the physical network. If you're seeing unexpected behavior on multiple LANs, are there attributes shared among them? Same router(s)/switch(s)?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×