Can't Reserve Client, Piton Protocol Violation, On Linux Client With Multiple Shares

[AntonRang]

My Retrospect 8.2 setup was reliably backing up several directories from a Linux client.

 

After upgrading to Retrospect 9, the first directory backs up correctly, but the following ones fail: (directory names changed slightly to protect the innocent)

 

 

+ Normal backup using Backup work areas at 11/14/11

To Backup Set Big Backup...

- 11/14/11 10:17:30 PM: Copying work on anton

11/14/11 10:17:30 PM: No files need to be copied

11/14/11 10:24:21 PM: Snapshot stored, 61.1 MB

11/14/11 10:24:36 PM: Execution completed successfully

Duration: 00:07:05 (00:06:45 idle/loading/preparing)

 

- 11/14/11 10:24:36 PM: Copying rang on anton

!Can't reserve backup client anton, error -515 ( Piton protocol violation).

- 11/14/11 10:24:39 PM: Copying mmmmm on anton

!Can't reserve backup client anton, error -515 ( Piton protocol violation).

- 11/14/11 10:24:42 PM: Copying cccccc on anton

!Can't reserve backup client anton, error -515 ( Piton protocol violation).

- 11/14/11 10:24:45 PM: Copying aaaaaaa on anton

!Can't reserve backup client anton, error -515 ( Piton protocol violation).

- 11/14/11 10:24:48 PM: Copying rrrrrrrr on anton

!Can't reserve backup client anton, error -515 ( Piton protocol violation).

11/14/11 10:24:52 PM: Execution incomplete

Total duration: 00:07:21 (00:07:00 idle/loading/preparing)

 

Whilst I just realized I might be able to work around this by re-directing my script to the top level directory, has anyone run into this?

 

I should probably drop a note to support too.

[twickland]

My Retrospect 8.2 setup was reliably backing up several directories from a Linux client.

 

After upgrading to Retrospect 9, the first directory backs up correctly, but...

!Can't reserve backup client anton, error -515 ( Piton protocol violation).

We saw exactly this same error message on our first attempt to backup a Linux client under Retro 9.

 

I went to Sources> Locate, entered the IP address of the Linux client (we connect to all our clients by direct IP address), and was then able to back up the client successfully.

 

Under Retrospect 8, we would occasionally lose communication with certain clients, and using the Locate feature (as opposed to the Refresh button) would restore communication. I'm hoping that this most recent error is a residue from Retro 8 rather than a continuation of that problem in Retro 9. I am actually encouraged by seeing the Piton protocol error message, since we never saw that message in Retro 8.

[gibsonm]

Well I decided to try Retro 9 for “old time’s sake” and wasn’t suprised.

 

Updated three clients correctly (one machine runs Windows Server 2033, the other two Mac OS X Server 10.5.8).

 

Results:

 

“Can't access volume Server II on BHF Server, error -519 ( network communication failed)“

 

and

 

“Can't reserve backup client XXXXX, error -515 ( Piton protocol violation)“

 

So its not just LINUX.

 

Suggestions so far from Roxio support (thought they were now Retrospect):

 

Delete all scripts and start again (great idea with some 20 scripts).

 

Backup entree volumes not just “favourites” (except we don’t want to backup everything due to time constraints).

 

All very disappointing since this part at least worked under 8.0x and nothing has changed apart from upgrading to 9.0x.

 

Sort of makes you wonder which “200+” bugs they did fix while letting this sort of fundamental issue creep in?

[Guest Steve Maser]

Well if you are testing Retro 9, you don't have to delete all scripts -- just stop the engine, move your config80.xxx files out and restart it. Then just add those specific clients to the "clean" config file and try backing it up to a new test media set.

 

If that fails, that might point to a client problem. If that works, it could point to a problem with your existing config80.dat file.

[9a8d718b-afcb-468c-9847-3045ab0148b4]

Same exact issue except as Gibsonm with the a 519 error. I have eliminated any network issues by connecting the server directly to the client. Still the same results. Looks like I'll be going back to version 8 unless this can be resolved quickly, Thank God for Cloud backup services!!

 

