Jump to content

Yet another -530 client not found error


x509

Recommended Posts

Nigel Smith, and MrPete,

Getting back to what Gilbert and Sullivan might have termed the "poor wandering laptop", I have two suggestions for that -530 problem.

My first suggestion is based on henry-in-florida's suggestion, which I tried in late 2018 and which worked.  That is to define the laptop as a Source using Subnet Broadcast, and to define all possible Subnets on which the laptop might appear (see pages 228–9 of the Retrospect Windows 17 User's Guide).  If you do so, the "backup server" uses Piton Name Service in turn on each defined Subnet to find the "client" by its Computer Name (or the Windows equivalent).  This, of course, assumes that the "client"'s Computer Name is not used for different machines in different Subnets; if e.g. Martha in Meteorology takes her laptop from the Science Building when she goes over to the Engineering Building to work with Martha in Materials Engineering on designing a sturdy mast for measuring wind speeds inside tornadoes, and each woman has a different machine named "Martha's Machine", the "backup server" will get confused.  Subnet Broadcast actually solved my -530 problem for a month starting in 2018 even though IIRC I had no defined Subnets, but I then switched over to using Direct Access with fixed DHCP IPs defined in my router.

The second suggestion is based on an approach I came up with in early 2017, when I started getting -530 errors after upgrading an Ethernet switch.  That is to add a preliminary "sacrificial" Backup script  backing up each "wandering laptop", as described most clearly in the second paragraph of this June 2019 post.  You don't care whether or not the "sacrificial" script gets -530 errors, because using the No Files Rule (No Files Selector for Retrospect Windows) means it's not going to back up any files regardless.  The cost is 4 minutes or so of run time.

The voodoo idea behind both of these suggestions is that a "client" needs time to "straighten up and fly right", rather than being backed up immediately by a "backup server" Engine that is in the process of initializing itself.

 

 

Link to comment
Share on other sites

2 hours ago, DavidHertzberg said:

Getting back to what Gilbert and Sullivan might have termed the "poor wandering laptop", I have two suggestions for that -530 problem.

Neither of which will work, because it is an RS client/OS problem.

You can see how it should work with your Mac. Have the Client Preferences open while you are on your ethernet network, then unplug the ethernet and join a wireless network. RS Prefs will read "Client_name Multicast unavailable"  in the "Client name:" section for a while (still bound to the unplugged ethernet) and then switch to the new IP address and read "Client_name (wirelessIPAddress)".

(Going from memory, exact messages may be different, but you can see a delay then a re-bind to the new primary IP.)

But in the same situation, Windows RS Client will go from the ethernet-bind to self-assigned-IP-bind but not then switch to the new wireless primary IP -- it gets stuck on the self-assigned address. Whether that's RS Client or Windows "doing it wrong" is something they can argue about amongst themselves...

It does suggest another solution, though. That self-assigned IP is always in the 169.254.*.* subnet. If you are in a single-subnet situation and can configure your DHCP server appropriately you could have your network only use addresses in 169.254.*.* range, and both DHCP- and self-assigned addresses will be in the same subnet and the client will always be available. 

  • Thanks 1
Link to comment
Share on other sites

MrPete and Nigel Smith,

I see MrPete diagnosed the Windows Client problem—under "Here are anomalies ..."—in an up-thread post last October.  It's that Windows is assigning an APIPA address, possibly because DHCP services are not available in the "wandered-to" subnet.  This krypted article gives a brief explanation, and also outlines (one can Google "APIPA Windows" for detailed—and possibly obsolete—instructions) a way of disabling APIPA for the laptop.  Of course one should also investigate why DHCP services aren't available in the "wandered-to" subnet; maybe there's a problem with that subnet's router.

Now let's consider how the Retrospect engineers might fix the APIPA problem entirely in the Windows Client, without allowing and requiring the laptop user to manually stop and restart the Client (see pg. 237 of the Retrospect Windows 17 User's Guide).  This would be an automated version of running a stop/start script to do it.  The Client would have to detect that it had been assigned an APIPA address, and then to stop and restart itself.  Based on my obsolete and cursory Computer Science knowledge, that would require the Client to be multi-threaded—with the stopping and restarting of the main thread embodied in an auxiliary thread.  Based on my observation of the history of Retrospect, combined with my complete lack of knowledge of the Client source code, I doubt that the Windows Client is now multi-threaded.  So IMHO fixing bug #8512 would demand a significant engineering effort.

I had a phone conversation with someone in Sales this afternoon, and there's a 17.1 release planned for September that may include a fix for bug #8512.  An alternative "motivating" approach would be to send an e-mail to the new StorCentric boss of the head of Retrospect Tech Support, who may have influence with Retrospect engineers.  He's David Bartizal, and his e-mail address is dbartizal@storcentric.com.  That address was supplied by the VP Service & Support himself, in the e-mail conveying his request to fill out a SurveyMonkey survey on handling of an unrelated Support Case.

