Retrospect Clients randomly getting stale on Windows 10 machines

[hevanw]

I am running Retrospect 18.5 on a 24x7 home server running Windows 10 Pro. This does backups of itself + 6 home desktop and laptop Windows machines, which are all running the Retrospect Client.

On a very regular basis, I see that clients stop backing up through ProActive scripts. Even after a reboot of such client machine, Retrospect will not start backing up. The only way to wake up Retrospect again is to go into Windows Services and restart the Retrospect Client service on that client machine. This fixes it every time, but then days or weeks later, the problem will reoccur on that client. With 6 client machines, this means that every week there is at least one client that has stopped backing up in this manner.

Some observations I've made so far:

* I suspect the issue must be at server side, since I have the problem with every single client machine I use here, which is a mix of destkop and laptops, W10 and W11, home machines and school machines...

* However it is then kinda weird that the explicitly restarting the Retrospect Client service fixes this. It's even weirder that rebooting the machine does NOT fix it (doesn't a reboot also stop and start the service ?!).

* I noticed that when the issue triggers, all retroclient.log files on the client are thrown away. There is no trace of successful runs, and the log rotation starts from scratch again. So when I'm quick to notice the issue, I will see that there are less than 10 rotated files (i.e. they don't go all the way up to retroclient.log.9.log). 

* I've actually had this issue for many years, also on the previous version I ran (Retrospect 12) when my server was still runing W8 Pro. But now that I've done another paid upgrade, I want to see if I can get this fixed once and for all.

* I do have a support case ongoing currently, but so far nothing coming out of it, other than questions for info and logs and info and logs.

[Lennart_T]

I don't think it is on the server side, since it starts working every time you restart the service on the client.

Speaking of clients:

How often are they restarted?

What happens during the night? Turned off or just hibernation?

[hevanw]

Hi Lennart,

it's a mix. Sometimes they go in sleep overnight due to inactivity, other times they are turned off entirely. It does however make me wonder whether that makes the difference. I think I see the problem a lot more with my own desktop PC which also happens to go into sleep much more often than other clients. It's worth doing some tests with this. Thanks for the lead.

[mbennett]

The only reliable way I've been able to get the clients to consistently work with Proactive is to use the DNS name.  You can try the Multicast, Subnet Broadcast or IP address, but either they won't test successfully or they'll keel over at some point.  So use the Direct method and type in the PC client's name and see if that's reliable.

 

[hevanw]

Thanks, mbennett, will give that a try.

The weird thing remains though that a restart of the 'Retrospect Client' service at the client side, fixes the problem. You would think that a reboot then has the same effect, but rebooting does not fix it.

Support has explained that a client not being seen must mean that port 497 is not reachable. I tested this and that is indeed what is happening. When a client stops being backed up, I could not telnet to port 497 from the server to that particular client. After I restarted the Retrospect Client service, I was able to telnet to port 497.

So everything still points at the client becoming in some bogus state where it is no longer listening to port 497. The weird thing is that it seems to be just me with this problem, while I have a mix of clients : desktops (Ethernet) and laptops (wifi), W10 and W11... But I even had this problem back in Retrospect 12 with Windows 8 clients.

[hevanw]

The hostname idea was not working.

However, what I noticed when Retrospect is not backing up is the following :

* On the client machine, I can telnet to 127.0.0.1 port 497.

* On the client machine, I cannot telnet to 192.168.x.y port 497 with 192.168.x.y being the client's (static) IP.

 

I then rebooted to confirm the issue (since rebooting normally does not help) and to my surprise, this time I can telnet to 192.168.x.y. Moreover, I see the Retrospect Server now starting a proactive backup of the machine.

I also looked with Windows resmon.exe to see what is listening where, and I could see retroclient.exe listening on address 192.168.x.y port 497 (both UDP en TCP) even when it was not working. Resmon also shows that all traffic is allowed so the firewall is not blocking anything either. Comparing Resmon before and after the reboot also does not show any differences. So I'm stumped at why I could not connect to 192.168.x.y:497 before the reboot.

 

EDIT: 2 weeks later and I could reproduce the above. It seems like telnetting to 127.0.0.1 port 497, and then rebooting, also does fix the issue. This time I also first tried rebooting, before I did that telnet, and that did not fix it. So the telnet to 127.0.0.1 seems to unblock something in the Retrospect client.

[x509]

Hi.

I hope I'm not hijacking this thread.  My normal Retrospect configuration is my desktop system plus 2 clients.  At this moment, there is only one client, but the issue is the same.  All systems are running Win 10 Pro 64, and are up to date with MS patches and annual major upgrades.

The issue is that my client often reports a 505 - Client reserved error message, even a day or more after the last backup.  @Lennart_T provides an explanation in the second message from this 2012 thread. 
 

So why is the Retrospect client still "busy" after 24 hours?  Does the Retrospect server not signal the client that the backup script is done?  No timeout? And why has this issue not been fixed by now?

I've been set up an AI script for the client, in addition to the regular backup script, but the AI script doesn't seem to solve this issue.  Rebooting that client isn't a practical option.

It's frustrating enough that I'm thinking I should upgrade from V17 to V19, just to take advantage of the free tech support window, which is crazy.

That all said, Retrospect has saved my butt enough times that I can't imagine going to any other backup solution.

Happy New Year to everyone.

 

 

[hevanw]

As for my problem. I think it is related to Sleep Mode when the PC has been inactive. I had turned this off in Windows and then did not see that issue any more. Now that it's on again, I again see sometimes Retrospect stopped backing up.

Also contrary to what I stated previously : the issue actually gets resolved when I do a reboot of Windows. Note that the issue does not get resolved if I do a shutdown and then boot up the PC again. No idea why there is a difference between a reboot and a shutdown/power-up, as I would have thought these are essentially identical as far as Windows behavior is concerned.

[hevanw]

Sorry for the bump of this old thread. I recently found the cause and workaround and just wanted to share it just in case anyone else is wondering or googling this.

A couple months ago, I accidentally learned that a Windows shutdown and restart is actually not the same as doing a reboot. This is due to a feature called 'Fast Startup' which performs a sort of hybernate when doing a shutdown, which then speeds up a subsequent startup. This is a recommended setting (per Microsoft) and is also on by default. However, that difference with a reboot immediately made me think of the Retrospect issue I had and which is described in this thread. So I actually turned off Fast Startup on all my Windows PCs (both 10 and 11). In fact, many articles do recommend turning this off so your system has a proper shutdown and boot up.

Well, you probably already guessed it: since I turned off Fast Startup on all machines, I have not run into this Retrospect issue a single time. All my pro-active backups are now running reliably and whenever they should. I'm surprised that Retrospect Support themselves were not aware of this issue, and that it took me several years to find out. But better late than never, I guess.

[MrPete]

It would not surprise me if this issue were related to the (AFAIK still unresolved) challenging problem I discovered several years ago.

I will describe it by explaining how to test for it: download and install NirSoft's TCPview app.

• Open the app and sort on Local Port
• You should see retroclient.exe listening on port 497 -- that is normal
• At least one line will listen on 127.0.0.1 (localhost) which is fine. That's internal to the app
• You should ALSO see retroclient listening on your real IP address. E.g. 192.168.x.x or whatever. -- if so, that too is fine.
• The problem: under various circumstances, anything from a stale WiFi link to one or more Windows virtual network devices can produce an IP address that goes nowhere. Usually this is an APIPA address (169.254.*.*)... and retroclient can listen on that instead of the real IP address.
• So far I've not seen it necessary to reboot, just restart retroclient with a pause. I have a batch file that does:

net stop "retrospect client"
sleep 3
net start "retrospect client"