Jump to content

All Activity

This stream auto-updates

  1. Earlier
  2. 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 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 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 seems to unblock something in the Retrospect client.
  3. 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.
  4. 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.
  5. 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.
  6. 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?
  7. 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.
  8. Thanks very much for that info, rdestes2002. Good to know if I accidentally delete several scripts. Fortunately I only deleted one, so I was able to recreate the script with the same source and media set. Seems to have worked.
  9. I accidentally deleted 21 very detailed scripts. Retrospect Support saved my bacon by giving me the following advice: Locate and recover a backup copy of the file configs.xml that predates the date & time you deleted the script(s). On Mac, this file normally is in MacHD/Library/Application Support/Retrospect. Go to this link: https://www.retrospect.com/en/support/kb/server_configuration_management On that page, go to this link: Retrospect for Mac - How to Import Engine Configuration and follow the instructions for Importing. When you click on File/Import in Retrospect, you'll see the Retrospect Import Window. In that window, deselect all but the Scripts option. When you click OK in the Retrospect Import Window, a Finder window will open allowing you to select the recovered configs.xml file. After that, you should see all your missing scripts repopulate the Scripts window in Retrospect.
  10. Thanks, Lennart_T. Creating a new script with the same source and media set seems to have worked. That saved me a lot of time!
  11. If you create a new script with the same sources and the same media set(s), Retrospect will see which files that are backed up and which ones that are not. In other words: It will pick up where the old script left off.
  12. macOS 12.5.1 Monterey on iMac Retrospect 18.5.3 Backing up to external 8TB hard drive (5 partitions) I have used Retrospect for years but this is the first time I've accidentally erased a script. I know I could recreate the script, but wouldn't just that start a brand new backup? Is there any way to make a new script that will pick up where the old one left off? Thanks for any suggestions.
  13. As (hopefully) a final entry in this thread, a couple things: Nigel mentioned making a new script and a "Preview" option. Yes, I found that this does exist when making a new script, but not on an existing script. I chose not to make a new script on the cloud backup because the script and backup set definitions are complex. In any case, it worked somewhat properly, but not totally. Where Retrospect weekly backs up 2-3GB to the cloud, the backup I finally did yesterday backed up 50-something GB out of total backup selection size of ~180 GB. I don't know why it didn't backup either the whole 180GB or, as normal, 2-3GB, but I will settle for that. As for the local backup, after redefining the backup source disk as the real system disk (C:), it did indeed backup only changed data as it usually does. I also found that the local backup from the wrong disk (the old C drive, now the E:) can be "forgotten" and Retrospect will groom it out of the backup set. That is a nice feature and a good way to recover from an "oops"! ...Or, I believe it is a nice feature. Retrospect is as I write grooming an "oops" from last night, the first incremental to my USB drive after swapping the offsite and onsite disks, which I do every few weeks. Again, I forgot to redefine the backup source when I brought the second drive in. But grooming the bad backup from last night is taking a while so I don't know how successful it's going to be.
  14. It's probably me -- I'm a Mac rather than Windows user. But pp12 of the Windows RS v17 manual shows a "Preview" button, so I think the functionality is there if you dig around a bit.
  15. Nigel, the only "Advanced mode" I find is in the Backup Wizard; I use that mode, and the only option there is a check mark icon at the top of the screen that has Retrospect inform me about whether the script appears valid or not. While there, I can also check media. This gives me no indication as to which or how many files will be selected. Am I missing something? Note that I simply redefined the source volume as "C:", checked my selectors, and ran it manually. It did indeed work as we thought it should, doing an incremental backup in the same manner that it did in the old drive. So yes, it works as it should once the source volume is redefined.
  16. Make a new script in Advanced mode with the same options, source(s), destination, and selectors as the script you are worried about and then "Preview" to see what's going to happen.
  17. Unless I get a more definitive answer I will have to try a manual version of the nightly backup. This backup, to a local USB drive, doesn't matter so much space-wise, as the 4TB backup disk has enough open space to hold the 500GB or so that a full backup will take. But Retrospect does an incremental backup of only my data to cloud storage, approximately 180GB, every Thursday night. That incremental backup normally consists weekly of 3-4GB, but if it backs up all the data would take many hours and exceed my allocated bandwidth. So I must be sure! Any additional thoughts?
  18. Thanks Lennart. I got it working by uninstalling Retrospect, downloading the archive copy again, and reinstalling. I suspect that the cause of the problem was that I had not downloaded the correct version; perhaps I had downloaded a non-USA version. In any case it is working now.
  19. Just make sure the license code is for version 17.5 and not for (for instance) 16. The account ID should not matter. Copy and paste from the email with the license code is always better than typing.
  20. I'm pretty sure that Retrospect will not perform a full backup just because the files are on another drive. That is because it's the same computer with the same Windows version.
  21. I changed the laptop account to the same as the desktop. This did not help. Someone, please. I've got to get the laptop back in operation. I have a recent Retrospect backup that I can't get to.
  22. I had to reimage the C drive on my Windows 10 laptop yesterday and after doing so installed the version of Retrospect Desktop I am using. The first step after installing the zip file is to enter the license code in the "Getting Started with Retrospect" window, which I did, many times--upper case, lower case, dashes, no dashes. It always returns the message "Sorry, that code failed. (needs code for Retrospect Desktop or similar application)". I even checked for an upgrade to 18 on the Retrospect website from the desktop by entering this license code, and it is valid. Could this rejection be caused by my use of a different account ID on the laptop versus the desktop (.outlook on the laptop, .gmail on the desktop)? If so, how do I make it work? I need to restore the system to this laptop quickly and move on.
  23. Retrospect, Windows 10 desktop. I replaced my out-of-space C SSD drive yesterday with a new one and used Samsung's cloning software to duplicate the old drive to the new. That appeared to work flawlessly, but when Retrospect did its nightly incremental backup, it went to the E drive where the old SSD now resides instead of the new C and, thankfully, backed up nothing. I can redefine the backup script to go to the new C drive, but I'm concerned that it will do a full backup first time through, and I would rather that didn't happen--I would like to continue doing incremental BUs, since the new drive appears to be identical to the old except for drive ID, or whatever it is that causes Retrospect to follow the physical drive regardless of the drive letter it currently has. What will happen when I redefine the source drive on the script? And if it will by default do a full backup, any way I can change that? Or must I settle for a full BU?
  24. Robin, There were no error logs recorded and visible in the console on that date. There was however a diagnostic error report on that date at midnight of 5JUN2022. Looks to me like it was a low disk space warning on the startup drive. I have since freed up space on that drive. How could this result in a disastrous failure of another entirely different operation using another attached drive and a running application? Why was an error in the Retrospect operation not logged? Guess we'll never know, the answer to these questions, either way. But please don't shoot the messenger. Thanks, I though you might want to know. Diagnostic Log_disk writes 20220606.rtf
  1. Load more activity
  • Create New...