P.S.: The automated-stop-restart solution I suggested in the second paragraph would be inappropriate for an installation set up per Nigel Smith's last paragraph directly above,  and for one that isn't supposed to have a router—because the krypted article says "APIPA is a dhpc mechanism that provides dhcp clients with self-assigned IP addresses when DHCP servers are not available."  How would you disable the automated-stop-restart solution in such cases?  Possibly the Retrospect "backup server" could be enhanced to automatically create and test a 192.168 ... Subnet if there are no Subnets defined, and set a flag in every Client installed using that "backup server" if the 192.168 Subnet fails the test.  Would disabling per that flag do the trick?

Edited by DavidHertzberg
P.S.: The automated-stop-restart solution I suggested in the second paragraph would be inappropriate for an installation set up per Nigel Smith's last paragraph directly above, or for one that isn't _supposed_ to have a router
Link to comment
Share on other sites

On 8/29/2020 at 2:38 AM, DavidHertzberg said:

It's that Windows is assigning an APIPA address, possibly because DHCP services are not available in the "wandered-to" subnet.

The problem isn't with the network being joined.

When you switch between networks on Windows there can be a "temporary bind" to the self-assigned IP because there's a period when no external network is available. Think of an old-fashioned A/B rotary switch -- as you turn it from A to B there's a moment when neither A nor B are connected.

The problem is that when the new network is joined, either Windows doesn't tell RS Client or RS Client refuses to listen (or both! Or something else -- this is Windows, after all 😉). We can nudge things with stop/start, ipsave, or your suggested automation, but these are just workarounds until the engineers (from whichever company) fix the problem.

Link to comment
Share on other sites

On 5/29/2020 at 6:24 PM, MrPete said:

Hi all! Sorry for the long delay. The Real World is intense for me right now :)

The following simple sequence has been a 100% reliable workaround for me:

1) AFTER an endpoint is stably connected to a LAN via any mechanism (wired, wifi, etc)...

2) Restart the Retrospect Client service (stop / start as described earlier)

The client NEVER gets confused under such conditions, at least in my way-too-extensive testing.

Confusion arises when the client initializes at the same time as the computer is initializing various things, including a variety of network-connected startup services etc. And/or if the network connection changes (eg wired to wifi, or to a different wifi.)

Oh it's a long long way, from October [2019] to May [2020].

Nigel Smith,

You said directly above:

Quote

We can nudge things with stop/start, ipsave, or your suggested automation, but these are just workarounds until the engineers (from whichever company) fix the problem.

My impression—subject to correction—is that MrPete is saying ipsave doesn't work in his circumstances, which include a "client"'s network connection changing.  However Retrospect Mac has for years had an option preventing a "client"'s user starting or stopping the Client (pp. 85-86 in the Retrospect Mac 17 User's Guide), and Retrospect Windows has the same option (pp. 236-237 in the Retrospect Windows 17 UG).  AFAIK Product Management had the engineers add this option, years ago, because some ordinary users were suppressing Retrospect backups to avoid slowing down their "client" machines.  My suggested automation would simply enable the Client to do its own stop/start, without allowing or requiring the machine's user to do it.

I recommend that you avoid holding your breath waiting for either Retrospect "Inc." or Microsoft to come up with a permanent fix to the underlying problem.  Retrospect engineers seem too busy implementing StorCentric's priorities (2nd long prgf.) to do a deep analysis required for a permanent fix.   Microsoft may consider the problem too unimportant for most Windows users to have its own engineers do the analysis and fix.  That's why I suggest the stop/start automation, which may be simple enough for a Retrospect engineer to do while waiting for Drobo hardware to become available again.

P.S.: What I wrote in the preceding paragraph may have been too pessimistic. 😁  I just talked to someone in Retrospect Sales about another matter, and a fix for bug #8512 is supposed to be in a Retrospect 17.X release scheduled for September–October 2020.  So you can start holding your breath.

Edited by DavidHertzberg
In first long paragraph, option preventing a "client"'s user from starting or stopping the Client is in fact documented in the UGs; in 2nd long paragraph, add links. P.S.: A fix for bug #8512 is scheduled for Sept.–Oct. 2020
Link to comment
Share on other sites

On 9/2/2020 at 7:10 PM, DavidHertzberg said:

My impression—subject to correction—is that MrPete is saying ipsave doesn't work in his circumstances

His contention is that it's a lot easier for his users to simply turn RS off and on than it is to find the new IP address and use that (somehow!) in an ipsave command -- and I have total sympathy with his view! That would be my default fix too -- as long as (as you've also said) admins haven't disallowed turning off RS.

