Client -530 error workaround, from Retrospect Inc. Tech Support

[DavidHertzberg]

Around 15 February I started getting -530 errors for my MacBook Pro when my "Sun.-Fri. Backup" incremental script made its daily scheduled runs.  However, when I then ran the same script manually from the Console, it ran fine—as it had been doing via schedule for 7 months prior to 15 February.  My "Sat. Backup" Recycle Media Set script got the same -530 error for the MBP on its weekly scheduled run, but backed up all drives on my other two Macs.  When I then manually ran my "Sat. Backup  Incremental" script to compensate, the MBP backed up all files as if it were a Recycle Media Set run—which it was for the MBP on that particular Media Set.

 

After nearly two weeks of this behavior, I realized on 25 February that the -530 errors had started just after just after I updated the Retrospect Client on my MBP from 12.0 to 12.5 before running the tests described in this post.  The morning of 26 February I realized that I might be able to fix the problem by reverting the MBP's Retrospect Client to the 12.0 version, and that I would probably have to do so by restoring it from a Media Set—but that I was scheduled to Recycle the only Media Set that still had the 12.0 Client the next morning when the "Sat. Backup" script ran.  Since I didn't know where on my MBP disk I could find the Retrospect Client files (the app is not in Applications to prevent a client user's deleting it), I phoned Retrospect Inc. Tech Support to ask.

 

As soon as the words "-530 error" were out of my mouth, A. told me he could give me a workaround for it.  He told me to do the following: (1) Remove the MBP from Sources on the Retrospect Console.  (2) Export Client Installer from the Retrospect->Preferences->Console onto a flash drive, and then sneaker-net that flash drive over to the MBP.  (3) Run "Uninstall OS X Client.app" (no quotes) from the flash drive on the MBP.  (4) Make sure the file "root-drive-name/Library/Preferences/retroclient.state" (no quotes around file name, root-drive-name is usually "Macintosh HD" with no quotes) is no longer there; if it is still there, delete it.  (5) Run "Retrospect Client Installer.pkg" (no quotes) from the flash drive on the MBP, and alter the MBP's System Preferences->Retrospect Client preferences as required. (6) Add the MBP to Sources on the Retrospect Console, and then alter that client's Source Options as required.  (7) Re-checkmark the MBP as a Source in all Scripts where it should be used, and then (although A. didn't say this—either because he knows I know to do it or because he doesn't accept derek500's report in this post) drag the MBP client into the proper sequence position in the Summary of any of those Scripts that backup more than just the MBP.

 

A. also said that Retrospect Inc. engineers are investigating the underlying cause of such -530 errors, but that they haven't found it yet.

 

I did what A. said, and the workaround eliminated the -530 errors (so long as the MBP is awake when a script backing it up runs).  YMMV (for non-Americans, that's shorthand for "Your mileage may vary"—a caution given at the end of auto mileage claims in TV ads for many years in the U.S.).  Not only do I now have a working 12.5 Retrospect Client on my MBP, but Instant Scan has now started working on the MBP for the first time.  Step (2) deleted the file "Macintosh HD/Library/Preferences/retroclient.state", and step (4) re-created it.

 

Here followeth a short tale of my stupidity as a likely explanation of why I started getting -530 errors on scheduled scripts starting around 15 February; feel free to skip it.  On 15 February, when I decided to update the Retrospect Client on my MBP from 12.0 to 12.5, I discovered that Retrospect->Preferences—>Console wouldn't Export Client Installer directly to my MBP over my LAN.  Rather than using a flash drive and sneaker-net, I downloaded Retrospect_Client_12_5_0_111.zip from download.retrospect.com.  IIRC—thinking I was doing an update—I then ran Mac_Client_Update_12_5_0_111.rcu from the downloaded Mac Client Updater folder, rather than "Uninstall OS X Client.app" followed by "Retrospect Client Installer.pkg" from the downloaded Mac Client Installer folder.  The result was that I didn't delete the file "Macintosh HD/Library/Preferences/retroclient.state", creating some kind of mismatch that seems to cause the -530 problem.

 

Compounding this stupidity was my initially thinking that the -530 problem was being caused by some startup LAN connectivity problem between my Mac Pro "Retrospect server" and the MBP (I normally do not boot the Mac Pro until it is past time to run a script, with at least the MBP awake).  I therefore added Firefox to the Mac Pro's Startup Items as a connectivity check, and gradually replaced each non-coax piece of LAN cable between the Mac Pro and the MBP.  It was only when none of these measures resolved the problem that I started thinking about the MBP's Retrospect Client.

 

In addition, before starting to think about the MBP's Retrospect Client, it occurred to me that maybe closing port 497 on my router had belatedly started to cause a problem.  So, despite my having posted this, I tried re-opening port 497 again.  That didn't solve the -530 problem, and I have—since implementing A.'s workaround—closed port 497 without getting any -530 error.  Note that, if you have an internal firewall—such as on a particular computer—or an internal router on your LAN, you do need to have port 497 open for TCP and UDP.

 

P.S.: Very belatedly noticed that I had two step (3)s in the third paragraph; renumbered the steps.

[DavidHertzberg]

As of the day before yesterday, error -530 is back on my MacBook Pro.  Tried the workaround yesterday.  As of this morning, the workaround didn't work. 

 

For my failing scheduled "Sun.-Fri. Backup" script, I just run it again from the Console.  My scheduled "Sat. Backup" script simply skips the MBP and goes on to backup the next client, so from the Console I submit a "Sun.-Fri. Backup" script to run after it—which backs up the MBP from scratch because  the "Sat. Backup" run has done a Recycle Media Set.  Therefore no big deal, just a minute per day of inelegance.  

[DavidHertzberg]

Early this morning (7 March 2016), left my MacBook Pro awake and my Mac Pro "Retrospect server" machines up when I went to bed around 2 a.m.., When I awoke at 5 p.m. the "Sun.-Fri. Backup" No Media action script had run as scheduled, starting at 3 a.m.. No -530 error for the MBP. 

 

I believe that several weeks ago I tried this approach of booting the Mac Pro (which has the Retrospect app in its Startup Items) before it was time to run a scheduled script.  IIRC it also eliminated the -530 error then also.

 

Tomorrow I'll try this again, but quit the Console app well before "Sun.-Fri. Backup" is scheduled to run. 

[DavidHertzberg]

Early this morning (8 March 2016), left my MacBook Pro awake and my Mac Pro "Retrospect server" machines up when I went to bed around 2 a.m., but quit the Console app well before "Sun.-Fri. Backup" was scheduled to run.  When I awoke at 6 p.m. the "Sun.-Fri. Backup" No Media action script had run as scheduled, starting at 3 a.m.. No -530 error for the MBP.  

 

Tomorrow I'll try this again, but take the Console app out of Startup Items and shut down the Mac Pro well before "Sun.-Fri. Backup" is scheduled to run, then reboot the Mac Pro after "Sun.-Fri. Backup" is scheduled to run .  What I'm trying to determine is whether the -530 error for the MBP happens only when the Console  is running when the script is ready to run, or whether it occurs when the Engine starts running after the script is ready to run. 

[DavidHertzberg]

....

 

Tomorrow I'll try this again, but take the Console app out of Startup Items and shut down the Mac Pro well before "Sun.-Fri. Backup" is scheduled to run, then reboot the Mac Pro after "Sun.-Fri. Backup" is scheduled to run .  What I'm trying to determine is whether the -530 error for the MBP happens only when the Console  is running when the script is ready to run, or whether it occurs when the Engine starts running after the script is ready to run. 

 

 

This morning I did this, and got a -530 error for my MacBook Pro, verified by starting the Console after the LED on my USB3 Media Set disk drive stopped flashing and by looking at the log.  As usual after a -530 error, I was able to manually run my "Sun.-Fri. Backup" script for the MBP.  I noticed that, when I did so, there was no Instant Scan for the script—which there had been when the script was recently being run as scheduled from when I successfully executed the workaround up through 3 March.

 

My conclusion is that, for me at least, the -530 error occurs when the Engine is started (by booting my Mac Pro) after the scheduled time for the script—whether or not the Console is started when the Engine is started.  However, from when I successfully executed the workaround up through 3 March, I could boot the Mac Pro after the scheduled time for the script and the script would automatically be run—as shown by the Console which was in Login Items (which I have been referring to elsewhere in this thread as Startup Items).

 

My version of Retrospect is 12.5, and both the Mac Pro and the MBP are running OS X 10.10.5 (I don't consider OS X 10.11 to be "ready for prime time" yet).

 

P.S.: And it looks like my conclusion in the second paragraph is a winner!  This morning (11 March 2016) I left both my MBP and my Mac Pro awake when I went to bed shortly after midnight.  When I awoke at 3:20 a.m. the "Sun.-Fri. Backup" script had just finished running fine, including Instant Scan. 

 

P.P.S.: Amen to what I said in the P.S..  Yesterday morning (12 March 2016) I left both my MBP and my Mac Pro awake when I went to bed shortly after midnight.  When I awoke at 6 a.m. the "Sat. Backup" Recycle Media Set script had finished backing up the MBP, including Instant Scan, and was proceeding to compare it.  It went on to backup and compare my other 5 drives, for a total of 8.5 hours. 

 

P.P.P.S.: Oops, a further hypothesis bites the dust.    This morning (13 March 2016) I woke my MBP up at 2:57 a.m.—3 minutes before "Sun.-Fri. Backup" was scheduled to run—but did not start up my Mac Pro until 3:10 a.m..  "Sun.-Fri. Backup" failed with a -530 error.  When I ran it manually, it did not do Instant Scan.  My further hypothesis had been that there would be no -530 error if the MBP—and only the MBP—was awakened at least a few minutes before a script was due to run, but the Mac Pro was not booted until after a script was due to run.  

 

P.P.P.P.S.: This morning I happened to wake up at 2:45 a.m., 20 minutes before "Sun.-Fri. Backup" was scheduled to run.  So I immediately woke up my sleeping MBP, and booted my Mac Pro—which is the Retrospect "backup server" and has the Console among its Login Items.   "Sun.-Fri. Backup" ran just fine, including Instant Scan.  One notable fact is that, when the incremental "Sun.-Fri. Backup" runs with Instant Scan, it backs up nearly 9GB instead of just over 2GB—taking 17 minutes instead of 4 minutes for the copying phase alone.  Based on errors shown in the log, the additional 6GB includes many ~Library/Caches/Firefox/Profiles/ksalhsaz7.default/safebrowsing files (I was using Firefox while "Sun.-Fri. Backup" was running) .

[DavidHertzberg]

There was bad news yesterday on the debugging front, and there's good news today on the workaround front.

 

The bad news is that yesterday (19 March 2016), just as I was going to sleep shortly after midnight, I had a brilliant bug-isolating idea: that it was Instant Scan that was causing the -530 error  when the Engine is started (by booting my Mac Pro) after the scheduled time for the script.  So I disabled Instant Scan for my MacBook Pro (by holding down the Command key while clicking System Preferences->Retrospect Client to show the Advanced tab button, then clicking the on that button and doing the usual thing for changing Preferences).  I then went to sleep, woke up just before the 3 a.m. scheduled time for my "Sat. Backup" Recycle Media Set script, immediately woke up the MBP, but intentionally did not boot the Mac Pro until 5 minutes after the scheduled time for the script. I got a -530 error on the script for the MBP (it went on to backup all my other drives), got a -530 error again on the MBP for an execution of my  "Sun.-Fri. Backup" No Media Action script I manually threw in to run immediately after "Sat. Backup",  and then couldn't Locate the MBP.  So, crying in my figurative beer (it was too early in the morning for literal beer  ), I went through A.'s workaround procedure as spelled out in the OP of this thread  —which enabled Instant Scan for the MBP.   After I did that, another manually-submitted "Sun.-Fri. Backup" ran fine to do an effective Recycle Media Set backup of my MBP.

 

The good news is that this morning (20 March 2016) I didn't wake up until after the scheduled time for the "Sun.-Fri. Backup" script, but it ran fine when I awakened the MBP and then booted the Mac Pro.  So this time—as opposed to last time—the workaround again did all that I could have hoped.     Unfortunately, this means I can no longer do any bug isolation for -530 errors.   

[Mayoff]

This thread has a lot of information to digest, and honestly, I just haven't had time to read it all. A few general points about this type of error:

 

1) 530 error means that Retrospect can't see the computer on the network. The reasons could be different depending on how a client is added to Retrospect

2) With sleeping computers, you should turn on the Wake on LAN option in the Sources>Options tab of Retrospect. You must then edit the script options and turn on Wake on LAN. This will help Retrospect find the computer if it is sleeping.

3) Port 497 must be open for TCP and UDP Traffic. if you suspect the firewall is an issue, try turning it off to see if it helps. OS X does not easily let you manually enter port info into the firewall, but some 3rd party utilities can do it. Typically the OS will detect Retrospect activity and ask you to allow the firewall to open.

4) You can always go to Sources>Add>test to enter the IP address of a client to see if Retrospect can find it on the network at any given time. If the IP test fails, it means we don't see anything at that address over port 497.

