Jump to content


  • Posts

  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

JamesOakley's Achievements


Newbie (1/14)



  1. Helpful - thanks! I'm on static IPs, and I've just discovered that I can edit that IP in the clients list in the main Retrospect Desktop application. The annoying thing is, randomly (not every time) after rebooting the WiFi network or the client computer, the IP address gets reset to the one on the virtual interface, and I then have to reset it again in the main application. I still think this is not how it's supposed to work!
  2. This is not a post about running Retrospect (or clients) within a virtual machine. I have a Retrospect Client running on a Windows 10 machine on which I needed to run the Android emulator that comes with Visual Studio. In order to do that, you have to turn on virtualisation / virtualization / hyper-v options within Windows. As soon as I did that, my Retrospect Professional installation could no longer see the client (Client Not Found). I tried reinstalling the client software, but that didn't help. When I looked at the client properties in Professional, I had a hunch as to why - the IP address of the client was not the one I was expecting. It was outside the subnet I use for my local area network; I forget what IP it was, but it was still in one of the ranges reserved by IANA for local networks. Conclusion: Enabling Hyper-V must, behind the scenes, create a new network with a different subnet mask to set up a NAT system that lets any virtual machines communicate with each other and the wider network. So each virtual machine, and the host physical machine, share the same "public" IP (the IP on my actual network), and have their own internal IP that is only for VMs to communicate with each other. Somehow, the Retrospect Client had picked up that internal IP, and was broadcasting it to Retrospect Professional, so that my Professional installation was trying to use that IP address to locate the client. Not surprisingly, it failed - any traffic that doesn't originate somewhere on that client machine needs to use the single address the client has on my main network. The solution was actually not too painful - remove the client from Professional, and re-add it, giving the IP address manually. Re-create the subvolumes etc., and everything worked. Until, randomly, last night the client settings switched back to using a local loop IP again. So I had to remove and re-add the client. Again. This is solvable, and not happening too often, but is clearly a bug in the way Retrospect Client thinks it's found the IP address that should be used to contact it. Using
  3. I am doing this, and it is working. But, if the two scripts require a lock on the same source volume or backup destination, the system will respect that and wait for the lock to exit. But where the scripts are truly independent, one doesn't hold the other up.
  4. I've been a Retrospect user for many versions now. When I upgraded from 12.x to 15.x, the Executing tab of Activity Monitor jumped from 1 to 16 units. So it seems that it's a feature as of version 15. At the time, I looked in the release notes, and the only reference I could find was this: So I think (hope) you were asking support to fix a bug that, this time, is actually a feature. I have to laugh. If you read up a few posts, that's exactly what support tried getting me to do. I wasn't convinced at the time, and like you quickly reverted. But seriously: Is this their solution to every support request and bug report? It causes a lot of disruption (you lose your backup session history, but also all the sub-volume and volume group definitions), and shouldn't be something to ask someone to do unless there's reason to believe it will help.
  5. Nope. I'd clocked what it was for, which was pretty much as you put it. Except for Sally. I could see a use-case for it for us, actually, with a second office site that could then be backed up as a client to my backup storage. But I'm not sure it's an optimal solution even for that, so I've not done anything with it. I took #7748 to be about a "remote" backup client only in the sense of "not the same computer as the one running the Master copy of Retrospect". In other words, I hadn't noticed the word "remote" as significant. It's funny though, because apart from "remote" that's exactly the issue we're discussing here. I did ask in my support ticket whether my problem relates to that fix. I wonder what they'll say
  6. Or even: "Remote Backup: Fixed issue where Retrospect would not time out when searching for a remote backup client (#7748)" Support had me deleting configxx.dat files, so that they were regenerated from the equivalent .xml files. That meant losing all volume information in my installation, which would have meant setting up volume groups from scratch, and then adding source volumes back into each scheduled script before it would run, hoping I remembered correctly how all that was configured. I didn't last long before I put the backup copies of configxx.dat back, and waited for a proper fix, suspecting that a corrupt config file was probably not my problem. Edit: They also got me to uninstall InstantScan from the clients. I can probably re-enable that now.
  7. That's more help than I got. I'll wait for the 15.6.x release and upgrade hopefully. Thanks for the good news.
  8. Before spending time on a Support Request, (from experience) does doing so actually get their attention?
  9. This is a pretty serious regression since the 12.x versions. Certain errors (specifically including a client being unreachable) no longer fail elegantly with an emailed report, but cause the whole engine to hang so that nothing is backed up. Further more, the hang is serious enough that it can't be restarted from the dashboard - it requires the task manager with elevated permissions.
  10. But if it's running in the background, with no UI visible, it shouldn't pop a dialog that you have to click "OK" to before anything continues. I'm now on 15.6, and it just did it again - no backups ran for 3 days until I noticed that they hadn't. Killed retrospect.exe, and started the program again, and the waiting executions all began to run. The thing is, under 15.x for Windows, even Desktop edition gets multiple execution units, so one stuck job shouldn't freeze the whole setup.
  11. Go on, I'm intrigued: when you click "View the message", what is it?
  12. Yes, and in fact it can't be an invisible dialog in my case, because the front-end doesn't stop responding, just the engine. So I cannot "stop" the running job - it just sits there trying to connect to the client. I also cannot close the Retrospect main window, and I cannot relaunch it from the dashboard - if I try, nothing happens. But I can browse around the application, read logs, look at selectors, clients, volumes, etc. - none of which would be possible if the program were paused waiting for me to click "OK" somewhere.
  13. The dialog issue may be behind this. It's hard to find out, by definition. If that were the case, fixing the z-order wouldn't solve the problem, since Retrospect usually runs without the UI open. If Retrospect is running in the background, the only way to get the UI up to interact with it is to restart it, which cancels any running jobs.
  14. I've noted this with 15.5.x (Professional) on Windows 10. The trigger here seems to be if a client is not available for whatever reason. Retrospect hangs looking for that unreachable client. The trouble is, it doesn't timeout like it used to on earlier versions, and move onto the next task. It hangs totally. If you try to close Retrospect, or relaunch from the Dashboard, it never does. The only way to get things back is to kill retrospect.exe in the task manager. I always notice emails telling me that a backup run had a problem. It takes me longer to notice I haven't had any emails from Retrospect for a while, so I need to find out what's wrong.
  • Create New...