Jump to content
maxhowarth

error 530. the gift that keeps on giving.

Recommended Posts

i've read the many posts by david hertzberg (thank you david for all your hard work) relating to the backup clients not being found on the network.

we're using r14.6.1 backing up 8 sources (all macs) to a mlogic lto-6 tape drive. i'm finding that although the clients appear in the client list i'm getting repeated backup failures due to 530 errors. as per david's many posts, removing and re-adding all the clients manually fixes this issue but it doesn't last.

surely there must be a way of getting past or working around this rather infuriating problem. 

Share this post


Link to post
Share on other sites

maxhowarth and boomcha:

I suggest that you first read this post again, so that I can use terminology I've already defined.  (Don't worry that the thread is defined on a Retrospect Windows forum; I defined the terminology based on my experience as a Mac administrator.)

If your affected Macs can be backed up after you successfully execute a Sources->select client->Locate, then you have one or more types of -530 Bug 2 occurring.  These range from the -530 Bug 2 I have been having for the past year—where the -530 seems to be caused by some sort of Ethernet speed mismatch between components of my LAN—to the -530 Bug 2 I had for about 5 months starting two years ago—where the -530 seemed to be caused by some kind of automatic software updating being applied to a client machine simultaneously with its being backed up.  In the first case the Retrospect Inc. engineers ought to be able to fix the bug with careful attention to the "backup server"'s networking code, while in the second case the bug might be difficult for them to fix without instituting some kind of "timeout" limit for simultaneous software updating.  You may be able to fix the cause of the -530 Bug 2 yourselves with hardware or software changes.

If your affected Macs can be backed up without a -530 error if the "backup server" machine has been booted 10 minutes or more before the script starts to execute, and if otherwise you get a -530 error only on the first client machine being backed up, then you have a -530 Bug 1 occurring.  This is obviously caused by some kind of "too-slow waking up" problem in the Retrospect Engine code, but the Retrospect engineers have so far not gotten around to fixing it—probably because doing so would require too much work.  You may be able to work-around the cause of the -530 Bug 1 error, regardless of the existence of a -530 Bug 2 error, by either scheduling a "sacrificial script" to run first or by not scheduling your backup script to run until 10 minutes after the "backup server" machine is booted.

If you—as maxhowarth and others including me have experienced—have fixed either a -530 Bug 2 or -530 Bug 1, only to have the the fix fail after a few days, then you have what I must now term a -530 Bug 3.  The fix that eventually fails is typically the removing and adding of client machines in the Retrospect Console.  This appears to be caused by some kind of corruption in a Retrospect configuration file, although whether that file is in the Engine software or in the Client software I cannot yet say.  Right now I am getting some indications that a Sources->select client->Refresh may again temporarily fix the problem; I'll know more tomorrow morning.  If that works, a Sources->select client->Refresh for each affected client would be faster than the the removing and adding of client machines in the Retrospect Console, with its required re-adding of client machine to Retrospect scripts.

Please reply with additional posts in this thread specifying under precisely what circumstances of "backup server"-bootup-timing and client-position-in-backup-script you get -530 errors.

Share this post


Link to post
Share on other sites

maxhowarth and boomcha:

The test I ran early this morning, pausing my "sacrificial script" run and using a Sources->select client->Refresh, didn't work; my"real" daily incremental backup run failed, and I had to do a Sources->select client->Locate before manually re-running the backup script.  I will try swapping in lower-speed Ethernet switches (which used to work) before deleting and adding the Client on the machine I backup daily.

I suggest that maxhowarth submit a Support Case for -530 Bug 3; why and how to do so are here, and he could also mention  boomcha's experience   I had the same experience with the fix stopping working as maxhowarth and boomcha nearly two years ago, but I'm not going to report it now because it is too stale.  Besides Retrospect Tech Support might think I'm making a career of reporting multiple separate -530 Bugs, since I already have a long-standing Support Case in for -530 Bug 1 and my version of -530 Bug 2.  You can tell them I suggest that they have the Retrospect engineers create what I call an "instrumented beta version" of the Retrospect Engine and Retrospect Client software, and distribute that version to a number of users who are experiencing -530 Bug 3.  Each initial "instrumented beta version" would have code that compares its networking configuration file at the end of a script run to a stored version as of the beginning of the script run; that should enable the engineers to identify the script situation that causes a change in the networking configuration file to occur.  After they've done that, the engineers should distribute a new version of the "instrumented beta version" with the comparison code moved earlier in the Engine or Client code; thus gradually they should be able to pinpoint the place in the code where the configuration file gets corrupted.  Please tell Tech Support that I volunteer to run a copy of the "instrumented beta version", since I'm still chasing down a new -530 error of my own.