[DavidHertzberg]

I'm sorry, Mayoff, but you'd really better read this thread thoroughly, and other threads I've started in the last few months in the "Retrospect Bug Reports" sub-forum of this forum.     To wit:

 

2)  Wake on LAN doesn't work for scheduled scripts; I've tried it per this thread.  As the sole post in that thread states, this is a Retrospect bug that has been known for years.

 

3)  Port 497 on an interface-to-Internet router doesn't have to be open for TCP and UDP traffic, so long as the machines on the LAN are not running firewall software  and there isn't an internal router on the LAN.  A. told me that it did back last July, and for seven months I believed him.  However back a couple of months ago, in response to "security hole" flak I was getting in my Retrospect-promoting thread on the Ars Technica Mac Achaia forum, I closed port 497 on my Verizon router.  As I reported in this thread, that hasn't caused any problems.

 

4) I've tried Sources->Add->test; if Locate can't find my MacBook Pro on the LAN, nothing else will.

[DavidHertzberg]

Mayoff, I think you should be ashamed of this post.  It feels like the "take two aspirin and call me in the morning" advice that harried M.D.s used to give to patients who phoned them.  And that goes for the advice in paragraphs 2) and 3) that A.—who presumably works for you—has been handing out. 

 

The summary e-mail that I sent—per this post—to support@retrospect.com about my accumulated evidence for my -530 problem was also shamefully misread by whoever wrote "Agent Reply".  So I'm going to forward my clarifying reply to that "Agent Reply" to robin.mayoff@retrospect.com.  Please remember that it was A. who originally told me that Retrospect Inc. engineers are trying to solve the -530 problem.  I'm just trying to be helpful. 

 