Link to comment
Share on other sites

Hiya, I am back from travels (and now have alligators to fight off ;) )

1) Bug #8512 is Windows ONLY. I have no comment on MacOS with respect to this.
2) I have no comment on ipsave. Have not played with it as I have no reason to do so. (Yes, my perspective, even scripted: if I'm gonna write an effective script that waits around for a proper and stable dynamic IP, it is much easier in my context for the last two steps to be: (stop service // start service) than (discover the correct ip among possibly 4 or more available ip's // format correctly // issue a proper ipsave) ;) )

I did hear back from RS support, who spoke with engineering. YES, a fix for #8512 was delayed, but it IS being worked on.

A Big Picture comment: for many reasons, dynamic networking is becoming more complex, not simpler. I easily remember when laptop vendors had a simple monitor service that would auto-switch between wired and wifi ethernet. Now... not so easy in all contexts.

Link to comment
Share on other sites

On 9/4/2020 at 1:15 PM, Nigel Smith said:

His contention is that it's a lot easier for his users to simply turn RS off and on than it is to find the new IP address and use that (somehow!) in an ipsave command -- and I have total sympathy with his view! That would be my default fix too -- as long as (as you've also said) admins haven't disallowed turning off RS.

Nigel Smith,

This KB article says "The Retrospect Client uses the ip and ipsave commands to allow users to direct Retrospect backup traffic through a specific IP address if it is available to the machine the client is installed on."  IMHO that means the only way manual ipsave might be made to work is if [1] the "client"'s user knows the the IP address of the "backup server", and [2] the "client" machine—which has "wandered" by either being physically moved to another subnet or by having its IP adapter switched from from a cabled to to a WiFi connection (or vice versa)—can still connect to that "backup server" IP address.  However IMHO that would only work if the "client" is set up as a Remote Client and is backed up with a Proactive script, in which case the Client takes the initiative in contacting the "backup server".

The -530 problem MrPete and x509 are dealing with is that—as diagnosed by MrPete in this up-thread post—the Retrospect Client for a particular "client" is getting confused,  either by getting assigned a virtual interface by  Windows APIPA or VMWare, or by a security system, or by a router.  That means the "backup server" can't contact the Client for a non-Remote backup.  MrPete's solution is to "unconfuse" a "client"'s Client by restarting the Client.  As for APIPA, this article says "The APIPA service also checks regularly for the presence of a DHCP server (every five minutes, according to Microsoft). If it detects a DHCP server on the network, APIPA stops, and the DHCP server replaces the APIPA networking addresses with dynamically assigned addresses."  So making the "backup server" wait 5 minutes before trying to back up a "wandering" client" might do the trick.

However I just remembered this trick for "unconfusing" a "client"'s Client, which worked for my MacBook Pro "client" when I was still Adding it to my Retrospect Mac "backup server" with Use Multicast instead of Add Source Directly (using a fixed IP address)—which MrPete has said doesn't solve his -530 problem.  This suggests having the Retrospect Windows "backup server" automatically do the equivalent of Retrospect Mac's Locate (page 51 of the Retrospect Mac 17 User's Guide) 15 minutes before it starts to back up each particular Backup script "client".  If the "client"'s Client has been assigned a virtual interface by  Windows APIPA, the Locate-equivalent alone should "unconfuse" it.  If OTOH the "client"'s Client has been assigned a virtual interface by VMWare, or has gotten confused by a security system or a router, then the Locate-equivalent will fail—in which case the "backup server" should send an e-mail to the Retrospect administrator.  I suggest doing the Locate-equivalent 15 minutes in advance because the Retrospect administrator, upon receiving the e-mail, may have time to fix the "client"'s problem before the script begins to back it up.  Looking at a post in another thread later, I was reminded that the "backup server" already does "reaching out" to Proactive script "clients" per steps 3 and 4 of this KB article —so extending that "reaching out" as a Locate-equivalent for Backup scripts wouldn't be as "effortful" as the first sentence of the next paragraph says.

But that at first seemed effortful, so here's another way or "unconfusing" a "client"—an extension to the suggestion I made in the second paragraph of this up-thread post:  Have the "backup server" store its own IP address, which I'll call the "ipsave address", in the Client of each "client" machine added to its Sources.  Then, when a "client"'s Client starts up, let it try to contact the "backup server" at the "ipsave address".  If it can't, then the "client"'s Client should restart itself—because it must have been "confused" by being re-assigned an address by APIPA or by VMWare or by a security system or by a router.  (This is based on the "if I can't see you, then you probably can't see me" principle we all learned as children playing hide-and-seek.)   A "client"'s Client successfully contacting the "backup server" for address verification would only be a slight variation of what is already done by a Remote Backup "client".  Possibly there should be a script run option to wait 5 minutes before backing up a "client" whose Client has not contacted the "backup server".

