Jump to content

-519 -530 again and again and again

Recommended Posts

Oh well, #sigh

I have a few Macs.
All on WIFi
All on DHCP
They have to be this way, because they roam from office-to-office, client-to-client, home-to-work-to-home ... like laptops do.

The error -530 and associated -519 has be around in almost every version  of retrospect I have used for the past 20 years.
I can never find the solution, apart from a full client reinstall, and I can not be doing that every week TBH!
Is there ever going to be a stable answer?

Each Mac, Client and Server has no firewall or anti-virus FYI.

The fixed desktop Laptops that do not leave the office have no issues.

The laptops returning to the office login automatically to the WIFI and have no network issues for everyday work; email, www, ftp, server shares, printing ... what so ever.

Server: Mac OSX 10.11.6
Client: OSX 10.12.6
Retrospect 13.5

Please don't say 'upgrade to the latest version of Retrospect or I may have to slap you :-)
That has never been an answer to this issue.

Edited by redleader
mac specs updating
  • Like 2
Link to comment
Share on other sites

If redleader is getting -530 and -519 errors only on laptops logging on to the WiFi, but not on computers permanently cabled to the LAN, I suggest reading this post

All of my client computers are connected to the LAN by Ethernet cable.  However 3 years ago, when I started using Retrospect again, I was getting errors—and I now believe they were -530 errors—until Alan of Retrospect Tech Support told me to give the clients static IP addresses.  The post linked to in the preceding paragraph tells how to do it for my particular router.  Since it is done by associating a particular LAN address with the computer's MAC address (which as you can read here has nothing to do with whether the computer is an Apple Macintosh as some people think) that should work for all redleader's computers—including those connected over WiFi because that connection must also be through the router.  He/she should talk to his ISP or router provider.

Edited by DavidHertzberg
Reworded second prgf. to emphasize that setting static IPs via the router should work for WiFi-connected computers
Link to comment
Share on other sites

  • 2 weeks later...

How could I have failed to notice, back on 7 December, that both redleader's Retrospect backup server machine and client machines are Macs?  So this thread was started in the wrong forum (there is absolutely no mention of Windows machines—much less any running a Server Edition of Retrospect Windows), but—as a Retrospect Mac administrator—I'll respond again anyway.

First, the post I linked to in the second post of this thread doesn't mention that the assigned static IP addresses must be unique within the LAN.  When I see the address in the preceding post, that makes me suspicious; it looks like one that could be duplicated automatically by redleader's Netgear 6300 router, assuming he/she has enough clients/servers and/or printers on the LAN.  On my router I assigned the address for my networked printer (with which I had connection problems first), and and for my Mac clients (I'm hoping to hit the lottery, and turn my home into a medium-sized office—insert appropriate smiley here).  IMHO redleader should do the same for his/her WiFi connected MacBooks, and possibly assign static IP addresses beginning with to his/her cable-connected client machines for good measure; don't use any address ending in .255 or greater.

Second, the post I linked to doesn't mention that any Retrospect client machine that is assigned a static IP address must be first Removed from the Sources list (pages 80-81 of the Retrospect Mac 13 User's Guide) and then Added back (pages 76-79 of the UG).  An undocumented tip is that when recent versions of Retrospect Mac add a Mac client source, they do so defaulting to All Volumes in the Back Up popup menu in Options (page 50 of the UG)—and that default includes pseudo-volumes that only Retrospect Add Client can see; you must change that Options popup to Selected Volumes and check-mark only the real volume(s) you want to back up.  After that those client machines must be re-Selected in all the scripts that use them (page 111 of the UG); I've often thought of choreographing a dance to accompany the steps in this paragraph (insert appropriate smiley here).  An undocumented tip (DovidBenAvraham documented this in the Wikipedia article, but other editors made him take that out because it looked too much like something that belonged in a user manual—which of course it does!) is that, after doing a Save for a revised script, you can change the order in which Sources are backed up in the script by dragging them in the Summary panel and then doing another Save.

Edited by DavidHertzberg
Added caution about not using static IP addresses ending in .255 or greater; ony Add Client can see pseudo-volumes
Link to comment
Share on other sites

Apologises about the Posts location.
Forgive this #oldman, Retrospect since 1992, time to retire perhaps? :-(

I have done the IP address, fixed IP,  on the Netgear 6300, and all Clients have taken up those IPs fine on reboot.
The Server is at .100
I have removed and added the troublesome Client at .18 as per the manual and decades of good practice.