I am beginning to get the distinct feeling that there is an institutional disconnect between Retrospect Inc. Support and the Retrospect Inc. engineers.  Are you people allowed to occasionally talk to each other?  If not, who instituted that prohibition? 

[DavidHertzberg]

Most days over the last two months I've been getting -530 errors on my scheduled script runs.  I've done A.'s workaround a couple of times, but it hasn't been effective for more than a day or two.  I've even reverted my MacBook Pro to the 12.0 Retrospect Client again, but that didn't help.

 

On 14 May, with genuine anguish in my heart, I added a new post to my 4-months-long Retrospect thread on the Ars Technica Macintoshian Achaia forum. In it I recounted the series of -530 errors that I and other users have been getting, and that the Retrospect Inc. engineers have been unable to isolate and fix the problem.  In view of that, I recommended that anyone buying Retrospect take advantage of the 45-day free trial offer, and be prepared for Retrospect's stopping working for scheduled scripts even after that period.

 

I also wrote in that post: "For me at least, the -530 error seems to have something to do with the RetrospectInstantScan root process running on the client machine; the successful manually-from-the-Console reruns do not invoke Instant Scan—and the legacy PPC client [which never gets -530 errors on 'Sat. Backup' unless I forget to switch on the Retrospect Client after booting my Digital Audio G4] has no Instant Scan capability. However disabling Instant Scan on my MBP's Retrospect Client does not stop the -530 problem."

 