P.S.: I have now created Support Case #75559, from this post preceded by links to appropriate preceding posts in the thread.

 

Edited by DavidHertzberg
As a result of further inspiration, add third paragraph; add final sentence to it. As a result of even-further inspiration, add fourth paragraph; add final sentence to it. P.S. I have now created a Support Case.
Link to comment
Share on other sites

On 9/8/2020 at 1:02 AM, DavidHertzberg said:

IMHO that means the only way manual ipsave might be made to work

Manual ipsave has been working for years, well before Remote Clients were even thought of. Particularly useful for dual-NIC machines where eg the primary interface (which RS Client will generally try to bind to) is the general network or "outside world" while the secondary (which you want RS Client to bind to) is connected to a backup or "internal" network. It's most useful for machines with static IPs since you just do it the once.

As said before, it's also a good work-round for the "confused client" issue for those who don't allow their users to turn the Client off-and-on-again. But it is more involved since the user (or a script) has to determine the IP address to be used.

Note that pretty much anything done server-side will not help because the "confused client" is rarely bound to an address that the server can reach.

Link to comment
Share on other sites

On 9/15/2020 at 3:23 PM, Nigel Smith said:

Manual ipsave has been working for years, well before Remote Clients were even thought of. Particularly useful for dual-NIC machines where eg the primary interface (which RS Client will generally try to bind to) is the general network or "outside world" while the secondary (which you want RS Client to bind to) is connected to a backup or "internal" network. It's most useful for machines with static IPs since you just do it the once.

As said before, it's also a good work-round for the "confused client" issue for those who don't allow their users to turn the Client off-and-on-again. But it is more involved since the user (or a script) has to determine the IP address to be used.

Note that pretty much anything done server-side will not help because the "confused client" is rarely bound to an address that the server can reach.

Nigel Smith,

I'm sorry my last up-thread post consists of four lengthy paragraphs.   I felt I had to present my alternative proposals side-by-side in the same post, in order to avoid having the reader bounce back-and-forth between different posts.

First, with regard to all my paragraphs except the third, let's go back to what "came out of the horse's mouth" on 5 SeptemberMrPete said:

Quote

