Jump to content


  • Content count

  • Joined

  • Last visited

  • Days Won


Everything posted by henry-in-florida

  1. Found that when I changed the name of the source drive, even if the sources are refreshed to recognize those new source names, subsequent backups seem to revert the sources to what they were and then the backups fail because that device no longer exists. My workaround was to refresh the source list and then immediately run a script using those devices. Somehow that seems to work... For now. Here's the step by step in case you want to reproduce: Change the source name ( in my case I'd reformatted the source drive in APFS and renamed it) of a device in the Retrospect Multi-Server backup plan. Go to Retrospect and refresh the source computer to register the names of the drives. Wait 24 hours. Run the backup script with the sources. The source names revert over time (and running other automated backups) to the old names ALL BY ITSELF, those new source names previously existing in the dropdown list disappear, the old names replace them and any backup scripts using the old drive source names obviously will continue to fail, lacking manual intervention. After the workaround above- reset the source list by refreshing sources (Sources>select the source machine>Refresh) and immediately perform a backup. N.B., two anomalies reading through the log. The log shows "First Access" for the device "GenieMBP", even though previous backups of the device WERE COMPLETED previously that same day. Guess it means first access of those SOURCE DRIVES? The script also changed the source drive to something that existed ALL BY ITSELF during previous backups (Macintosh HD) prior to failing on the missing drives. Retrospect log_190219.rtf
  2. This is a bug of some long standing related to locating a client. I have found it regularly when needed to add or re-add it to the sources. Here's an example: I have TWO clients. Both work fine and can be located by IP with no trouble. Also, both exist on my network and Bonjour can locate them in MacOS. However multicast cannot find one of the two. The attached shows the story. Since updating to 15.6.x, I now have to add at least the missing client via it's IP rather than with multicast. I tried to turn the client software on and off, restart the machine and combinations reversing these two steps without success. Does anyone have an idea what causes multicast to behave so badly with network attached clients in Retro? Have also had the other client go missing from multicast and the opposite client show up instead in previous iterations of the process. I conclude that multicast is very unreliable. YMMV.
  3. David, Let's digress... I'm assuming the client and Server now work to at least see the internet. So, did you use Subnet client selection to register your client, did it find the client? Did you (delete the old client and) re-add it to your script(s)? Did this fix the -530 error you said you get or not on an actual backup script? If not... Did you then see and try the troubleshooting steps here? What were the results of that? Henry
  4. Hi David, I stand corrected as he-whom-you will not name is in Support. I go back a long way, too. So I recognize the history lesson. However that is very old news. One that I prefer to leave in the scrum gone by. As to YOUR issue with -530 errors, switches should not cause it, since by definition, a switch doesn't assign IP ports, rather simply allows data to pass along to multiple connections paths at the proper speed between the router (which IS the only type of device to deal with the IP assignment table) and the client device(s). If, OTOH, you have multiple routers (most routers have an included switch) cascaded throughout your network, then it's a different kettle of fish. In case you have "Switches" that are really routers and wish to deactivate the router part, try bridging mode on those routers to avoid a router behind a router situation. Or you can try to use subnets there AND in Retro as you are apparently doing with the proper subnet assignments for your reconfigured system. I'd avoid the use of multiple routers for LANS, personally, as much as practical anyway. After all, do you really have 250+ devices to manage at home? I use bridging mode for devices like WAP(s), which typically have routers inside them. My network of WAPs improve wireless coverage at home, several WAP's "meshed" to appear as one. I also frequency coordinate my use of spectrum for both bandwidth and cross channel RFI (radio frequency interference) coordination in WAP RF assignment. That has worked for me prior to the advent of recently introduced meshing WAP "systems" that recently came on the market. They don't do that to the same extent as Apple did. They are now out of this market, sadly. Again, Apple was way ahead of their time on this since the Airport Express and Extreme WAP products do (and were the first to) coordinate between themselves when set up correctly on a single SSID. Some of these new type meshing devices claim very high network connection speed due to multi-channel wireless connectivity (may be false claims, since I did not notice such terrific, read claimed results when I helped set up a friend's system using one). So I'd recommend you perform some thorough testing for WAPs before using them for Retrospect. For backup speed, I still use wired LAN connections between Server and clients, not wireless.
  5. Hi David, I should've credited Robin Mayoff, Director of Support and longtime Retro boss. He explained troubleshooting Multicast, which is a network standard, not a Retro invention. The troubleshooting procedure(Multicast app) is nice but not easy to implement, since it involves setting up a path for the client AND the server machines outside of the Retrospect app to prove it works. It clearly didn't. I found the relevant app and tested it. Sure enough, the client's port is stuck for this access, I know not why. That doesn't address what the problem is, only that it's not Retro. And it wasn't. The fact that the Server works and it's port is open. That leaves the other port on the router since subnet works and it's blocking of port for the range needed by Multicast. I could've tried to force open those ports for the IP and confirm. That would be the fix for the router- port blocking or assignments. Rather, I simply went with Plan B, e.g., Subnet Broadcast. It was easier to implement, and Retrospect engine settings support it quite well. As you apparently found as well. One day, I'll get the complete port assignment for Multicast and open a hole for all three machines' ports. Ah, one day...
  6. I was able to ping (e.g., see) from all clients to Multicast port 497, and from the server as previously describer. However I did not ping to Multicast from anywhere. Still assuming a bidirectional pathway. That’s the implication - Multicast to a machine is blocked? Robin at Retrospect mentioned a Multicast check tool - Multicast Ping for use on two machines to send and receive from each other. See this web page from the developer Mr. Dunagan. When I used the app supplied (Multicast Ping) current version, I was unable to ping from one client to the server when the app was running simultaneously, obviously the very one having the issue in Retrospect. I believe I was successful open up that port (create a firewall "pinhole") on the router IP connection to the client to see if that makes a difference, it should have been opened on the machine when I installed the Retro Client. Perhaps it will open up now, when I retest the two-way ping between the Server and this particular Client. The other devices (client and server) communicate with no pinhole configuration on the router, so I have no idea what could have caused this issue. Either way, it's simply a matter of interest. Since Subnet protocol seems perfectly fine.
  7. Your ideas have merit, I made "friends" with my router already, David. A long time ago. However, the router is not so friendly as to allow me to remove select inactive IP's singly. I have several IPs that, while inactive now, become active when the WiFi in the device turns on and the devices go from active on wired connections to active on WiFi. So there is NBO REASON to remove inactive IPs en masse. Irrespective to activity there is no reason that this is an issue the Multicast shouldn't take care of (multiple inactive users)itself and there are many reasons I do not want to willy-nilly get rid of all active or inactive IP's. No thanks. No, that's not what I said as to the IP assignment of my machines. They're not on the same IP. If you saw that, then it's an error. Let's move on. I've already proven (at least to my own satisfaction, if not yours) that based on the article Retro published (shared with you earlier) that Multicast works at the network level. So I disagree that it's a router issue in the first place. The ping proves that the IP's re being discovered. What happens within Retro beyond that is a Retrospect problem. I have static IP for my clients and have done so in the past. I feel very comfortable with my router (using it and diagnosing the performance of it) and the system I've got now. Although it's not the fastest in overall throughput, it gets the job done. I'm not making more trouble for myself than it's worth restructuring everything over and over, for no potential gain when there're multiple ways to discover clients in Retro. Emailed with a Retro support rep (Kyle) who's got a few more ideas. He suggests making the Subnet broadcast source selections work instead of the Multicast. Tried setting it up. This works very well and both clients respond to it without a problem. Obviously Direct selection of sources is a backup and also works fine, so I've got two paths to source machines, the latter being the most cumbersome. Fine. So Subnet selection's what I'll use instead of Multicast. There's still no good explanation about why Multicast fails, but I'm willing (more than, actually) to let Multicast go it's merry way without me. As I said, I've had too many problems over the years with it to believe it's happenstance or router issues as you indicate. Actually don't care to go further unless Retro support wants to carry on. I'm of the opinion that Retro's implementation of Multicast is the issue. Now, that I present the problem to Retrospect, simply not going to pursue it further.
  8. Hi David, Thanks for your thoughts on the matter. Yes. I neglected to put that in my post. I am running 15.6.1(105) on both Clients, Engine and Server. When you say "fixed IP", what do you mean by that? The Server name is what I input, its IP address appears when upgrading on the app. I have always done that and this install is no different. Do you mean to leave the Server address set as the "default IP" of That doesn't appear to work. Do you instead mean the machine's router IP? Yes, that is DHCP. Please reread. I mention three IP's as being those in use- two clients, and a server. They are respectively ending in: .64, .70 and .86. Please re-read the comments I made and the IGMP multicast document from Retrospect. They say that using the multicast model they licensed for port 497 should work. It does, but pings to that address reveal a huge number of devices (judging by their IP) very old devices no longer active but previously assigned to that port. I wondered if that is the issue? Perhaps this is a cause of my problem, not finding the actual devices in use? I recorded the output of the ping list and you'll see the results on the attached document in that comment.
  9. I found this Retro article related to Multicast: https://www.retrospect.com/en/support/kb/why_is_retrospect_communicating_with_address_224_1_0_38 Running terminal as described by the article (ping test of, I found a huge number of assignments, which repeat. Could this be the problem?? No idea how to fix it. The only relevant IP's are clients at .70, .64 (TWO CLIENTS), .86 (the Server). Can I delete the others (.121, .83, .81, .67)? It seems these may be IP's stored in my router that are no longer active for these clients or their predecessors. I don't see how this could be gumming up the works but I could force my router to forget inactive clients, I suppose. Ping Result_multicast_181212.rtf
  10. If you have a mobile client, one that disconnects and reconnects from the LAN (wired) Retro 15.6 will fail when the client returns. It's happened to me twice that Retro doesn't recognize the client when it again plugs in / appears on the network on it's next scheduled backup. The error is "Client unavailable." I believe this to be a long standing issue. The Client in System Preferences seems not to give any bad indications and show status as normal, but it clearly isn't. The symptom is the client is un-recognized when refreshing or locating it, it can be seen after such a failure to run a script. I suspect this is a problem with (Retrospect's) multicast service as compared with Apple's Bonjour service. Even a desktop that has been restarted occasionally fails on multicast (due to sleep recognition issues previously reported). Apparently is still runs backups probably because the last time this happened I located to a fixed address. I can report a workaround to this issue which seems to work to recover from the error. Just log out the user and log back in, then launch the Retro app to locate the source client. Retrospect server then recognizes this client on future backup scripts.
  11. Not 0 for 5... If you look at my signature, the machines and the versions are current!
  12. Client failed with this error (-559) while in deep sleep yet attached to a network connection. It read no connected disk, merely timed out with this error in the log. When I returned to the office woke up the machine and re-ran the same script, it ran perfectly. Power settings (System Preferences>Energy Saver>Power Adapter) are the same as they have been, which ran in all modes including deep sleep prior to upgrade. Why?? Enclosing/attaching log snippet, images on power settings, error report. Retrospect errors_log_181113.odt
  13. I didn't use the Wake On LAN checkbox and in my case the Deep Sleeping client still doesn't wake up in the latest (15.6[125] Client). Since Mojave came out there doesn't seem to be a way to have the CPU run 24x7 while allowing the screen sleeps. Which makes coping with the non-fixed issue of error-559 impossible to work around. Comments? See my posting about this similar issue in the newest version of Client.
  14. FYI... File a web support request: https://www.retrospect.com/en/rscustomers/sign_up?locale=en Limited Chat functionality as well. Wait times too long.
  15. Lord knows, we've filed plenty of those, eh? Yes, I upgraded from 15.0, prior to that I had some issues similarly, but then the OS had different features/choices: check box as I recall allowed the CPU to run always and the display to sleep. Maybe it was the same and only the verbiage was changed on the MacOS side. Don't know. However Mojave is clearly a different animal. So anything like that, I guess could be, "... lost in the sauce." Will call them first, if I can get through. Thanks for the history lesson on 14.6 (14.1 Client). You didn't say if you are running Mojave, may I assume not? Thanks for your history.
  16. Hello, If you don't set the System Preferences>Security & Privacy>Full Disk Access as described on the appropriate web page before the first Retro Client (iMac running Mojave), on a backup, the following occurs to a (formerly working) backup script that tries to run: The Retro Backup of that client fails with errors. (expected). Client version is 15.6.0 (125). You get email notifications (several) of the errors (-550 network connection, incomplete, general error of no data received, "No Full Disk Access" during scanning- 54 of them on one report and thereafter times out @301 seconds. (Unexpected... REALLY!) Thereafter, having discovered the error (duh!) and fixed it, the backup will not begin when initiated because the Client hasn't reset itself and remains in the mode, "Preparing for Backup..." Two error failure condition emails, 2x (Error -505 Client Reserved) emails, I realized this. (Expected since I tried it twice) You can work around this condition by turning off the client manually and then on again. Whereupon the client is once again "Ready for Backup". Then you can initiate the script. After Scanning process, Client sleeps and a (-519 Network Communication) error results. This setting works for other clients (MBP). So this would be unexpected. May I respectfully suggest that the Client reset itself when these setting have been detected and in some other way simplify the notifications to avoid the above as issues if you don't get to the settings updates required by Mojave security before a backup starts. Maybe provide a way to reduce the multiple error warning emails and set up the client so it functions during sleeping the display in Mojave?? Retro Error log_181031.rtfd.zip
  17. In Mojave, using the new client, the icon no longer appears by default. Clicking the checkbox on or off accomplishes nothing on the menu bar.
  18. Web page seems wrong KB page describing full disk accesses in Mojave 10.14 . States that the app (note that apps only are allowed). The article states, "Client: Please add /Library/PreferencePanes/Retrospect Client." The screenshot has others shown... What's the right story and where do we find the described file(s)? Hint: not where it's stated or shown! Oh, by the way how to install Instant Scan?
  19. henry-in-florida

    Full Access Mojave

    Nige, Yep. Sorry I just posted a section of my window for you. It's the same. I had other stuff enabled. My client(s) are OK for awhile. One is running now with out an error. I have had clients that show up a -519 communications error where I've had to delete and re-add the client for unexplained reasons, however.
  20. henry-in-florida

    No more instant scan on MacOS?

    I got that feedback from support recently as well and reported it in another post here. Frankly, when using SSD's in clients, I don't see a huge advantage to ISA. Whether in incremental or full backup. It is a CPU hog and space hog. Maybe also duplicates processes already in place (in the case of APFS). I will compare again in 15.6 with ISA disabled to confirm this. Once turned off, intend to leave it that way. Locally, on HFS+ formatted (HDD) drives, maybe some advantage, but since the server does its thing quicker locally and is essentially unattended, I don't care too much. My 2¢... Henry
  21. henry-in-florida

    Full Access Mojave

    Just went to do the update. Found two issues with it. While available from the Retrospect.com web site, there is no update notice in the old app download a new update. While the text in the new KB version is correct but the screen shot for the Client install in Privacy settings is incorrect. It should look like mine not theirs. I previously reported issues like this and Lo! Still a small issue on the new one... FYI...
  22. henry-in-florida

    Full Access Mojave

    David, Thanks for that info. Not quite what I was told but similar and seems to be the ultimate fix. Will try it soon. There have been a lot of interesting followups to my post. Thanks, all! I hope that Retrospect people were likewise entertained.
  23. henry-in-florida

    Full Access Mojave

    Well, I heard from Retro Support that Instant Scan will be going away. And as some have said on this thread, there is a new client coming that will fix the issue, not waiting for Apple to do anything further. At least that's the gist of my understanding from the conversation I had with support. Since then, I did work around the exclusions for now and have my client running w/o the exceptions, on Mojave. But no Instant Scan. They say that the speed issues have been worked around and will be completed without the need for Instant Scan functionality, which I never really liked anyway (CPU hog, among other issues). Henry
  24. Certain partitions fail on clients with two different, strange errors: On an APFS formatted volume (internal SSD) on MacBook Pro 2017 backing up the entire drive. On MacOS Journaled drive, network timeouts occur in accessing the source. The ONLY [systems Preferences>Energy Saver>Power Adapter [Energy Settings] settings that work for me are shown. Unchecking "Prevent computer from sleeping," will result in these timeouts. I don't see where that's clear in your manual or other instructions. Seems that this condition used to be known as "deep sleep". I haven't had that issue in MacOS before 13.x not in Retro before 14.5 (do not know or have any ideas as to which version of OS or your software causes this, do you?). See the attached picture/screen shot. As to item # 1, here is log pertaining to this event. Using Instant Scan data for RAID 4 SSD on MyNewGenie_MBP 10/3/17 03:00:35: Found: 363376 files, 201365 folders, 1.1 TB 10/3/17 03:00:41: Finished matching 10/3/17 03:00:59: Copying: 743 files (2.5 GB) and 0 hard links [*] soccRecv: recv failed, error 60 !Trouble reading files, error -559 (network connection timeout) 10/3/17 03:02:55: Execution incomplete Remaining: 695 files, 1.7 GB Completed: 48 files, 818.3 MB Performance: 416 MB/minute Duration: 00:02:54 (00:00:56 idle/loading/preparing) As to item # 2, here is log pertaining to this event. - 10/2/17 07:14:44: Copying VM on MyNewGenie_MBP Scanning incomplete, error -1,101 (file/directory not found) 10/2/17 07:14:58: Execution incomplete Total performance: 705 MB/minute Total duration: 00:50:09 (00:15:00 idle/loading/preparing)
  25. With a MacOS Client (See MBP2017 information below, I am receiving error timeouts accessing the backup client times out during the scanning cycle. Also, separately getting errors when backing the APFS volume partition VM (unable to back up that partition (claims a virus error code on that partition, if selected to backup). It seems like this only occurs with this machine and may have something to do with APFS volumes compatibility. Retro_Errors.rtfd.zip