The next night I added a P.S. to that post: "Last night after editing this post, I left my MBP awake, booted my 'backup server' Mac Pro 45 minutes before the scheduled time for 'Sun.-Fri. Backup', and went to bed. When I awoke I found that 'Sun.-Fri. Backup' had run fine, including Instant Scan. I've tried the same approach other times, and gotten -530 errors. Do you see what I mean when I say 'they [Retrospect Inc. engineers] can't consistently reproduce the problem'?"

 

Early this morning my "Sun.-Fri. Backup" script worked fine again—even though I un-slept the MBP and booted my Mac Pro "backup server" well after the script's 3 a.m. scheduled start time.  The only thing I'm doing differently for the last couple of days is to wait a number of minutes until the RetrospectInstantScan root process on the MBP has quiesced, as shown by the CPU tab on Activity Monitor, before I boot the Mac Pro.

 

Come on, Retrospect Inc.!  I've been working hard on the Ars Technica Mac Ach forum for months to counteract the terrible reputation Retrospect has among posters there from years past—and now I'm faced with this!

[DavidHertzberg]

I conducted a couple of interesting experiments starting late this morning, as motivated by experiences I've had with Retrospect 12.5 over the last two weeks.  My conclusions are: (1) A -530 error can result from a client machine trying to do something on the Internet after it is booted while my Mac Pro "backup server" is accessing it.  (2) A -530 error can be avoided if the "backup server" does not run a script immediately after it is booted.

 

