henry-in-florida

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

Thanks for your suggestion, Robin. I'm just reporting what happened, just out of the blue with one of my media sets. The drive contained several other media sets. When I got to it to inspect what had happened, the whole device was completely empty. As described, started over. and the new backup on the reformatted device worked perfectly. Will research further as to what happened on Console logs.

One of my backups failed on doing a recycle backup, with the error. But it got worse from there: ALL of the drive contents got deleted! All the contents of the drive contained other Retrospect backups, so not just the one backup file, but all others were somehow deleted by this recycle action. I manually stopped the backup and checked the drive. The drive checked good in Disk Utility. No apparently failures. Just to be sure, I erased the drive and checked it. All OK. This is the log of the event: + Recycle backup using Bi-Weekly Mac Mini_Seagate 4TB12_3x at 6/6/22, 22:00:00 (Activity Thread 1) 6/6/22 22:00:00: Finished scanning backup set data files To Backup Set MacMini_Seagate 4TB_12... 6/6/22 22:00:00: Recycle backup: The Backup Set was reset Warning: volume Seagate 4TB_12 has the "Ignore ownership" setting enabled. - 6/6/22 22:00:00: Copying Seagate 4TB_12 6/6/22 22:02:59: Found: 822960 files, 84614 folders, 3.1 TB 6/6/22 22:03:01: Finished matching 6/6/22 22:03:03: Selector "All Files" was used to select 822,960 files out of 822,960. 6/6/22 22:03:06: Copying: 822960 files (3.1 TB) and 0 hard links 6/6/22 22:03:08: Finished scanning backup set data files [*] ArcDisk::arcExportSessionFile: unexpected value of ArcCatalog::m_lastvol 0; can not write session file 6/7/22 22:30:26: Execution stopped by operator Remaining: 822,960 files, 3.1 TB Completed: 0 files, 0 B Performance: 0 MB/minute Duration: 1:00:30:25 (1:00:29:57 idle/loading/preparing) [*] ArcDisk::arcExportSessionFile: unexpected value of ArcCatalog::m_lastvol 0; can not write session file Recovery was simply to remake the catalog (same name and other parameters) and start over. Backup works for now. I am using an alternate backup application until/if this ever gets figured out. First time for this error for me. I've read about this error here in Windows applications. Including a screen shot of the current (restored) media set members as it completes the first repaired backup. Any ideas?

Thanks for your insight, David. My goals: Restore my backed up user data, settings and data from a working version of Mojave (10.14.5). Erase and Install a new version OS (e.g., Mojave 10.14.6) to an external (at first, as a test and ultimately) the internal drive on my MBP recovering all data from previous working version. Pare down installed apps on the original to 64 bit on/after the upgrade. This could be done after the install. Scope, which I hope to apply to any new future version (Catalina): Erase and Install new OS. Migrate apps using Migration Assistant from the fastest possible connection method. Migrate or preferably (if it's proven to work) use Retrospect (Restore: Replace corresponding...) to move the Users folders data onto the target drive. Questions: Have you tried your method? Coming from High Sierra -> High Sierra, same OS, what problems did you have to face? Has anyone tried it for an upgrade to different OS's? Example: High Sierra to Mojave. Have you used the Retro function, Restore: Replace corresponding...for this purpose? Were you ultimately satisfied by the cost vs. gain, e.g., time required and the results achieved?

I've been interested in new ways you may have found to use Retro 16 to fully restore a machine after an OS (bare metal) Erase and Install of the Mojave OS. Anybody have a proven step-by-step after such an OS upgrade using Retrospect 16 instead of Time Machine, for example to migrate data, users, settings? Alternatively, in a bare metal install recreating the user manually how about to migrate the users information (data files/folders) if all the user setting are in place. Maybe discuss here the pros and cons of each?

Gee, David, relax. Don't worry be happy. It was a bug report it's something that should work but doesn't. Someone (you?) did away with the signature in profile where I had that updated. It's on the OP (original post), now. So how about posting the full spelling of obscure mnemonics you use so everyone can enjoy? How do you know I didn't file a ticket? Refresh seemed to work, but is flaky as reported. Whether it "ever worked" I leave to you, Surely you have the history. I think it's always been flaky in one way or another, yes I do expect it to work in the way it's described in the User Guide.

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. For some reason signatures are no longer available/presented (where I had my User equipment, versions, backup device info, etc.) So, I'll try to include on every post until that feature of the forum is restored or found again. Retro Desktop Multi-Server 15.6.1 Host (Engine) CPU:  Mac Mini, 2GHz Core2 Duo, 16GB RAM, 500GB internal SSD (APFS), OS X 10.14.3 Host Backup Media: 8x External SATA III via Thunderbolt, 2x via FW->USB, USB3.0 500GB SSD Standalone Drive Router (1000BT wired and 802.11n/b/g wireless) Retro Client: Retro 15.6.1 (all)  3 Intel Clients (iMac, MBP), CPUs running OS X 10.14.3 H Retrospect log_190219.rtf

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

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.

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...

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.

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.

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.

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

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.