Jump to content
cgtyoder

Cannot get macOS client out of "backup client reserved" state

Recommended Posts

Environment: Retrospect Desktop 16.5.1.109 on W10 Pro 1909 x64. Client: macOS 10.14.6, Client version 16.5.1.104.

My last successful backup of this client was a week ago - not sure what has changed in the meantime. In R Desktop, when I go to Configure -> Clients -> <mac client> -> General Tab -> click 'Refresh', I get the error Sorry, couldn't connect to <client name>, error -505 (backup client reserved.) And the Properties dialog is very unhappy and keeps giving me that error.

I tried reinstalling the client on the Mac, and that succeeded (seemingly), and I go back to the client properties in R Desktop and click Refresh, all is good. But the Retrospect client is still seemingly locked in On(?) mode yet the On/Off toggle is greyed out, and there is a warning triangle to the left of the On/Off toggle, which says "Disabled by administrator" if you mouse over it. (The client is not disabled in the General tab in Retrospect Desktop.) If I go through the tabs in the client Properties window, all is good, but if I go the Volumes tab, the dialog hangs, I have to cancel to get out of it, and we are back to everything resulting in the -505 backup client reserved error.

What do I need to do to get this fixed?

Share this post


Link to post
Share on other sites

cgtyoder.

First, possibly you should have posted this in the Retrospect 9+ Mac Forum, since it has to do with a problem with a Macintosh "client" machine—even though your "backup server" is a Windows machine.  Based on my past experience, you're likely to find that the -505 error is caused by something else running on the "client" machine that is interfering with the Retrospect Client software.  I predict that when you dig into "not sure what has changed in the meantime", you'll have to talk to whoever maintains your Mac "client"'s software.

Here is my initial post, from 2017, in a thread on jweisbin's -505 error.   The short version is that, in 2016, I had discovered my own problem was because Adobe Flash Player Install Manager.app was repeatedly trying to update my MBP even though the latest version of Adobe Flash Player was already installed.  However in the remaining posts in the 2017 thread, I speculated that the ChronoSync "backup server" equivalent was— scheduling ChronoAgent's synchronization of an individual Mac for which the OP in that thread was responsible—interfering with its Retrospect Client.  We never got a jweisbin reply.

Share this post


Link to post
Share on other sites
8 hours ago, cgtyoder said:

I tried reinstalling the client on the Mac

Did you uninstall first, or just re-install over the top?

My go-to for a manual Mac uninstall is still Der Flounder's instructions for 6.x -- I just do each line of his script manually in the Mac Terminal app, ignoring any that don't autocomplete/exist.

In this case, if you want to save time you could probably just get away with killing the client, killing pitond, deleting retroclient.state (the "I am reserved"-causing file) and restarting the Mac.

Share this post


Link to post
Share on other sites

cgtyoder,

Nigel Smith, who has experience administrating an extensive LAN—which I don't have, is assuming the Client on your Macintosh machine has "gone bad" in a one-shot occurrence.  OTOH I, based on my prior experience, am assuming there is something making it systematically and repetitively generate -505 errors.  Try what Nigel Smith suggests; then, if that doesn't permanently solve the problem, investigate along the lines of what I have suggested.  Please let us know in a post here what you found.

P.S.: This morning I'm a lot more receptive to the idea of Retrospect Mac Clients "going bad" in a one-shot occurrence than I was 24 hours ago.  The OP in this thread describes my experiences starting last summer getting -559 (network connection timeout) errors up to 2 hours into the 3-hour Saturday-morning Recycle backup of my MacBook Pro.  The last post in that thread describes my October 28th conclusion that, based on my having acted on Nigel Smith's suggestion that I change the System Preferences -> Energy Saver settings, the problem had been caused by a change in macOS 10.13.  But yesterday morning I got a network connection timeout for my  MBP (without any -559 error) about an hour into my Saturday morning backup.  I switched back to my slower 4-year-old Actiontec MoCA 1.1 adapters (see the second paragraph in the linked-to OP), and tried running No Media Action (Retrospect Mac name for Normal) backup scripts—all of which failed with -530 errors even though my MBP was running because the Client kept switching itself off despite reboots.  What I finally did was to Remove the MBP from my "backup server"'s Sources, re-run the Uninstall and Installer apps for Retrospect Client 16.1 on my MBP, and re-Add the MBP to the "backup server"'s Sources and Scripts.  I have been re-running the Recycle backup since 1:44 a.m.; it finished backing up and comparing the MBP at 5:57 a.m., and has nearly finished backing up the second of two local disks on my "backup server".  Conclusion: something made the Client on my MBP "go bad"—and "stay bad"—in a one-shot occurrence.  I'm still on 16.1, because it appears 16.5 is a "bad release".

Edited by DavidHertzberg
P.S.: This morning I'm a lot more receptive to the idea of Retrospect Mac Clients "going bad" in a one-shot occurrence

Share this post


Link to post
Share on other sites

To be clear -- I don't think his client "went bad", I think it just got stuck in a reserved state and simply deleting the retroclient.state file and restarting the Mac would have cleared it. I often see "-505s" here, sometimes because the server borked and, more often, because the client was deliberately disconnected (eg laptop lid closed or network plug pulled) partway through a backup.

It used to be a simple command-click on the client control panel's "Off" button (a simple click turns the client off but leaves the process running and the .state file untouched, cmd-click shuts down the process and removes the .state file) -- I don't know if the same works with "modern" versions, but we lock ours down anyway so the user can no longer solve this themselves and it's easier for me to visit than explain Terminal commands to them 🙂

What I don't trust is a re-install, especially without a full and complete un-install first -- though that may just be me and the fact that I'm dealing with clients of various vintages (because it is easier to sort things out when these rare problems rear up, rather than proactively update).

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×