My first experience was that, starting two Saturdays ago, my "Sat. Backup" all-machines Recycle Media Set script started getting a -530 error for my old Digital Audio G4—which had never happened before.  The G4 is—as always—running the Retrospect PPC Legacy Client under OS X 10.3.  However, while doing a major cleanup of my dining table three weeks ago in preparation for a party, I re-discovered my install CD for MS Office 2004.  I have never bought MS Office for my MacBook Pro running OS X 10.10—I use LibreOffice instead—so I decided it might be nice to have it available on my G4 secondary machine.  After I installed Word + Excel + PowerPoint, Microsoft AutoUpdate started giving me messages about needing to install an 11.6.6 updater—which it couldn't find because MS has reorganized its website.  I realized yesterday that the Saturday following the Office 2004 install is when the G4 starting getting a -530 error during "Sat. Backup".

 

My second experience was that, twice during the last few nights, I have awakened well before the 3 a.m. scheduled time for my  "Sun.-Fri. Backup" No Media Action script.  On those nights I have  awakened my MacBook Pro and then booted my Mac Pro; "Sun.-Fri. Backup" has then run with Instant Scan for the MBP and without a -530 error.  This is not new behavior; see the P.S. in post #5 in this thread.

 

So last night I trashed Microsoft AutoUpdate on my G4.  Then, late this morning, I scheduled my "Sat. Backup Incremental" all-machines No Media Action script for a one-time-only run  that was supposed to be 15 minutes in the future—preceding this by awakening my MBP and booting my G4 (and manually turning on the legacy Retrospect Client on that machine).  The scheduled  "Sat. Backup Incremental" run started immediately after I scheduled it on the already-started Console for some reason, but it ran without -530 errors for either client—although with no Instant Scan for the MBP.  I then scheduled "Sat. Backup Incremental" again for a one-time-only run 45 minutes in the future; that time it again ran without -530 errors for either client—and with Instant Scan for the MBP (there is never Instant Scan for the G4, because AFAIK the final version of the PPC Legacy Client was written before the Instant Scan feature was added to Retrospect).

[DavidHertzberg]

It occurred to me on 18 May that I might be in possession of a Retrospect treasure: a MacBook Pro that fairly consistently gets -530 errors when backed up with Retrospect 12.5.  

 

I have a portable 2.5-inch HDD that I don't use very much.  I thought I could give that drive a name such as "Macintosh HD 530Test", and use Retrospect to restore the contents of my MBP's "Macintosh HD" onto "Macintosh HD 530Test".   I could then delete a few sensitive documents from the restored contents , after which I would verify that I could boot my MBP from the restored drive and then try to run a "530 Test Backup" script from my Mac Pro "backup server".  If that script failed with a -530 error, I would ship the "Macintosh HD 530Test" HDD drive to Retrospect Inc. to be copied and returned.

 

