Jump to content

Piton error


Recommended Posts

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.

Link to comment
Share on other sites

  • 1 month later...

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)

Link to comment
Share on other sites

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. :(

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • 2 weeks later...

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

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...