Jump to content

Retrospect Clients randomly getting stale on Windows 10 machines


hevanw
 Share

Recommended Posts

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

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