I posted that suggestion on my -530 thread on the "Retrospect bug reports" sub-forum of the "Retrospect 9 or higher for Macintosh" forum.  When I hadn't gotten a reply after two weeks—which is not totally surprising because the Retrospect Forums are user-to-user and not consistently watched by Retrospect Inc. personnel, I phoned the head of Retrospect Inc. Support this morning [01 June] to make the offer verbally.

 

R. said he appreciated the offer, and would pass it along to the Retrospect Inc. engineers.  He said, however, that the problem with reproducing the -530 error is really that that it depends on some combination of hardware and LAN as well as OS software.  It is apparently timing-related, having to do with how long the Retrospect "backup server" must keep trying to recognize a particular "client".

 

R. said the engineers are now trying to decide what changes to make to the Retrospect software to get around the problem.  A number of users are getting -530 errors, and some are getting other related errors.

 

David H.

 

P.S.: I originally made this post on my Retrospect thread on the Ars Technica Mac forum on 01 June.  I made it to let people on that forum know what was going on with the -530 error problem; the first two paragraphs and the first sentence of the third paragraph will not be news to anybody on this forum.  The person I refer to as R. in this post is, of course, Mayoff.  The reason I have now copied this post onto this forum is that results since 12 June—which I expect to be borne out by my weekly "Sat. Backup" script run tomorrow—indicate that what Mayoff said on 01 June about what the Retrospect Inc. engineers believe about the causes of -530 errors may not always reflect  a valid belief.  I expect that the results of my "Sat. Backup" run tomorrow morning, which I will post by tomorrow afternoon, will definitely call into question the validity—of the engineers' beliefs rather than what Mayoff said about their beliefs—of the second and third sentences in my fourth paragraph of this post.  Stay tuned!

[DavidHertzberg]

The results of the last week definitely call into question—in some cases—the Retrospect Inc. engineers' belief that the -530 error depends on some combination of hardware and LAN as well as OS software.  My experience over the last week is that -530 errors on an OS X 10.10 MacBook Pro can be caused—or cured—strictly by interactions—or inhibition of interactions—of application software with the Internet.  This post will deal only with my experiences from Sunday 12 June through Friday 17 June.  My experience today—Saturday 18 June, although it bears out the statement in the second sentence of this paragraph, is sufficiently complicated that it deserves its own post.

 

Very early on the morning of Sunday 12 June, I received an invitation from Mozilla to update my copy of Firefox on the the MBP and improve my use of its features.  I did so, which gave me a copy of Firefox 47.0 to which I added back Adblock Plus.  Some time after I had done so, finishing shortly before 3 a.m., I quit all applications on the MBP and booted my Mac Pro "backup server" to run my daily "Sun.-Fri. Backup" No Media Action script.  Contrary to my experience over the previous 4 months, in spite of the fact that it started after the 3 a.m. scheduled time, "Sun.-Fri. Backup" backed up my MBP without a -530 error.

 

This experience has repeated itself for every run of "Sun.-Fri. Backup" since then.  It doesn't matter how late after 3 a.m. I start the script, so long as I have awakened the MBP before booting the Mac Pro.  And, so long as I awaken the MBP at least 5 minutes before booting the Mac Pro, "Sun.-Fri. Backup" invokes Instant Scan.

 

A folder named "Old Firefox Data" has appeared on my desktop, created Sunday 12 June at 2:52 a.m., and containing over 1600 items.  This is evidence that the "improvement" involved extensive changes.  It certainly looks as if the "improvement" cured whatever was causing my MBP to get -530 errors whenever "Sun.-Fri. Backup" was started after 3 a.m..  My guess is that what was "improved" had something to do with the way a Firefox add-on interacted with the Internet.  But Firefox involves neither hardware nor LAN, nor is it part of Mac OS X.

 

