Jump to content

henry-in-florida

Members
  • Content count

    137
  • Joined

  • Last visited

  • Days Won

    3

henry-in-florida last won the day on June 28 2015

henry-in-florida had the most liked content!

Community Reputation

13 Good

About henry-in-florida

  • Rank
    Retrospect Addict

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

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

  1. 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
  2. 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.
  3. 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...
  4. 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.
  5. 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.
  6. 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 227.0.0.1? 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.
  7. 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 224.0.0.1), 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
  8. 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.
  9. Not 0 for 5... If you look at my signature, the machines and the versions are current!
  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. 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.
  12. 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.
  13. 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.
  14. 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
  15. 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
×