lukeah Posted January 20, 2012 Report Share Posted January 20, 2012 After updating to Retrospect 9 we're starting to see a bunch of errors like this: - 1/19/12 6:42:24 PM: Copying Photo Share on piggy !Can't reserve backup client piggy, error -515 ( Piton protocol violation). Any ideas on how to fix it? 10.6.8 Server to 10.6.8 Server. Quote Link to comment Share on other sites More sharing options...
ferthalangur Posted March 5, 2012 Report Share Posted March 5, 2012 I just received this error on a backup of my servers. Running 9.0.1 multi-server on OS X 10.6.8 on a dual 2.66 GHz Dual-Core Intel Xeon server. Clients are all running either 10.6.8 or 10.7.3. Clients are all running v. 9.0.0.319. The first backup, which ran fine (athena), is on a Linux client running 7.7.100. Log entries follow. I had recently fine-tuned my rules ... otherwise configuration is unchanged from what has been running on Retro 8.2 without any problems. + Normal backup using Remote Servers M at 3/5/12 (Activity Thread 1) To Backup Set Server Set R... - 3/5/12 3:05:12 PM: Copying / on athena 3/5/12 3:05:12 PM: No files need to be copied 3/5/12 3:36:10 PM: Snapshot stored, 29.2 MB 3/5/12 3:36:17 PM: Execution completed successfully Duration: 00:31:04 (00:31:00 idle/loading/preparing) - 3/5/12 3:36:20 PM: Copying /data1 on athena 3/5/12 3:36:20 PM: No files need to be copied 3/5/12 3:36:37 PM: Snapshot stored, 73 KB 3/5/12 3:36:40 PM: Execution completed successfully Duration: 00:00:20 (00:00:18 idle/loading/preparing) - 3/5/12 3:36:41 PM: Copying /data4 on athena 3/5/12 3:36:41 PM: No files need to be copied 3/5/12 4:48:57 PM: Snapshot stored, 145.6 MB 3/5/12 4:49:28 PM: Execution completed successfully Duration: 01:12:47 (01:11:16 idle/loading/preparing) - 3/5/12 4:49:31 PM: Copying /data2 on athena 3/5/12 4:49:31 PM: No files need to be copied 3/5/12 4:49:48 PM: Snapshot stored, 69 KB 3/5/12 4:49:50 PM: Execution completed successfully Duration: 00:00:19 (00:00:18 idle/loading/preparing) - 3/5/12 4:49:53 PM: Copying /data3 on athena 3/5/12 4:49:53 PM: No files need to be copied 3/5/12 4:50:11 PM: Snapshot stored, 69 KB 3/5/12 4:50:12 PM: Execution completed successfully Duration: 00:00:19 (00:00:17 idle/loading/preparing) - 3/5/12 4:50:15 PM: Copying atlas on atlas.chs.harvard.edu !Can't reserve backup client atlas.chs.harvard.edu, error -515 ( Piton protocol violation). - 3/5/12 4:50:25 PM: Copying Data on atlas.chs.harvard.edu !Can't reserve backup client atlas.chs.harvard.edu, error -515 ( Piton protocol violation). - 3/5/12 4:50:36 PM: Copying nike on nike.chs.harvard.edu !Can't reserve backup client nike.chs.harvard.edu, error -515 ( Piton protocol violation). - 3/5/12 4:50:44 PM: Copying Data1 on nike.chs.harvard.edu !Can't reserve backup client nike.chs.harvard.edu, error -515 ( Piton protocol violation). - 3/5/12 4:50:57 PM: Copying Data2 on nike.chs.harvard.edu !Can't reserve backup client nike.chs.harvard.edu, error -515 ( Piton protocol violation). - 3/5/12 4:51:05 PM: Copying ilex on mail.ilexfoundation.org !Can't reserve backup client mail.ilexfoundation.org, error -515 ( Piton protocol violation). - 3/5/12 4:51:18 PM: Copying Data on mail.ilexfoundation.org !Can't reserve backup client mail.ilexfoundation.org, error -515 ( Piton protocol violation). - 3/5/12 4:51:29 PM: Copying Data on argos.chs.harvard.edu !Can't reserve backup client argos.chs.harvard.edu, error -515 ( Piton protocol violation). - 3/5/12 4:51:39 PM: Copying argos on argos.chs.harvard.edu !Can't reserve backup client argos.chs.harvard.edu, error -515 ( Piton protocol violation). - 3/5/12 4:51:49 PM: Copying Videos on Video Edit MacPro !Can't reserve backup client Video Edit MacPro, error -515 ( Piton protocol violation). - 3/5/12 4:51:59 PM: Copying VideoData on Video Edit MacPro !Can't reserve backup client Video Edit MacPro, error -515 ( Piton protocol violation). - 3/5/12 4:52:09 PM: Copying Users on Video Edit MacPro !Can't reserve backup client Video Edit MacPro, error -515 ( Piton protocol violation). 3/5/12 4:52:21 PM: Execution incomplete Total duration: 01:47:02 (01:44:38 idle/loading/preparing) Quote Link to comment Share on other sites More sharing options...
ferthalangur Posted March 7, 2012 Report Share Posted March 7, 2012 After updating to Retrospect 9 we're starting to see a bunch of errors like this: - 1/19/12 6:42:24 PM: Copying Photo Share on piggy !Can't reserve backup client piggy, error -515 ( Piton protocol violation). Any ideas on how to fix it? 10.6.8 Server to 10.6.8 Server. According to Retrospect Technical Support, this is a bug which they have been able to reproduce and Engineering is currently looking into it. There is no work around within version 9 at the moment. Quote Link to comment Share on other sites More sharing options...
Maser Posted March 8, 2012 Report Share Posted March 8, 2012 How did you add your clients? Private/Public key? Or by browsing/hostname addition? Quote Link to comment Share on other sites More sharing options...
ferthalangur Posted March 8, 2012 Report Share Posted March 8, 2012 How did you add your clients? Private/Public key? Or by browsing/hostname addition? The clients that have the problem are outside the range of the multicast that enables browsing. They were added directly by hostname. Interestingly, that seems to be the differentiator between the clients that work (within multicast range) and those that failed. We use public key authentication for all our clients. Retrospect Support suggested that I uninstall the 9.0.0.319 client and reinstall the 6.0.029 client. I'm testing that right now. Quote Link to comment Share on other sites More sharing options...
Maser Posted March 8, 2012 Report Share Posted March 8, 2012 Out of curiosity -- what if you add your clients *without* using the Public key authentication? Does the problem go away? (Maybe try to revert a few clients back to the 6.3 client and try a couple others with the 9.0 client added without keys?) Quote Link to comment Share on other sites More sharing options...
ferthalangur Posted March 12, 2012 Report Share Posted March 12, 2012 Out of curiosity -- what if you add your clients *without* using the Public key authentication? Does the problem go away? (Maybe try to revert a few clients back to the 6.3 client and try a couple others with the 9.0 client added without keys?) Yes, that works too. Retrospect Support suggested that I uninstall the 9.0.0.319 client and reinstall the 6.0.029 client. I'm testing that right now. I Uninstalled the 9.0.0.319 client on one machine, installed the 6.0.29 client, deleted it as a source on the Retrospect Server [necessary -- otherwise the server gets very unhappy trying to back it up thinking it's a 9.x client], add it as a source, and backing up works without the Piton errors. On another machine, I uninstalled the 9.x client that had the public key, deleted it as a source on the Retro. Server, then reinstalled the 9.x client with a password instead of the public key, added it as a source, and backing up works without the Piton errors. Interesting -- now I have to choose which workaround to use. Any suggestions there? Quote Link to comment Share on other sites More sharing options...
Maser Posted March 13, 2012 Report Share Posted March 13, 2012 Well, you should probably report this to Retrospect support. It sounds like a bug they need to fix. Quote Link to comment Share on other sites More sharing options...
ferthalangur Posted March 13, 2012 Report Share Posted March 13, 2012 Well, you should probably report this to Retrospect support. It sounds like a bug they need to fix. They are already working on it. The most recent response I received was "Our engineers believe they have isolated the cause of the problem and they are planning to release an update to the Retrospect Client software in the near future to resolve the problem." As far as workaround choices -- I am going to go with backing out the 9.x client and reinstalling the 6.029 client with the Public Key simply because it is less work (for me) to upgrade 6.029 to 9.x using the Administration Console when a fix comes out, than to uninstall and reinstall the 9.x client a second time. YMMV. Quote Link to comment Share on other sites More sharing options...
137491ABC7D58DE1E040000A2A666149 Posted March 26, 2012 Report Share Posted March 26, 2012 I am in the same boat, and I, like Rob, have gone back to the 6.x clients with good success. The most troublesome part of this for me was the fact that the 9.x clients generated an excessive CPU load on the machine running the backup engine. Since I typically have many proactive backup threads running simultaneously, the 9.x client problems brought all the backup threads to a halt - including those threads backing up older Mac clients or Windows clients. Eliminating Mac 9.x clients had allowed all my proactive backups to run smoothly. Quote Link to comment Share on other sites More sharing options...
Maser Posted March 26, 2012 Report Share Posted March 26, 2012 Are you certain you could isolate that to the client version? What I see -- and I run multiple concurrent proactive scripts with really large disk media sets containing between 1.5 and 2.0M files each -- is that when an activity is in the "closing" phase, *that* can often cause the console to SPOD for a while until it's done. But I only have about 2/3rd of my clients update to the 9.x client at this point, but I see this issue regardless of which version of client is backing up. Quote Link to comment Share on other sites More sharing options...
137492415EB68DE1E040000A2A666149 Posted March 28, 2012 Report Share Posted March 28, 2012 We are a 99.9% Macintosh environment. We have a mix of clients, and I don't bother adding via multicast - it is faster and more reliable to manually add them. Sadly, when users IP changes (seldom, but it does when they've been away for a time), I have to pay attention and re-add them again. <sigh> What was suggested to us by support with the piton error was to add the clients to a Proactive script. It seems to have resolved the error, however, we aren't really keen on a proactive script for this function. Hopefully it is resolved soon. 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.