Client -530 error workaround, and what happened when it stopped working

[DavidHertzberg]

Retrospect Inc. engineers, please note this thread in the "Retrospect 9 or higher for Macintosh" forum.  I started the thread to let everybody know the workaround A. of Retrospect Inc. had told me about, but I did some bug isolation—whose results are summarized in post #5 in the thread—after the workaround stopped working.

 

 To quote from the second paragraph in post #5: "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 ...."

 

Also, when my MacBook Pro is backed up by a script as scheduled—because it has been awakened and the Mac Pro has then been booted before the scheduled time of the script, Instant Scan runs.  From the final paragraph:  "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) ."

 

P.S.: As the new post #6 (20 March 2016) in the linked-to thread states, I had to do the workaround procedure again—and this time that procedure worked.  So thus endeth my bug-isolation efforts for now. 

[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]

It occurred to me this morning [18 May] that I may 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 could give that drive a name such as "Macintosh HD 530Test", and use Retrospect to restore the contents of David's MacBook Pro'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.

 

Mayoff, you have my e-mail address.  Let me know if this would help the Retrospect Inc. engineers investigating the -530 bug.  I could start working on it as soon as next week.

[hgv]

You may want to take a look at my workaround here: http://forums.retrospect.com/index.php?/topic/152290-retrospect-13-error-530-backup-client-not-found/

[DavidHertzberg]

A belated thank you to hgv, whose workaround inspired my "Skull Island tradition" workaround here.  My workaround is much more kludgey, but easier to implement for those of us lacking the OS X/macOS skills that hgv evidently has.

 

I have, of course, created a Support Case for my workaround.  Both of these workarounds disclose a glaring bug in the Retrospect Engine, and I've been told that my Support Case—precisely because it's such a kludge that happens to work reliably—has stirred a fair amount of discussion in Walnut Creek. Let's hope the Retrospect Engineers get around to fixing the bug in time for Retrospect Mac 14.5.