Same issues :-( The clients goes dead/dormant and will not respond to retrospect server.

Remote Desktop Picture 22 December 2017 at 09.12.50 GMT.png

Remote Desktop Picture 22 December 2017 at 09.13.28 GMT.png

Link to comment
Share on other sites

I first started using Retrospect in my home installation in 1995, stopped in 2010 when my backup server 7300 died of old age, and started again in 2015 when I inherited a Mac Pro to use as a backup server.  I'm already retired.

First, from the Console , try using Sources->select WiFi Mac->Refresh.  That is item 4 in this Knowledge Base article on Error -530.

Second, from the client machine, go to System Preferences and double-click the Retrospect Client icon while holding down the Command (apple or cloverleaf) key.  Then click the Advanced tab.  Do you see Server Address

Link to comment
Share on other sites

I remembered this afternoon that 2.5 years ago, when I started using Retrospect again, I had some connection trouble after I assigned a static IP address to my backup server—not just to my clients.  I got rid of it, and had no further problem on that score.  So I decided to do a bit of testing this evening, to see if I could reproduce redleader's problem.  Note that I do not use WiFi at all; the third paragraph in this post in another thread explains my LAN setup (the second paragraph explains the reasoning behind it).

I added a DHCP reservation entry to my router for the Mac Pro backup server, using its MAC address.  The static IP address I assigned was, whereas before the Mac Pro's address had defaulted to ( being the default address of the router).  In spite of rebooting my Mac Pro after I had updated the router, the the Server Address in the Advanced tab of my MacBook Pro's Retrospect Client stayed at until I did a Sources->select MacBook Pro->Refresh in the Console.  I then successfully ran a No Files incremental backup of my MBP.  I decided to get rid of the Mac Pro backup server's static IP; I did so in the router and then rebooted the Mac Pro, but a further Refresh of the MBP did not change the Server Address in the MBP's client until I manually changed back the IP address in the Mac Pro's System Preferences->Network panel—which had remained at despite several reboots of the Mac Pro!

My tentative conclusion is that specifying a static IP address for a Mac backup server in the router changes the IP address in the backup server's Network panel, but that de-specifying a static IP address does not change the IP address in the Network panel back to what it defaulted to before without manual intervention.  And remember, this is for Macs connected to the LAN by cable, not by WiFi.  I suggest that redleader look for discrepancies between what IP address his/her router specifies for the FS-SERVER backup server and what FS-SERVER's System Preferences->Network panel specifies.  It appears that Sources->select a MacBook Pro->Refresh changes a MacBook Pro's Retrospect Client Server Address based on what's specified in the backup server's Network panel, not what's specified in the router.

I now remember that Alan, the former phone-answering assistant to the Head of Retrospect Technical Support, told me back in 2015 not to specify a static IP for my backup server.  I know, from one other piece of advice Alan gave me, that he tended to give Retrospect administrators the most generalized advice rather than ask them questions about their particular installation.  However it's beginning to look as if his advice about not specifying a static IP for a backup server tended to keep the administrators out of trouble.

P.S.: A very unintended result of my testing is that I have—hopefully temporarily—truly messed up my own Retrospect backup server.  As a result, my weekly Recycle backup of 6 drives wouldn't even start correctly.  I am now completing a Restore of the Mac Pro's boot drive onto a second drive in the same machine, from a single-drive Media Set cumulative as of a week ago Friday (the Media Set cumulative as of yesterday is now sitting in my safe deposit box in the local bank branch, which wasn't open as of 4 a.m. this morning).  I will next copy over the Library->Applications Support->Retrospect folder, which should be OK if I substitute the Config80.bak file for the Config80.dat file.  Be very careful messing with the static IP address on your backup server, redleader.

Edited by DavidHertzberg
Clarifications; added P.S. with cautionary tale
Link to comment
Share on other sites

3 hours ago, redleader said:

The Posts seem to have got out of sync ... so, to recap ...

Mac Server using Retrospect is on .100 manually in it's system prefs network panel.
Mac Server using Retrospect is on .100 manually on the routers reserved devices list.



I understand that.  IMHO the key question, for one of your WiFi-connected clients, is (to quote myself two posts up) if you "go to System Preferences and double-click the Retrospect Client icon while holding down the Command (apple or cloverleaf) key.  Then click the Advanced tab.  Do you see Server Address "  When I was experimenting with a static IP address for my backup server the other day, I wasn't getting a match between the address the backup server was on in its own Systems Preferences->Network->Advanced panel and the address my client was looking for in its Retrospect Client->Advanced panel.

IMHO you should send a salesperson out to an extended lunch, leaving his/her computer connected via WiFi, and investigate this question.  See what the address is on the client when it is first re-booted, see what the address is 10 minutes later, see what the address is after you click Sources->client name->Locate on the backup server.

Edited by DavidHertzberg
Added a second sentence to the second paragraph, with specific suggestions
Link to comment
Share on other sites

  • 2 months later...
22 hours ago, redleader said:

Well ... we updated to v14.6.x [SERVER and CLIENT] for Mac OSX and the problem magically went away :-)


I hate to be the one to predict future rain on your parade, but your fixing the problem by upgrading the Backup Server and Client software may turn out to be an example of what I have termed -530 Bug 3—see the fourth paragraph in this post and boomcha's preceding post in that thread.  If that turns out to be true, I predict you'll "magically" start getting -530 errors again after a few weeks because of some kind of corruption in a configuration file.

As reported in this post responding to  saskia's preceding post in that thread, I now—as a result of experimenting to reproduce your problem—am getting -530 errors every single time I run a script to Backup my MacBook Pro using Retrospect Mac 14.6.1 (Client 14.6.0) under macOS 10.12.6.  The workaround, also reported in that post, only takes me about 2 minutes—so I'm willing to live with it.  One possible cure would be to replace the MoCA 1.1 adapters on a segment of my LAN with bonded MoCA 2.0 adapters, but that would cost US$160 and might not work.

Please report back every couple weeks as to whether your fix is still working.  I hope I'm wrong in my prediction.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...