Edited by DavidHertzberg
fixed typo

Share this post


Link to post
Share on other sites

I woke up this morning well before the 3 a.m. scheduled time for the first of the two Sunday-through-Friday Backup scripts for my MacBook Pro.  As promised in the last sentence of the first paragraph of the post directly above, I swapped in lower-speed Ethernet switches (which used to work) before deleting and adding the Client on the MBP (and then adding the MBP client back to the appropriate scripts, dragging it to the top of the Summary panel when necessary).

The "sacrificial script"—that uses the No Files option—scheduled for 3 a.m. really ran OK, although as usual I had forgotten that in recent versions of Retrospect Mac adding a client defaults to the All Volumes option—including "pseudo-volumes" that only the client-adding logic can see (I've reported this in a separate Support Case, only to be met by the Tech Support reply that the volumes must be there if Retrospect can see them—insert wincing smiley here).  I changed the client option to Startup Volume by the time that the "real" Sunday-through-Friday Backup script ran at 3:05 a.m., so that ran perfectly.  Note that the Client software I installed on my MBP is the Retrospect Mac 14.1 version, because I had problems 4 months ago with the 14.6 Client even though I use the 14.6 Engine and Console on my Mac Pro "backup server".

The acid test will come tomorrow, when I intend to not boot my "backup server" until sometime distinctly after 3:05 a.m..  If the "sacrificial script" gets a -530 error (or even runs OK) but the "real" Saturday Backup script—which does a Recycle backup of 6 drives and takes 8 hours—runs OK, then I'll be back to the situation I had before I started experimenting—as described in the P.S. of this December post.  Then we'll see how long that situation lasts, based on the problems maxhowarth and boomcha have been having.

Share this post


Link to post
Share on other sites

I find that Retrospect sometimes gives a -530 error after having been successful for months and that I can get going again by forgetting and then adding the client again at the server end. A nuisance. There is no change of IP address involved since all of the addresses are statically assigned. I also have clients where the boot partition shows up but not the other partition until I re-install

Share this post


Link to post
Share on other sites
On 2/9/2018 at 5:07 PM, saskia said:

I find that Retrospect sometimes gives a -530 error after having been successful for months and that I can get going again by forgetting and then adding the client again at the server end. A nuisance. There is no change of IP address involved since all of the addresses are statically assigned.

As recounted in previous posts in this thread,  and in a previous thread, I find the "drop and add client" solution works for only a week or two.  Since my last two sets of hardware changes (attaching a pair of 100Mbps-speed and then gigabit-speed Ethernet switches), it hasn't worked at all.  My current solution is to Pause all running scripts during the "sacrificial script" run, whose running  I've prolonged to 10 minutes with Preferences changes, and to then Locate my MacBook Pro—which always works within a couple of seconds.  After that I Stop the "sacrificial script", and the real backup script finds the MBP and runs OK.

Edited by DavidHertzberg
Added Stop of "sacrificial script" step to last sentence; removed space before closing quote-mark; Resume unnecessary

Share this post


Link to post
Share on other sites

For three months now, after I experimented temporarily with reverting to 100Mbps Ethernet switches, the "sacrificial script" has had no effect in making the "real" script run. If my Mac Pro "backup server" is not booted until after the 3 a.m. scheduled time for my scripts, I have to manually: [1] Pause the "sacrificial script" in its 10-minute effort to find my already-booted MacBook Pro client, [2] Locate the MBP in the Sources pane, [3] Stop the "sacrificial script" in the Activities pane. Thereupon the "real" script starts running, finds the MBP after a couple of seconds, and proceeds to do what the script says. If my Mac Pro "backup server" is booted before the 3 a.m. scheduled time for my scripts, all I have to do is Locate the MBP in the Sources pane, after which the "sacrificial script" and then the "real" script proceed to run starting at 3 a.m..

Yesterday afternoon, having just received delivery of a 50-foot Ethernet patch cable I had ordered for an unrelated use, I ran an experiment. I disconnected the MoCA adapters from my 1Gbps Ethernet switches in the study and the bedroom, and substituted the 50-foot patch cable (because it is 50 feet long, I can run the cable around furniture and corners and along halls between the two rooms). "Sacrificial scripts" scheduled for 10 minutes after my "backup server" was booted ran to completion. However "sacrificial scripts" scheduled before my "backup server" was booted couldn't Find my already-booted MBP.

This proves that my particular -530 Bug 2 is caused by the Retrospect Mac 14.6.1 Engine being confused by some kind of momentary timing delay in my MoCA adapters, which—as I stated above—can be overcome by doing a two-second Locate of my MBP connected to my Mac Pro "backup server" via the MoCA adapters. I'm not prepared to spend $120 to $160 upgrading my 270Mbps MoCA 1.1 adapters to 1Gbps MoCA 2.0 bonded adapters, since they may not solve what is fundamentally a Retrospect bug. Over a month ago I upgraded my MBP's Retrospect Client software to 14.6.0, which didn't make any difference.

The preceding 3 paragraphs are copies of the latest Additional Notes to my Support Case.  The bolding starting midway through the first paragraph was an artifact resulting from my having itemized the manual steps using letters surrounded by square brackets; the letter 'b' surrounded by square brackets is apparently interpreted by the Forums system as a bolding command.

Share this post


Link to post
Share on other sites

I'm still struggling with this as well. I don't have anything fancy in my little network, all through Cat 6A and standard consumer/home office grade gear that works perfect otherwise. I believe this bug was introduced in 14.6 as I never had any issues before. I have a ticket open and as of the latest beta version in Retrospect 15 it wasn't fixed yet. I don't want to pay for version 15 if this is something that they broke in 14.

Essentially my issue is that Retrospect server won't see the clients and thus errors out in -530. Locating the device finds it again and it works until the next time the machines are rebooted and then its busted again.

Share this post


Link to post
Share on other sites

FedEx delivered my new Motorola Zoom Telephonics bonded MoCA 2.0 adapters early in the afternoon of 9 May, and I tested one of them before going to the gym. However I wanted to do further tests using both of them, but first had to register and speak at an official meeting on the 2019-2020 Canarsie Line renovation—grabbing dinner before the meeting started and doing grocery shopping after it ended.

My idea in substituting only one of the adapters first was to test out my speculation that a hypothetical power surge on 30 January 2017 had damaged the MoCA 1.1 adapter in the study while ruining the adjacent 100Mbps Ethernet switch. Since MoCA 1.1 is supposed to be upwardly compatible with bonded MoCA 2.0, simply replacing the adapter in the study would test my speculation. Well we can definitively discard my speculation; I still had to do a Locate under all circumstances to get the Engine to see the MacBook Pro's Client, but the combination of one new and one old adapter worked fine for "sacrificial" backup scripts (running them is faster) once I did the Locate.

My further tests late on the night of 9 May, with both new bonded MoCA 2.0 adapters substituted for the old MoCA 1.1 adapters, produced the same results. My conclusion is that it's Retrospect that has "gone bad" in two successive stages, starting on 31 January 2017, not any networking hardware.

I forgot to say that yesterday, before the FedEx delivery, I dug out my used-once 40-foot length of Radio Shack RG6 coax (it's got printed labels) and repeated the test I did back in the spring of 2017. I got the same results I've been getting for the past 2 months with my RG-59 cable running through the walls and under the floor, so there's nothing wrong with that piece of networking hardware either.

Share this post


Link to post
Share on other sites

It turns out that the developers at Retrospect Inc. are also eager to fix the -530 bug (I now think there's only one bug with 3 manifestations). On 14 May I left a voicemail on the Tech Support hotline, asking to whom I should snail-mail my now-no-longer-needed MoCA 1.1 adapters and 40-foot coax cable. Early on 15 May I received an e-mail from the head of Technical Support, saying that liability issues prevented Retrospect Inc. from accepting equipment from customers, but offering me a test version of Retrospect Mac that is related to the -530 bug. Later that afternoon I received another e-mail telling me how to download and install the test version of Retrospect Mac 15.0, which turns out to have added logging to troubleshoot -530 errors. I downloaded and installed that evening, and have been running both test and daily incremental production backups of my MacBook Pro using the test version. Last night I uploaded the resultant logs to my Support Case, and today I will revert back to my regular Retrospect Mac 14.6 version.

IMHO the moral of this story so far is that some bugs can be very difficult to find and fix. If only a minority of users experience a bug, and if most of those are too busy to help isolate the precise conditions in which it occurs, the developers of Retrospect are going to find it very hard to reproduce the bug under controlled conditions.

Share this post


Link to post
Share on other sites

hey david

maybe you could pm me the his contact details? i'd be happy to run a test version of r15 if it helps the cause.

Share this post


Link to post
Share on other sites

maxhowarth please contact support directly for test version requests. That is the best way to reach us in situations like this. 

Share this post


Link to post
Share on other sites

Just to prove that I wouldn't have tried to bypass Tech Support, here is a slightly-edited version of the PM I sent to maxhowarth on 19 May:

"I have communicated your kind offer to Retrospect Tech Support, which I eventually managed to do by leaving a voicemail message (I had forgotten that, if you sit through the announcement saying you should send an e-mail, you'll eventually get a chance to leave a voicemail) on the U.S. number.  My first voicemail earlier this week was evidently heard by ... the head of R.T.S. ..., but it was Jeff (McIntire?) who responded by updating my 15-month-old Support Case with the instructions on how to get and set up the test version of Retrospect Mac15.0.  I believe that Jeff  goes by the "handle" Eppinizer on the Forums, now that he is relieving ... [the head of R.T.S.] in handling phonecalls.

However my guess is that R.T.S. won't take you up on your offer.  As an applications programmer who retired after 40 years, I think that they will decide that the engineers need the simplest kind of test data for -530 errors.  And I provide that simplicity, because I have only a single "client" that unfailingly gets -530 errors, and I back that "client" up first on Saturdays and alone on other days of the week.

Nevertheless you might consider filing a new Support Case that includes the offer to do testing.  IME R.T.S. always reads and responds with an e-mail (even if automatically generated) to newly-filed Support Cases.

Good luck!"

Share this post


Link to post
Share on other sites

Believe it or not, I got Retrospect totally working again over last weekend, complete with the bonded MoCA 2.0 adapters that now are attached to the ends of a detached in-the-walls coax TV cable that has been a segment of my LAN since 1998. :)

I should explain that the most ancient piece of hardware on my Mac Pro "backup server" is actually its former boot HDD, which was originally the boot drive on the 2005 G5 Quad that preceded the old MacBook Pro as my main client machine. When I inherited the Mac Pro in 2015, I left my late friend's boot HDD untouched (I back it up once a week) and re-purposed my old HDD as the boot drive (this is the unfortunately-discontinued "cheesegrater" Mac Pro that holds up to 4 drives). About 5 months ago, feeling that the boot HDD was running out of capacity and really getting a bit long in the tooth, I cloned it onto an SSD that became the new boot drive but left the HDD in the machine.

A week ago Friday, having uploaded the test logs from the "backup server" and the MBP client, I tried to revert Retrospect to the latest non-test non-bleeding-edge version. In the tradition of "no good deed goes unpunished" that has dogged my 6-months-long attempt to diagnose its -530 bugs, this left Retrospect in a totally-non-client-backing-up state. So I said "b*r it", re-designated my old HDD as the boot drive, and upgraded its Retrospect Engine and Console to non-bleeding-edge Retrospect Mac 14.6 and the MBP's Client to Retrospect Mac 14.1. I then ran my usual Saturday Recycle backups of all 6 of my drives (backing up the Mac Pro's HDD boot drive instead of its former SSD boot drive), along the way rebuilding the Catalog File for this week's archive file to compensate for the fact that the Media Set's 500GB portable HDD sole member had temporarily run out of space doing Recycle backup runs using two different Catalog Files (the one on the SSD, and then the one on the HDD; my error in not erasing the portable HDD after the first Recycle backup that worked for non-"client" drives).

After all that, last Sunday's incremental backup of my MBP ran OK. What's really interesting is that the following morning's incremental backup of my MBP ran OK too, even though I let it start at 3:25 a.m. and—as an experiment—didn't do a preliminary Locate. To top it off the "sacrificial" script ran OK that morning before the "real" script, which hasn't happened since February 2017 if the Mac Pro is booted substantially after 3 a.m. (the "sacrificial" script was my February 2017 workaround for -530 Bug 1; it sacrifices itself so that the "real" script runs OK even when the Mac Pro is booted after 3 a.m.).
 

Share this post


Link to post
Share on other sites

i contacted support on the 21st (case number 00061458) but still no response. i can repro the issue incredibly simply and 100% of the time.

remove all clients

add a single client

hit refresh, client is seen and refreshed.

reboot the server mac

click on the client previously added

hit refresh

530 error, client not seen.

 

 

so as long as i never reboot the server the clients remain connected. but obviously that's not workable.

 

 

 

 

 

Share this post


Link to post
Share on other sites

I did have a networking problem per se that was affecting Retrospect. I casually fixed it the weekend before last, but only early Saturday morning did I realize that it had been affecting the backup.

Before reading further, please remove all sharp objects from your immediate vicinity, so that you don't hurt yourselves when you fall down laughing. ;)

Along with the Mac Pro, in 2015 I inherited my late friend's Apple 27-inch LED Cinema Display, which originally cost around $1K in 2010. Of course I immediately attached it to my MacBook Pro and my Digital Audio G4 via a KVM switch. My new MBP has only USB-C ports, so I bought an Apple-marketed Moshi Ethernet-to-USB3 dongle that also has a pass-through Type A USB 3.1 port. I then used that port to connect a StarTech USB3-to-DisplayPort adapter that functions as an external DisplayPort video card, passing DisplayPort signals from the MBP to the KVM switch.

I immediately noticed artifacts on the LED Cinema Display, especially when looking at Page View Statistics for Wikipedia articles—which shook about 60% of the time. I thereupon cursed the DisplayLink company that actually makes the StarTech adapter. :(

The weekend before last the cat5e patch cable that connects the MBP to my switch in the study fell out of the Moshi dongle for about the sixth time. That time I noticed that the Moshi dongle's RJ45 Ethernet port has trouble with a cat5e connector that has the usual rubber hood over the plastic snap on the connector. I peeled back the hood so that it sits underneath the snap, and the RJ45 connector now snaps in solidly.

I've seen no artifacts on the LED Cinema Display since then. It was only early Saturday morning that I realized the reason for that was that the RJ45 cable had previously been shaking in the Moshi dongle's port because it wasn't firmly snapped in. The shaking could very well have affected the Retrospect Engine's ability to connect with the Client running on the MBP, even though it didn't affect the software's ability to pass signals once the connection had been manually made. :o

P.S.: Sorry, forget what I said in the first and last paragraphs in this post. After running a totally successful from-scratch backup of all my drives Saturday morning, in which even the "sacrificial" script ran without a preceding Locate, I decided this afternoon to make a more-stringent test of my hypothesis that previous shaking of my MBP's RJ45 connection might have affected backups. I changed my Mac Pro's boot drive from the HDD back to the SSD, and reran Saturday morning's "sacrificial" script without a preceding Locate of the MBP. It didn't work. What's worse, when I changed the Mac Pro's boot drive back to the HDD it could no longer run a "sacrificial" script unless I preceded that with a Locate. My conclusion is that the totally successful runs reported in this post were simply the result of re-initialization of Retrospect's "client"-related configuration file(s), and—as has been previously experienced by other administrator users as well as myself—the re-initialization was eventually overridden by the -530 Bug 3 that causes corruption of the configuration file(s). :(

P.P.S.: However, the problems that required manual action when booting my "backup server" from the HDD now seem to have gone away. Sunday morning, when I booted the "backup server" 3 hours after the 3 a.m. scheduled time, the "sacrificial" script got a -530 error but the "real" script ran OK. Monday, when I booted the "backup server" 2 hours after 3 a.m., both the "sacrificial" script and the "real" script ran OK. If this situation continues—which it may not because of -530 Bug 3—then I'm back to where I was in February 2017; the "sacrificial" script eliminates any need for manual action. :)

Share this post


Link to post
Share on other sites
Cheer up.  I had received the following response from Retrospect Tech Support before I made this 
post in the thread.

"Agent Response: 
Hi David, 

The logging you've provided does appear to be quite useful. We can clearly see the IP address 
matches on both server and client, yet the address fails to resolve. 

For your reference, we've created escalation 7478 to track this issue. I know you have been 
seeing the -530 errors in several different circumstances, but there may be an underlying issue 
which is the cause of all of them. I will let you know as the escalation progresses, we may end 
up sending an new test build for additional logging if necessary. 

Thanks for your help with this. 

Regards,
-Jeff
Please let us know if you have any additional questions,
The Retrospect Support Team" 

Share this post


Link to post
Share on other sites

As a result of my "sacrificial" “NoOp Sun.-Fri. Backup” script and my incremental “Sun.-Fri. Backup” both failing early—but later than their scheduled 3:00 a.m. and 3:05 a.m. times—the morning of 1 June with -530 errors, I may have an possible cause of at least the -530 Bug 3. I thought back to what I had done on 31 May to cause some Retrospect configuration file(s) to "go bad" since that morning, and remembered that I had briefly unplugged the bonded MoCA 2.0 adapter in my study. My MacBook Pro in the study—which is what the two scripts back up—was running at the time, but my Mac Pro "backup server" in the bedroom was shut down. Therefore it shouldn't have made any difference if I unplugged the adapter, whose only purpose is to extend my LAN from the Ethernet switch in my study through a coax cable to another matching MoCA adapter and Ethernet switch in my bedroom for use by the Retrospect "backup server". I only unplugged the adapter for a couple of minutes, while I moved its plug on a surge protector to make room for another voice-phone-related device that I needed to plug in. But it later occurred to me that the Retrospect Mac Client 14.1 program in my MBP was running, even if it wasn't doing anything. Could the Client program's temporarily losing its standard connection path to the Engine, even if the Engine was shut down at the time, have caused a configuration file in the Client to reset itself in a way incompatible with future connections? If so, that would be what I term a "conceptual bug" that would be at least cause -530 Bug 3. If the configuration file(s) reset happened to only cause an incompatibility only if in the future the Engine had just been started and had to immediately run a scheduled script, then that would result in a future manifestation of -530 Bug 1. And—come to think of it, that's what could very well have happened the night of 30 January 2017, when I did an emergency replacement of the Ethernet switch in my study. I likely did leave my (old) MBP running while I did the switch replacement, since its failure to connect to the Internet is what alerted me to the fact that the switch had failed. And leaving the MBP running would allow me to immediately test if the replacement switch was working.

Share this post


Link to post
Share on other sites

This evening of 1 June before dinner I did the usual dance: (1) Remove the MBP "client" in the Console. (2) Uninstall the Retrospect 14.1 Client from the MBP. (3) Install the Retrospect 14.1 Client in the MBP. (4) Add the MBP "client" in the Console. (5) Add the MBP "client" in the Console back to those scripts that use it, including dragging it to its frontmost position in the Summary of those scripts that back up multiple "clients" (the two "... Sun.-Fri.Backup" scripts only back up my MBP). I then scheduled two executions of the “NoOp Sun.-Fri. Backup” script for a few minutes in the future, and immediately shut down my Mac Pro "backup server". I did not reboot the Mac Pro until several minutes after the first of the scripts was scheduled to run. Both of the scripts ran OK. The proof of the pudding on the morning of 2 June was that my "sacrificial" “NoOp Sun.-Fri. Backup” script got a -530 error, but my incremental “Sun.-Fri. Backup” ran OK.   I'm now back to the situation as of 8 February 2017—with only -530 Bug 1 occurring.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×