P.S.: I'm running Firefox 47, not 42; so sure I didn't check; bad memory.

[DavidHertzberg]

This morning [saturday 18 June] I awakened my MacBook Pro and then booted my Mac Pro "backup server", expecting that the "Sat. Backup" script would start doing a Recycle Media Set backup of my MBP in spite of the fact that it was more than an hour past the script's 3 a.m. scheduled start time.  Instead "Sat. Backup" gave immediate -535 errors (backup client: network unavailable) for both the MBP and my Digital Audio G4—which I had not yet booted because it would not start being backed up until the 3-hour backup of the MBP was finished—and started scanning (unable to use Instant Scan) the first of the two local drives on my Mac Pro.  

 

I tried to use the Console to do a Sources->Locate of the MBP, but it could not do so and gave a -505 error (backup client reserved) when I typed in the hard-coded DHCP address of the MBP.  I then ran Firefox on the Mac Pro to successfully connect to Ars Technica, which proved that a LAN path through my Verizon router—which is connected to the Internet in the room where the MBP and G4 are located—to the MBP should be clear.  Next I booted the G4 and rebooted the MBP, after which Sources->Locate worked for both the MBP and the G4 without typing in a hard-coded DHCP address.   Finally I killed the "Sat. Backup" script—which was still scanning the local drive—and restarted it, and it ran to successful completion on all machines.

 

Meanwhile I remembered that when I had booted the Mac Pro I had gotten a message that Adobe Flash Player wanted to install an update, which I had postponed.   I had not gotten any such message for the MBP, which is why I had decided to reboot it.  Sure enough, it turned that the System Preferences->Flash Player had its "allow Adobe to install updates" radio button activated on the MBP (as opposed to its "notify me to install updates" radio button on the Mac Pro).  A post-mortem revealed that Adobe Flash Player Install Manager.app on the MBP had been updated an hour into the successful "Sat. Backup" run, which showed compare errors for nine Flash Player Install-related files on the MBP during that successful run.  

 

My conclusion is that Adobe Flash Player had started to do a self-initiated install on the MBP after I originally awakened it, and that is what caused the -535 errors and later -505 error during the first—scheduled—run of "Sat. Backup".   Again Adobe Flash Player does not involve hardware, nor should it either take over the LAN or be part of Mac OS X—although it gives itself airs.  BTW, doing a Forums search, I noticed that I myself encountered -535 errors when testing out client Wake-on-LAN for scheduled scripts—as reported in this post.

[DavidHertzberg]

IMHO the results recounted in this post, this post, and this post indicate that in some cases a true "conceptual bug" lies behind -530 errors.  (In my terminology, you know you have a "conceptual bug" when you find yourself saying "Oh s**t, I had no idea I'd have to code for this situation."  OTOH, you know you have a "carelessness bug" when you find yourself saying "Oh s**t, I knew I'd have to code for this situation, but my hand/brain slipped.")  This "conceptual bug" is the conflict between "scheduled pull to server" backup and automated updating.

 

In the first linked-to case, it was Microsoft Office 2004 that was doing—unsuccessfully—the automated updating.  In the second linked-to case, it was something related to Firefox—probably  Adblock Plus—that was doing the automated updating. In the third linked-to case, it was Adobe Flash Player that was doing the automated updating.  In all three cases the automated updating activity interfered with the Retrospect Client, producing -530 or -535 errors.  In all three linked-to cases, stopping the automated updating eliminated the -530 or -535 error.

 

The very heart of Retrospect's "scheduled pull to server" backup is the "backup server's" telling a Retrospect Client on the LAN "You must start sending me the files to be backed up right now."  If the client's machine replies—because of automated updating going on—"I can't let you connect to the Retrospect Client" or the Retrospect Client—again because of automated updating going on—replies "I'm here, but I can't send you files because the LAN is unavailable", the result is a -530 or -535 error in backing up that client machine.

 

This "conceptual bug" used not to be a problem because automated updating of application program files wasn't being done.  It is being done now, and solving the "conceptual bug" conflict will be a hard job for the Retrospect Inc. engineers.  In the mean time, it looks as if disabling automated updating for client machines being backed up by scheduled Retrospect scripts is the best approach to preventing -530 errors.

