minidomo Posted August 16, 2012 Report Share Posted August 16, 2012 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? Quote Link to comment Share on other sites More sharing options...
twickland Posted August 16, 2012 Report Share Posted August 16, 2012 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? 1 Quote Link to comment Share on other sites More sharing options...
minidomo Posted August 18, 2012 Author Report Share Posted August 18, 2012 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? Quote Link to comment Share on other sites More sharing options...
minidomo Posted August 20, 2012 Author Report Share Posted August 20, 2012 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! Quote Link to comment Share on other sites More sharing options...
CallMeDave Posted August 22, 2012 Report Share Posted August 22, 2012 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)? Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.