lupine Posted August 7, 2013 Report Share Posted August 7, 2013 I manage a network of four Macs: the console is on my MacPro running 10.6.8; two are iMacs running 10.6.8; one is an iMac running 10.7.5 It is DHCP (the IPv6 says 'Automatic, in About this Mac)). Even so, the IP never changes for the 10.6 machines. The newer 10.7 has changed, but the correct IP is displayed in source summary. Differences between the three clients' summaries include: -Both 10.6 clients showing 'Interface: default/ multicast' which I think is correct, while the 10.7 shows 'default/ direct IP'. -One 10.6 and the 10.7 show 'Security - Public/Private key' which is correct, and one 10.6 shows 'Password' which has never been used. It does not appear to have any impact, as this client has the fewest number of failed backups. All three clients have no 'Allow client to...' permissions, and Enable wake is selected. Also, all three clients will randomly reset which volumes should be backed up, which usually causes errors. The script is supposed to run every night, backs up any new/changed file to an external hard drive, which we swap when full. For us, it's a way to retrieve files that have been incorrectly overwritten, and be able to restore a work station's files if there's a fatal crash. I understand and accept the fragilities that come with, but it's simple and works for us. Except that it doesn't work flawlessly very often or for very long. Usually it's Scanning incomplete, error -519 ( network communication failed), but lately it's been '!Can't reserve backup client, error -515 ( Piton protocol violation)' on the 10.7. It seems like I have to check constantly to see who is not backing up this week; when I try to Locate or Refresh a failed client, it's a total crapshoot whether I get the -505 Client reserved or something else. That is, sometimes I can 'fix it', and sometimes it doesn't back up on the next schedule. We've used Retro since v 6, and I don't see many alternatives in the marketplace. I would dearly love to have back all the time I have spent trying to ensure that all of us are having our work saved. Does anyone have any suggestions? Start over? Upgrade to 10? Or should I simply muddle along... Thanks in advance for any assistance. Tracy 1 Quote Link to comment Share on other sites More sharing options...
twickland Posted August 22, 2013 Report Share Posted August 22, 2013 In my experience, Retro 10.2 is more stable and reliable than any version of Retro 9, but that may not be the reason for all of your problems. Upgrading may help the problem of the changing client source volumes, which, if it's really occurring, would be happening on the backup (engine) computer and not the clients. The other errors you're seeing, though, make me wonder about network problems. A -519 error can mean that a client that was installed with a direct IP address is not visible on the network, but if it appears after scanning begins it would indicate that the network connection was dropped or otherwise failed during the actual backup attempt, interrupting the backup of that client. When a client backup is interrupted, you will typically get the -505 error when you attempt to reconnect with the client. (Turning the client software of and then back on may resolve this error; if it doesn't, stopping the client software by holding the command key while clicking the off button should do the trick.) The real red flag to me are the -515 Piton protocol errors. This error is put up when Retrospect detects a problem in communication between the engine and the client software, and often indicates trouble with your network. If you're getting this error with more than one of your clients, it would suggest problems with a router or switch that's in the pathway between the backup (engine) computer and the affected client machines. If it affects all of the clients, you may be having trouble with the network interface on the backup computer. BTW, if you're using DHCP to assign IP addresses, and you haven't set up an address reservation based on the client machine's MAC address, you shouldn't use direct IP to access the client; you should use multicast or subnet broadcast, or you will be unable to connect to the client after its IP address has been changed. 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.