[mbernhardt]

David, has anything come of this since your last post? I found that if I deleted the client from the server, then deleted the client software, then installed new and reattached to the server, it would work for a while. But it never lasted. I've been a Retrospect user since the late 1980s and I'm very frustrated to now have these problems with my relatively simple needs. I started using CrashPlan because I was tired of the -530 errors, and unlike you I didn't have time to really study them. Now, I have to look at yet another solution unless I want to pay a lot more money. I haven't used Retrospect in several months and I don't want to pay for an upgrade unless they have solved this problem.

[DavidHertzberg]

mbernhardt, AFAIK Retrospect Inc. has done nothing to fix the problem—but I've done something to fix the -530 hardware-related problem that I started having on 30 January 2017.  What I did is described in another thread, especially in post #5.  Preceding posts in the same thread describe my analysis of -530 problems in general as well as that specific one.  

 

It sounds to me as if, since your fix works for a while before stopping working, you may have the particular -530 problem linked to in the preceding paragraph.  However, you may instead have a -530 "conceptual bug" of the type described in post #15 of this thread.  In that case, although a "sacrificial script" may solve it, you may instead have to deal with your "conceptual bug" directly—as I had to in post #13 in this thread.

 

BTW, mbernhardt, you wouldn't have had to make your post in this thread—much less PM me—if you'd used the Advanced Search facility of these Forums.  To use the facility, first click the little gearwheel icon at the top far-right of a browser page accessing one of the Forums, on the same line that says "IPS Community" on the left.  Then, if you want to restrict your search to threads dealing with the -530 error, type "-530" including the quotes (which are necessary to avoid finding posts that merely have the number 530 in them) into the Find Words box.  If you want to restrict your search to a particular Forum, make a selection in the Find in Forum dropdown menu.  If you want to restrict your search to posts made by me—with or without any other restriction, type "DavidHertzberg" without the quotes ("I am not a number; I am a free man!" said the hero of The Prisoner TV series of the 1960s—followed by voice of chief villain laughing in response) into the Find Author box.

[mbernhardt]

Thanks. At this point I'm trying out Carbon Copy Cloner for local backup of my 6 machines ($39 for all of them!), and will continue with Crashplan for cloud backup for the time being. I'm rather liking not having to deal with being dependent on a server that seems to require far too much administration (backup sets getting corrupted, not connecting to clients). Retrospect used to be a no-brainer but it's too problematic for me at this point.

[DavidHertzberg]

I'm sure Joe Payne (CEO of Code42) will be happy to eventually get even more of your money, mbernhardt.  And how long will it take you to, after using CCC to restore your latest onsite backup onto a replacement for a local drive gone bad, to download updated-since-the-last-CCC-run files from CrashPlan's cloud?  

 

Four months ago I had a local hard drive go bad with almost no warning.  It took me 2.5 hours to restore my latest (daily-updated) Retrospect Media Set (this is the Mac Forum) onto a spare portable drive, not counting the 0.5 hours it took Retrospect to systematically delete every file that was already on the portable drive.  I then simply booted another computer from the portable drive, and proceeded as usual.  When I got the computer that had had the bad drive back from Mike's Tech Shop (it is a laptop, and at my age I don't attempt to replace laptop drives myself) with the latest version of macOS on an SSD, I used Setup Assistant to update the SSD with the non-OS contents of the portable drive—taking about an hour.  Problem solved with no hassle.

 

I don't mess with cloud backup, because my Internet upload speed is too slow.  Instead I just do a daily Retrospect incremental backup onto a USB3 portable HDD.  Once a week I take that portable HDD to my bank safe deposit box, and swap it with another USB3 portable HDD onto which I then do a Recycle backup of all my 6 drives.  So I don't have to worry about Media Sets getting corrupted, because each one is only in use for a week before going to the safe deposit box.  My total time for drive swapping at the bank is about 15 minutes a week—including travel time, if I can catch a bank officer at a slack time.  If my friend hadn't died two years ago at age 88, my total swap time at his apartment would be about 30 seconds.