!Can't reserve backup client Lisa’s Computer, error -519 ( network communication failed).

[9a8d718b-afcb-468c-9847-3045ab0148b4]

Fixed the issue! De-installed the new version 9 client from the offending machine then repaired the permissions. Reloaded client and all is well! Guess I should have gone there 1st. Oh well..

 

 

 

 

 

Same exact issue except as Gibsonm with the a 519 error. I have eliminated any network issues by connecting the server directly to the client. Still the same results. Looks like I'll be going back to version 8 unless this can be resolved quickly, Thank God for Cloud backup services!!

 

!Can't reserve backup client Lisa’s Computer, error -519 ( network communication failed).

[twickland]

Same exact issue except... with a 519 error... !Can't reserve backup client Lisa's Computer, error -519 ( network communication failed).

There's actually a lot of difference between a -519 "network communication failed" error and a -515 "Piton protocol violation error." The -519 error may mean that a connection to the client was beginning to be established and then failed, typically due to a problem with the client computer but possibly also to problems with the network or the backup computer. It can also mean simply that the client was not found (same as a -530 error) if the client happened to be added by direct IP address. (The latter was almost always the case in out setup with both Retro 8 and 9.)

 

The -515 Piton error means that a connection with the client has been established, but that Retrospect sees something wrong with its handshaking procedure.

[twickland]

I mentioned above our -515 error with a Linux client and our solution. Since that time, I've found that the Piton issue in Retro 9 is both more extensive and more complicated than it first seemed.

 

Up until yesterday, I had been testing Retro 9 using a trial license code. The trial license enables a number of features, including open file backups of Windows machines. Most of the time we had been seeing error messages with our Windows clients like the following: "Can't use Open File Backup option for Documents and Settings on [Client name], error -515 ( Piton protocol violation)." However, Retro 9 would then back up the client volume or favorite folder, compare it, and apparently complete normally.

 

Yesterday, I entered a normal, paid license code for Retro 9 that did not include the open file backup option. This resulted in Retrospect's failure to back up most of our Windows and Linux client volumes, with an error message like:

 

- 11/29/11 1:42:25 AM: Copying /data on Client X

!Can't reserve backup client Client X, error -515 ( Piton protocol violation).

Yet, then in the same script, Retro 9 would sometimes immediately go on to successfully back up another volume or favorite folder on the same client:

- 11/29/11 1:42:30 AM: Copying research on Client X

11/29/11 1:43:14 AM: Snapshot stored, 9.5 MB

11/29/11 1:43:22 AM: Comparing research on Client X

11/29/11 1:43:38 AM: Execution completed successfully

Completed: 81 files, 6 MB

I should note that we don't perform a complete backup of any of our client machines; we back up only selected volumes and favorite folders. Some clients have only a single volume or favorite folder being backed up; others may have as many as five. Every Windows or Linux client failed to back up at least one volume or favorite folder due to a -515 Piton error. Some clients with two or three favorite folders failed to back up anything; other clients successfully backed up one or two volumes or favorite folders. The successfully backed up volumes/folders could occur anywhere in the series being accessed for that client: first, last, or middle. Running the script again would often successfully back up folders that had failed the previous time, and vice-versa.

 

Our Windows clients are mostly version 7.6.106; most of the rest are version 7.0.112, with a few at 7.6.107, 7.7.106, and 7.7.114. Linux clients are all 7.0.112. There appears to be no difference in behavior based on client version.

 

Our Mac clients all backed up successfully; all are either version 6.2.234 or 6.3.029 and none are running Lion.

 

I tried running Retro 9 with a default configuration, adding only one client with three favorite folders, one media set, and one script, and still hit the -515 Piton error with two of the three favorite folders.

 

 

[Guest Steve Maser]

Is there something specific about the *contents* of the Favorite Folders that are generating the -515 error?

 

Do those failing folders have *subfolders* you can try making favorite folders and see if you can isolate where the problem is occurring?

[twickland]

Is there something specific about the *contents* of the Favorite Folders that are generating the -515 error?

 

