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.

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.

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.

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.

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.

Great, got it working with 4 parallel executions. Interestingly enough, the Desktop license does allow me to create Sets as Storage Groups, even though the feature matrix says it's only available in the Server licenses. EDIT: apparently I accidentally had posted this in the wrong subforum.

Ah that is great news, thanks. I have separate backup sets for all my clients, so this would then mean that I can have parallel backups of each, which is exactly what I had hoped for. Yes, I had seen that all subsequent updates were primarily about supporting the latest Windows versions and seasonal releases. I never ran into issues backing up, but like you state, the main question is also about restoring. I admit that I have not tried to restore anything yet with Windows 11 so maybe I was running a risk there that I wasn't even realizing. Which reminds me to soon do a couple test restores again. Anyway, guess I will be upgrading to 18.

I'm currently still on Retrospect 12 Desktop. Considered upgrading to 18, but at first sight there is nothing really compelling to upgrade for. The one thing that confuses me though, is with respect to parallel backups. The Feature Comparison matrix at https://www.retrospect.com/en/products/compare says that Desktop has 4 concurrent operations. I read this like there can be 4 concurrent executions (e.g. backups) in the engine. However, I then ran across an explanation of Storage Groups (which is only available in the more expensive Server versions) and that one says : "Protect an entire backup environment up to 16x faster with a single, centralized destination that Retrospect can use simultaneously. With Storage Groups, customers can run parallel backups to the same disk or cloud destination, reducing the backup window." which clearly seems to suggest that without Storage Group you can only backup 1 client at a time ?! Can anyone clarify ?

After I installed VirtualBox on my home server, Retrospect is considering the new virtual network interface of VirtualBox as the default interface. The result was that none of my clients were detected anymore and no backups were running. I now worked around it by adding a new interface with the original subnet of my hardware interface and reconfiguring the clients on my Retrospect server. I also tried manually setting the interface metrics in Windows 10 to prioritize the hardware interface, but to no avail. Even after a reboot, Retrospect is considering the virtual interface as the default one. Is there a different way to force Retrospect back to the original default interface ?

I now have a 2nd machine that got the upgrade, and which I wanted to give a try. This one has no issues at all with Retrospect 12 and has backed up nicely at full speed. So the issues with my 1st laptop are likely not to be related to Retrospect. EDIT: issue with the 1st laptop is now also resolved. It looks like you may have to log in in Windows 10 b2004 with every locally defined user first. For every local user that logs in for the first time again after the update, Windows still is doing quite a bit of activity, which may be required to have Retrospect be able to access some files.

I would definitely advise against upgrading if you still want to backup with Retrospect. I have 5 machines, and my oldest, least important, machine now has 2004. I seem to have 2 big problems: * The backup will run extremely slow at times : less than 3MB/minute. Not clear whether it's related to what files are being backed up or some general networking issues. At times it will speed up to the regular >200MB/minute. * The backup will abort/fail before completion with : " Scanning incomplete, error -1001 (unknown Windows OS error) " I must admit though that I am still on version 12, because I don't want to pay for an upgrade every year.

There were a lot more files that were exhibiting this issue than I thought. Some were also dll's in subfolders of Program Files, etc... As this didn't look like a healthy situation at all (still surprised my wife didn't run into any issues with the laptop) I ended up reinstalling Windows from scratch. And that obviously also solved the Retrospect problem.

Looks like a OS problem indeed. I looked at some of the files that Retrospect is reporting the error on. Apparently I cannot access/copy those files with a weird error : "0x80070157 - External backing provider is not recognized." Already googled some but can't really find a good solution. It looks though that these are files that I may not need, so I have moved the relevant folders into a TEMP folder so it gets excluded from the backup and will see from there.

Seems highly unlikely because the client machine otherwise acts perfectly fine, so there is definitely not an issue with corrupt filesystem or something along those lines. My further investigations now go toward The Volume Shadow Copy. Each time Retrospect runs, I see a couple of VSS Access Denied errors in the Event Viewer of the client. However, these errors seem to have been there already before I made the SSD swap.

After I upgraded the SSD in my wife's laptop, I am getting thousands of errors on each backup run for that laptop. I even did a reinstall of the Retrospect client and a Recycle backup, but the problem remains. Ths SSD upgrade was done by cloning the old SSD to a new one using Clonezilla. The errors are as follows, and this for many thousands of files. Client runs Windows 10 Home. Server runs Windows 10 Pro. Retrospect is 12.6.1.101. File "C:\ProgramData\O949\langpack-sr@firefox.mozilla.org\chrome\sr\locale\sr\global\finddialog.properties": can't read, error -1001 (unknown Windows OS error) [*] T-35: --ERR-- (10856) TPipelineMgr::tryStartPipeline: m_outQ->error=-1001 m_whyEnd=-1001 [*] T-35: --ERR-- (10856) TPipelineMgr::tryStartPipeline: error=-1001 [*] T-35: MapError: unknown Windows error 343 [*] T-35: can't read data, BackupRead failed, \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy113\ProgramData\O949\langpack-sr@firefox.mozilla.org\chrome\sr\locale\sr\global\global-strres.properties, osErr 343, error -1001 [*] T-35: --ERR-- (2372) ReadStation tryReadFile: BRRead err=-1001 [*] T-35: --ERR-- (20336) Terminal: workUntilEnd:-1001 seq=0 [*] T-35: --ERR-- (20740) ChecksumStation: workUntilEnd:-1001 seq=0 [*] T-35: --ERR-- (2372) ReadStation: workUntilEnd:-1001 seq=1 [*] T-35: --ERR-- (10856) BackupReadCloseAsync: err=-1001 I already googled a bit and looked at the forum here, but could not find a solution. In the client's Windows Event Viewer I also don't seen anything that should pertain to this. Hope someone has some suggestions because I'm out of options.