2) I have no comment on ipsave. Have not played with it as I have no reason to do so. (Yes, my perspective, even scripted: if I'm gonna write an effective script that waits around for a proper and stable dynamic IP, it is much easier in my context for the last two steps to be: (stop service // start service) than (discover the correct ip among possibly 4 or more available ip's // format correctly // issue a proper ipsave) ;) ) 

The proposal in my fourth paragraph is to first automate what MrPete said—after the quoted word "than"—would be less easy to do manually.  The user (or a script) wouldn't have to do those things if the user's Client had stored within itself—by the "backup server" at Add time—a pre-formatted "ipsave address" for the "backup server".  As I said in that fourth paragraph, if the Client found that automation didn't work then it would know (based on the "hide-and-seek principle") it has to restart itself—because otherwise the "backup server" at that "ipsave address" won't be able to contact the Client at the address the Client is bound to.  This proposal would also get around the messy fact that an administrator who won't allow the user to stop and start his/her Client probably doesn't want that same user to be mucking about with a manual ipsave.

The proposal in my third paragraph emerged from my memory after I drafted all my other paragraphs.  Despite what you said in the last paragraph I've quoted at the top of this post, the fact is that a Retrospect Mac Locate command did work when I was having trouble with "clients" Added via Use Multicast—precisely in the case that the "confused client's" Client was bound to an address that the server couldn't reach.  Since what's activated by a Retrospect Mac Locate command must be in the Engine's code—which is common to both Retrospect Mac and Retrospect Windows, there undoubtedly is a way of activating a Locate-equivalent that will work for Windows and Mac variants.  Figuring out what—if any (because the Retrospect Windows GUI has been intentionally "frozen in stone" since version 7.7)—command in Retrospect Window's GUI is equivalent to a Retrospect Mac Locate is "above my pay grade", but the engineers should be able to activate underlying common Engine code per the proposal in my third paragraph.

P.S.: I have now, crediting you, added your post directly below as an Additional Note to Support Case #75559.

Edited by DavidHertzberg
P.S.: I have now, crediting you, added your post directly below as an Additional Note to Support Case #75559.
Link to comment
Share on other sites

The confounding issue is that Macs behave "properly" -- when a "new" primary interface becomes "live" the client will, eventually, switch to it. On Windows the client often gets stuck -- I most commonly see it when users have started/woken their laptop up (client binds to wireless) then connect to the ethernet (which takes precedence for network traffic, but the client is still on wireless), but I've also seen what MrPete describes (client binding to internal IP during network change, and not releasing).

That you are using Macs, plus the relatively simple nature of your home network, means that your suggested automated work-rounds will (probably) work. In more complicated situations, with Windows clients, that's far less likely. While I'm sure it could be made to work, the real solution is to fix the problem (which, hopefully, that in-progress-but-delayed bug fix will do).

  • Like 1
Link to comment
Share on other sites

  • 3 weeks later...

After futzing around for a while, and then futzing around some more, I think I discovered the issue that I'm having, and it's only on one of two laptop clients.  Retrospect client status is OFF, and there is no way for the client to turn itself back on.  How is that?  So I used Windows Task Manager to shut down all Retrospect tasks.  Then I ran the main Retro client program again.  No luck.

The ONLY way to get the Retrospect Client to be ON was to reboot Windows.  Note that I have two laptop clients, both running Windows 10 but Retrospect client operation on the second machine has been problem-free.

I'm currently running the last version of Retrospect 16 on both the main system and clients.

x509

Link to comment
Share on other sites

x509,

How soon we forget! 🤣  Here's a December 2019 post by you yourself in this Forum, telling how you solved what seems to be this very problem on one of your "client" machines by thoroughly un-installing and re-installing the Retrospect Windows Client.  My preceding post in the same thread pointed out that there's supposed to be a Protected by Retrospect Server checkbox line, described on page 304 of the Retrospect Windows 16 User's Guide, in the Retrospect Client Control Panel.

However on page 305 of the same UG there's an Allow Clients to Turn off the Retrospect Client Software preference in Configure > Clients in the "backup server" console sidebar.  Maybe you've un-checked that preference for this particular "client", which would explain why "there is no way for the client to turn itself back on."  The preference was added years ago; users with slow "client" machines were turning off their Client to disable backup.

P.S.: Retrospect Windows 17.5.0.237, released on 23 September, doesn't contain a fix for bug #8512.  MrPete says the bug is only in the Windows variant, but I don't see why at least the cause—if not the must-reboot-the-"client"-machine fix—isn't the same in the Mac variant as well.

Edited by DavidHertzberg
P.S.: Latest Windows release doesn't fix bug #8512. Link to Retrospect Windows _16_ UG, since that's what x509 is running.
Link to comment
Share on other sites

6 hours ago, x509 said:

Retrospect client status is OFF, and there is no way for the client to turn itself back on.  How is that?

That's usually a temporary "lock" file that isn't being cleared. Killing processes won't do it, but you can manually delete it or reboot (which generally clears temp files).

My Windows troubleshooting can be summed up as "turn it off and on again", so I reckon you did the right thing 🙂 -- but maybe MrPete will chip in at this point?

Link to comment
Share on other sites

That's usually a temporary "lock" file that isn't being cleared. Killing processes won't do it, but you can manually delete it or reboot (which generally clears temp files).

My Windows troubleshooting can be summed up as "turn it off and on again", so I reckon you did the right thing 🙂 -- but maybe MrPete will chip in at this point?

 ---------

Nigel,

I think Occam's Razor applies here.  The idea of a lock file being present is a lot simpler than all the energy around IP addresses.  In any case, if I knew what lock file to delete (or even how to find it), I would just set up a daily script to delete that file.  As things stand now, I have to inspect Retrospect logs to see when my client "L" is not being backed up.

 

Link to comment
Share on other sites

14 hours ago, x509 said:

I think Occam's Razor applies here.  The idea of a lock file being present is a lot simpler than all the energy around IP addresses.

Two different cases.

For the IP address thing, the Client is running and you can check it to see state, client IP address, etc (though I can't remember if it reports the primary IP and "Multicast unavailable" when bound to the "wrong" address, or the "wrong" IP).

In your latest case, the client isn't running. And every time you try to start it, it launches, sees the lock file, decides it is already running because there is a lock file, and quits. If it was my Mac I'd be straight in with

sudo rm -f /Library/Preferences/retroclient.state

...which will usually clear the problem. But when it's a user's Mac I have no idea how they got into that state (forced a reboot? Got creative killing processes in Activity Monitor? Simply have so long an uptime that things are going flakey?) so it's usually better to tell them to restart properly so their machine carries on in a known "good" state.

But what you don't want to do is delete the file when there isn't a problem!

14 hours ago, x509 said:

As things stand now, I have to inspect Retrospect logs to see when my client "L" is not being backed up.

Let RS do that for you. Use the "No backup in n days" report, set to whatever number of days is appropriate (1?). Use script hooks to send yourself an email when the backup fails (if a scheduled script). Set the client "Notifications" pane to "Notify if no backup in n days". Plenty of ways for you to be told, rather than you waste your time looking!

Laziness, FTW!

Link to comment
Share on other sites

x509,

Nigel Smith's suggestion in the next-to-last paragraph directly above is excellent.  However if the lock file hypothesis is correct, it sound as if the "client" you now refer to as "L" is never backed up.

I will use my immense psychic powers 🤣 to guess that your client "L" is actually the same "Lenovo730" you were talking about in the OP a year ago today (Happy thread Anniversary!).  And two months later you solved a problem with what is probably the same "client" computer by doing this.  So why not do it again, which should get rid of any lock file that is related to "L"'s Client?

But I also notice that the Lenovo Yoga 730 came out about 2.5 years ago.  With two similar problems in one year, is it possible that your C:\ drive is failing in a way that affects the Client?  Nigel Smith or Lennart_T can advise you better than I can on how to test that.

Link to comment
Share on other sites

13 hours ago, Nigel Smith said:

Two different cases.

For the IP address thing, the Client is running and you can check it to see state, client IP address, etc (though I can't remember if it reports the primary IP and "Multicast unavailable" when bound to the "wrong" address, or the "wrong" IP).

In your latest case, the client isn't running. And every time you try to start it, it launches, sees the lock file, decides it is already running because there is a lock file, and quits. If it was my Mac I'd be straight in with


sudo rm -f /Library/Preferences/retroclient.state

...which will usually clear the problem. But when it's a user's Mac I have no idea how they got into that state (forced a reboot? Got creative killing processes in Activity Monitor? Simply have so long an uptime that things are going flakey?) so it's usually better to tell them to restart properly so their machine carries on in a known "good" state.

But what you don't want to do is delete the file when there isn't a problem!

Let RS do that for you. Use the "No backup in n days" report, set to whatever number of days is appropriate (1?). Use script hooks to send yourself an email when the backup fails (if a scheduled script). Set the client "Notifications" pane to "Notify if no backup in n days". Plenty of ways for you to be told, rather than you waste your time looking!

Laziness, FTW!

Since the client in question is a windows machine I can't run "sudo."

However, I have never given any attention to scripts.  Right now, I look at the History tab, and if I see error messages, that's an indication of a problem or issue.  I like the scripts idea, though.

Link to comment
Share on other sites

1 hour ago, DavidHertzberg said:

x509,

Nigel Smith's suggestion in the next-to-last paragraph directly above is excellent.  However if the lock file hypothesis is correct, it sound as if the "client" you now refer to as "L" is never backed up.

I will use my immense psychic powers 🤣 to guess that your client "L" is actually the same "Lenovo730" you were talking about in the OP a year ago today (Happy thread Anniversary!).  And two months later you solved a problem with what is probably the same "client" computer by doing this.  So why not do it again, which should get rid of any lock file that is related to "L"'s Client?

But I also notice that the Lenova Yoga 730 came out about 2.5 years ago.  With two similar problems in one year, is it possible that your C:\ drive is failing in a way that affects the Client?  Nigel Smith or Lennart_T can advise you better than I can on how to test that.

Yes, client "L" is a system with name Lenovo730.  It's my wife's system and she chose that name.  My other laptop client is also a Lenovo T-series, with a name starting with "D."  

I would like a solution that doesn't require constant maintenance.  I'm not quite there yet.

x509

Link to comment
Share on other sites

x509,

I'm now going to get myself into trouble by venturing into the sociological aspects of client-server backup. 😃  Assuming "client" machine "Lenovo730"'s C:\ drive is OK, then—based on what Nigel Smith has said and what you've said above—it sounds as if your wife is occasionally doing something to her machine while Retrospect is backing it up.  My guess is that she's either rebooting it or shutting it down or removing it from an Ethernet connection while the backup is running, and that's what's generating the Client lock file.  I wouldn't recommend holding your breath while the Retrospect engineers develop a facility for having a robotic arm reach out of the "client" to slap her hand when she tries to do that. 🤣

Therefore let's consider doing what I did for the last 10 years I was married.  I wrote Backup scripts—not Proactive scripts—scheduled to run at 3 a.m. or later to back up both our machines, and I booted both "clients" followed by the "backup server" whenever we had breakfast.  So both of our "client" machines got backed up once a day; No Media Action (Normal) on weekdays and Recycle (to a newly-swapped-in destination with the swapped-out destination going off-site)—with a script that also backed up the "backup server"—on Saturdays.  (IIRC I originally scheduled these backups to be done while we were getting ready for bed, but the noise of a tape drive executing the Recycle script in the bedroom turned out to interfere with our sleep Saturday night to Sunday morning.)  We both learned to do Save As for any document changes  that wouldn't be backed up until the following morning, and we treated Saturday mornings in accordance with the no-work Jewish Sabbath (despite her being Catholic).  Although now alone, I still do this.

If my guess is incorrect or my solution is unacceptable, let's return to the question of "constant maintenance".  Contrary to what Nigel Smith speculated above, this 2016 Knowledge Base document—though for a different error—implies that there is no Retrospect Windows equivalent for Retrospect Mac's retroclient.state file.  This post in a 2014 thread by the head of Retrospect Tech Support—again for a different error—implies the same thing.  So it appears there's no alternative to what you reported doing in December 2019—which is Client delete and reinstall. A Client, even multi-threaded (2nd paragraph here), couldn't delete and reinstall itself.  You can at least eliminate the monitoring part of the "constant maintenance" by—in addition to supplying your e-mail address—specifying Send e-mail for failure and media requests per page 407 of the Retrospect Windows 16 User's Guide.  That would, by showing any problem with "Lenovo730" backups, IMHO eliminate the need for the script hooks that Nigel Smith suggested.

P.S.: Nigel Smith made an error below because he didn't pay  attention to the second through fourth sentences of my third paragraph; a Windows Client has no equivalent to a retroclient.state file.  I've deduced this from a KB article and an R.T.S. post, but you can check that deduction with R.T. S..

 

Edited by DavidHertzberg
"Assuming 'client' machine 'Lenovo730''s C:\ drive is OK" prefix to second sentence of first paragraph. P.S.: Nigel Smith made an error below because he didn't pay attention; a Windows Client has _no_ retroclient.state file, so x509 must delete+reinstall.
Link to comment
Share on other sites

15 hours ago, x509 said:

Since the client in question is a windows machine I can't run "sudo."

However, I have never given any attention to scripts.  Right now, I look at the History tab, and if I see error messages, that's an indication of a problem or issue.  I like the scripts idea, though.

Obviously not. I doubt you've got a "Library" directory either...

But you should be able to work out what to do from that one-liner -- with Administrator privileges (sudo) delete (rm -f) the retroclient.state file from the machine's (rather than user's) preferences folder. You know Windows better than me, it won't be too hard to find out where that file is and what it is called.

Ways to go after that include:

  • Write a Windows script that looks to see if Retroclient.exe is running -- if not delete the state file and start the client.
  • Make it your wife's problem 🙂 Set the client's "Notify if no backup after" to 1 or 2 days, tell her she should restart (or manually run a batch file that does the above process) whenever the notification appears
  • Rather than "History", set RS to send you a daily backup report -- you're probably in your email client pretty regularly! You might be able to just "Send e-mail for failure and media requests" -- I think "failure" includes client not present for a scheduled script, but you should check. If you are using Proactive, no luck
  • Similarly, Script Hooks will work easily with scheduled scripts, but you'll have to be more creative with Proactive because you'll be looking for an event not happening
  • Regularly run a network scan from your machine -- if your wife's is present but port 497 isn't open, do something (send her an email/SMS, use a hardware board that sets off a klaxon, sigh loudly and give her meaningful look...)

Edit to add...

I always forget about these, but there are client-side script hooks too. The client only responds to two events -- StartSource and EndSource -- but you could use those to eg send you an email every time a backup happens. You'd then know there was a problem because you didn't get an email after a certain time period. Client-side script hooks would work brilliantly with Proactive backups.

With Script Hooks, your imagination's the limit. Emails are one way but you could also POST data to a local or remote web server, to store in a database or simply re-write an HTML file to display the last backup time on a web page. Update a single-pane management interface like Nagios, send yourself a Slack message, etc, etc. Up to you, your preferred methods, and how your current RS setup runs things.

...end edit

These are just band-aids -- you should really find out why this is happening. David may be right and it's PEBCAK, or your wife may be having to force a reboot (outside of an active backup) because of other problems, RS Client might be crashing for some reason... Sort out the underlying problem and much of the above becomes unnecessary.

Link to comment
Share on other sites

10 hours ago, DavidHertzberg said:

P.S.: Nigel Smith made an error below because he didn't pay  attention to the second through fourth sentences of my third paragraph; a Windows Client has no equivalent to a retroclient.state file.  I've deduced this from a KB article and an R.T.S. post, but you can check that deduction with R.T. S..

Not so sure. Windows uninstall may be deleting it for them, and is generally a good cure-all, so they just may not mention it.

I say this because there is a C:\ProgramData\Retrospect Client\retroclient file, which appears to get re-created on a reboot (or archived to a different name as part of the client properly exiting, since the last line on historical versions is "Retrospect Client Terminated"), and includes IP and client state data. It may just be the current client log file, or it may be that the client checks for it's presence at launch and doesn't start if it's there.

I'm looking at this on a remote VM and killing RS client might cause problems (and/or I might fat-finger and kill the wrong thing!), so I daren't dig further.

Link to comment
Share on other sites

Replying to several recent posts, I run backups late evening, after we are both finished "working" (if that's the word when people are retired ...) so my wife isn't doing anything funky.  In any case, I'm the "IT guy" in this marriage.  Not that I could get a real job doing IT admin, but I have sufficient skills to (mostly) keep the home LAN and its systems in good order.

However, I believe that the Lenovo bloatware on her system, client "L" may be the problem.  I keep deleting it or stopping those services, and like a weed, they keep coming back.  On client "D", which is also a Lenovo machine, it started life out with Windows 7 and then got upgraded to Windows 10.  But that was a clean install, using a retail copy of Windows, not a Lenovo OEM install.  I probably should have done the same with my wife's system when it was new, but too much time has passed now.

Agree about needing to figure out the underlying problem.  That said, it's frustrating that I simply can't restart the Retrospect client, that I need to do a reboot.

 

 

Link to comment
Share on other sites

OK so, life in my hands (and knowing a workmate had just arrived at the office, so could press buttons if needed), I connected to the remote VM and logged into Windows. RS Client was running, and I could turn it off and on again.

Ctrl-Alt-Del, Task Manager, found "retroclient.exe", "end process".

Launched Retrospect Client, which showed Status as "Off", and the "Protected by..." checkbox greyed out. Spinning wheel every time I tried to interact with it. File C:\ProgramData\Retrospect Client\retroclient still present from before. After 5 minutes of "Program not responding", clicked the "Close program" option.

Launched Client again, this time "Run as admin", same results. Ended process. Messed around with the retroclient file, still not launching.

In Task Manager's "Services" tab, found "Retrospect Client", right-clicked, "Restart service". (Interestingly, that rotated the retroclient[.logn] files and created a new retroclient file.)

Launched Client, everything A-OK!

So I think that's your alternative to a reboot -- Task Manager->Services and "Restart" the "Retrospect Client". You don't even have to kill the Retrospect processes (Sys Tray, Inst Scan).

Would love to hear how you get on next time your wife's machine has this problem...

 

 

 

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

Great experiment, Nigel Smith😀   It sounds as if x509 can make things easier on himself if he just checks the Client on "Lenovo730" before its nightly backup starts (he could already be backing up "client D"), and does a "Close program" followed by a "restart service" for the "Lenovo730" Client if its Status is "Off".  Maybe that can later be done in one Windows "command line" script—or optionally two; see the next paragraph.

MrPete, mbennett, rfajman, and Nigel Smith,

Be aware I don't know anything about Windows "command line" scripting, but it occurred to me that the entire process in this post's lead paragraph could be automated for the case where the Client's Status is still On—which it isn't in x509's case.  The approach would be the same as in the last substantive paragraph of this up-thread post, except that the Client would launch a Windows "command line" script to do the work instead of doing the work itself.  That would shift the multi-threading upwards to Windows, which would eliminate the engineering difficulty of multi-threading the Client that I mentioned in the second paragraph of this further up-thread post.  Either the "command line" script would retrieve the Client's "ipsave address" itself or the Client would pass the "ipsave address" to the script as a parameter; either way the script would simply "ping" the address, and do the "Close program" followed by a "restart service" for the  Client if the "ping" was unsuccessful (based on the "if I can't see you, then you probably can't see me" principle we all learned as children playing hide-and-seek.).  A optional extra—for x509's situation—"command line" script without the "ping" would be run after "client" machine boot to start the Client.

MrPete, because of his evident prowess in Windows shown in this even-further-upthread post, should probably investigate the feasibility of writing such a script.  If it's feasible, he should include it as an Additional Note in his Support Case #8512.  Given that Retrospect Windows 17.5.0.237 didn't fix the -530 bug, I suspect the Retrospect engineers would now be open to a simpler approach.  Maybe I should investigate the feasibility of writing the equivalent of such a script for macOS, although I have no experience with macOS "command line scripting.

x509, 

IMHO you need to further investigate eliminating the "Lenovo bloatware" on your wife's "Lenovo730" machine.    I did a search of the Forums, but nobody else has reported the same problem.  However you're totally correct  about that "bloatware"; through early 2015 it included bundling Superfish software identified as malware, and in August 2018—which post-dates the release of the Yoga 730—Lenovo "was criticized for automatically downloading Lenovo Service Engine software – labeled as unwanted bloatware by many. Worse, when users removed the software Lenovo systems were configured to download and reinstall the program without the PC owner’s consent [my emphasis]".  Before investigating that, you need to figure out precisely when the "bloatware" shuts down the Client around the time of "client" boot—so that the optional "ping"-less script can be run afterward as part of the machine boot process rather than by the Client.

Edited by DavidHertzberg
Add sentences to 1st–3rd paragraphs: optional "client"-_boot_ script, & maybe I should investigate equivalent macOS script. Add final paragraph saying x509 needs to further investigate concerning the "Lenovo bloatware" on his wife's "Lenovo730" machine.
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...
×
×
  • Create New...