Do those failing folders have *subfolders* you can try making favorite folders and see if you can isolate where the problem is occurring?

While I could probably try a bit more diagnosis, the fact that we have around a hundred favorite folders and specific source volumes spread over 38 clients, and that every one of these sources has failed more than once, I think speaks to something more fundamental, either in this build of Retro 9 or in its interaction with our network configuration (our network gurus are very security-conscious and we need to use direct addressing even within the Retrospect server's home subnet). At this point I'm probably going to drop testing Retro 9 until the next build becomes available.

 

I remember an issue we had with Retro 6, where we were running into periodic Piton protocol errors with our Mac clients. As it turned out, the cause was pretty obscure: the error occurred only when Retrospect was switching to a new tape member while in the middle of backing up a Mac client for which link encryption had been enabled. It took us quite awhile to track that bug down, and I'm hoping that this current issue will turn out to be more obvious.

[Guest Steve Maser]

What version of Windows are you running?

 

Do the windows client back up correctly if you reboot them?

[twickland]

What version of Windows are you running?

Most clients are running XP SP3; a couple are running Windows 7 and have the v7.7 client. The Linux boxes are running some flavor of SuSE (I'd have to check).

 

Do the windows client back up correctly if you reboot them?

No difference after a reboot. Reverting to the Retro 9 trial license re-enables backup, but with the open files backup Piton error message on the Windows machines. The only complete cure is reverting back to Retro 8.2.

[Guest Steve Maser]

Huh, I thought the "open file backup" module was part of Retro 9 now for all versions -- but maybe that's only automatically added to the multi-server version (which is what I have...)?

 

If it were me (and it's not), I'd still be interested in trying to isolate the difference between why on one client *one* FF backs up and the other one doesn't. Maybe there are hard links that don't resolve (or something like that) in one FF that aren't in the other.

 

Without figuring out the exact issue to replicate it, it may be unlikely the Retrospect team would be able to figure out the problem based on a "it worked in 8.2, but not in 9.0" type report. If it's a function of hitting "open files" and barfing on them, it should be fairly easy to figure that out, I'd think (i.e., do the favorite folders back up if you reboot the computers and leave them at the login screen?)

[twickland]

If it were me (and it's not), I'd still be interested in trying to isolate the difference between why on one client *one* FF backs up and the other one doesn't. Maybe there are hard links that don't resolve (or something like that) in one FF that aren't in the other.

 

Without figuring out the exact issue to replicate it, it may be unlikely the Retrospect team would be able to figure out the problem based on a "it worked in 8.2, but not in 9.0" type report. If it's a function of hitting "open files" and barfing on them, it should be fairly easy to figure that out, I'd think (i.e., do the favorite folders back up if you reboot the computers and leave them at the login screen?)

The problem is, I haven't been able to replicate the backup problem. For example, for the client I mentioned that has three FFs, of three consecutive backup attempts, one backed up the first FF, one backed up the middle FF, and one backed up no FFs. I'm almost certain this particular client had no open files in any of the FFs during any of the backup attempts, and in most cases, would have had no changed files either. The Piton protocol violation error occurs when the initial connection is made. Under the license code that permits open file backups, the error message refers to that feature, but then the actual backup proceeds normally. Under the license code that does not permit open file backups, the backup fails completely with the -515 "can't reserve client" error message.

Edited December 1, 2011 by twickland

[Guest Steve Maser]

Is there any chance anything on the Windows end is causing this (like different IP address being assigned from the DHCP server between backup attempts?) (Which, I know, can be very hard to determine...).

 

And, of course, I'm assuming you attempted removing and reinstalling the Windows client (you mentioned you have a number of different versions running)? I have all my clients running the current 7.7 client with no issues like you report, but I'm sure my deployment of Windows differs from yours.

[twickland]

Is there any chance anything on the Windows end is causing this (like different IP address being assigned from the DHCP server between backup attempts?) (Which, I know, can be very hard to determine...).

I would say no. All clients (Windows, Mac, Linux) either have a fixed IP address or have an IP address reservation based on their Ethernet MAC address.

 

And, of course, I'm assuming you attempted removing and reinstalling the Windows client (you mentioned you have a number of different versions running)?

No, I haven't tried this (haven't had the time). However, the fact that several dozen Windows clients went south at the same moment suggests to me it's not a problem with all those client installations, but rather with some change in Retro 9.

 

Assuming that our experience has not been typical, that suggest to me that it's likely some interaction with our network that Retro 8.2 was not affected by. We have a pretty high level of network security, requiring among other things that all machines connected via Ethernet need to be registered or else they will see themselves as connected via a 172.xx address.

[twickland]

I just got a message in response to my bug report that the Retrospect engineers have been able to reproduce the Retro 9 -515 Piton error in-house and are working on a fix. The current workaround for those of us who are experiencing this problem is to use proactive scripts, or, as I've done, revert back to 8.2.

[derek500]

I just got a message in response to my bug report that the Retrospect engineers have been able to reproduce the Retro 9 -515 Piton error in-house and are working on a fix. The current workaround for those of us who are experiencing this problem is to use proactive scripts, or, as I've done, revert back to 8.2.

 

That's good to hear. I cannot use proactive scripts for all my clients. Since upgrading from 8.2 to 9 I've been having the same problem - many of my Windows clients do not back up _sometimes_, giving the -515 Piton protocol violation error within seconds of connecting, and are skipped. It's not consistent, my clients back up some nights but not others on the same script. I had no problems at all with 8.2.

 

Fortunately I am still in testing mode - I was just about to go 'production' with my 8.2 install when 9 came out. Hoping they had addressed some of my complaints with 8.2 I pulled it up right away, but now I'm thinking I'll just go back to 8.2 again. We desperately need to start backing up Windows 7 and 2008 clients, so I am anxious to move from Retro 6. Also, I need stability to _improve_ from version to version, not the other way around!!!

 

I opened a support ticket about this issue just before coming to find these forum posts. Hopefully the fix is released quickly. Thanks for your update.

[Guest Steve Maser]

Out of curiosity, why could you not use Proactive Scripts for all your clients?

[derek500]

Out of curiosity, why could you not use Proactive Scripts for all your clients?

 

Sorry for the delay, I didn't see your reply. I have scheduled scripts run every night, backing up servers with one script, desktop clients with a different script (and different rules. They are scheduled to start 1 hour apart, so even though it takes longer than 1 hours to back up all the servers, the desktop backups begin whenever the server script has finished. Then whenever those scripts have completed, I have a 24 hr proactive proactive script (backing up laptops) that stays active until the following night when the scheduled scripts begin again. I have a few jobs that run backups on the server clients, and I want to wait until they are complete before starting their backup.

 

Could this be done with proactive scripts? I suppose so, but I would have to change the way I think about the scripts. What happens when a system gets more data than usual, and takes longer to back up? This would throw off the timing alloted for those scripts to run, wouldn't it? Can you have multiple proactive scripts running at the same time to make use of different rules?

[Guest Steve Maser]

Yes, you can have multiple proactive scripts running at once (I frequently have 4-5 running simultaneously) -- but they all back up to different media sets.

 

If you were backing everything up to *one* media set, there could be issues with getting everybody backed up within a 24-hour period (if one or more client suddenly dumped a bunch of new data on the client computer), I supposed. I'm guessing you know if that happens often enough that it would be an issue.

[minidomo]

I ran into the problem with "Piton protocol violation" after upgrading a Retrospect SIngle Server from version 8 to 9.0.0 (319). The RSS I'm working with does backups of 4 Macs and 2 Windows clients, and it started running into this problem with just one of those Windows clients. Both systems were running Windows 7 Professional (32-bit) with Retrospect Client 7.7.114. Like the person who originally posted this question, I noticed that the problematic client would get the first item to backup but then get the Piton error on all subsequent backups. The script was set to backup two folders on the Windows client into a single file stored on the RSS Mac. So I duplicated the script, set each script to only backup a single folder on the Windows server (but had each script write to its own individual backup file), and then scheduled the two scripts to run 5 minutes apart. That has solved the problem for us.