“Sorry, couldn't connect to PCxxx, error -530 . . . "

[edbaines]

First, let me say that after the problem statement, I think I have a solution. Posting for reference since searching Error -530 is non-productive.

 

After installing Retrospect Client 11.5, it works for a several days to weeks. Then I get, “Sorry, couldn't connect to PCxxx, error -530 . . . ". I am able to connect with Direct IP configuration but not with Piton Name Service.

 

I can get it back by uninstalling and reinstalling the Client. Repair/ Modify does not work, must be an uninstall – restart – new install. Now each new uninstall and reinstall of the client results in a functional link for up to several days.

 

Furthermore, this is a fairly simple machine software-wise. Also in my research this port seems to be assigned for use by Dantz so I would think it reasonably unlikely that a legitimate piece of software deliberately hijacks the port.

 

I looked over my list of installed programs. The critical applications is VMWare Workstation. The list includes Windows 10, Microsoft products and software that supports specific hardware from Intel, Nvidia and Areca. I also have Libre Office, Google Drive, Dropbox, MS OneDrive, Veracrypt, BestCrypt, Keepass as I have the host handle sync with the cloud and encryption. Also noted Apple Bonjour was installed. I did install Windows 10 Software Development kit a few weeks ago to try to diagnose some USB issues but the problem with Retrospect pre-dates this installation.

 

VMWare does not share the physical ports with the VM host. It has access to a separate 4-port Intel 350 ethernet card. To be clear, the VM host is where Retrospect Client fails. (too much host/ client terminology here.) Interestingly, the two main clients I run are also Retrospect Clients and they have run flawlessly for probably 18 months - since I switch over to Windows 10. 

 

Premium support said that the ability to add by IP address meant port 497 (the “Dantz” assigned port), had functioning TCP but UDP was blocked. They basically said they had nothing else to offer other than assigning my client machine to a fixed IP address.

 

I am posting this because I think I found a solution. I didn’t know why Apple Bonjour was there and I did not have any reason that I could think of that I would need it so I uninstalled it. The Piton name service could then find the Retrospect client.

 

So if you have a similar problem, try uninstalling Bonjour.

 

 

 

 

[DavidHertzberg]

I've had a thread going on -530 errors since 8 February in the "Retrospect 9 or higher for Macintosh" Forum.  I started it when I began getting a -530 error because of a hardware change in my LAN, and discovered a rather-kludgey work-around that I felt I should share.  I then created a Retrospect Inc. Support Case, because the work-around illuminated the fact that there are actually two separate Retrospect bugs that combine to cause a work-aroundable -530 error.  In that Forums thread I labeled these -530 bug (1) and -530 bug (2), based on the sequence in which I distinguished them.  This labeling is unfortunate, because the bugs have to occur in the sequence bug (2) followed by bug (1) for you to get a work-aroundable -530 error, but I'll stick with the numeric part of the labeling because I've already used it extensively.  I will in this Forums thread, however,  eliminate the parentheses and refer to them as -530 Bug 1 and -530 Bug 2—as I have done in my Support Case (which is also still ongoing because I've been doing testing—summarized in that Forum thread—in cooperation with Retrospect Support).

 

The concept of -530 Bug 2 is a bit difficult to grasp, because it revolves around a client that—for the Retrospect Engine running on the "backup server"—is "difficult to establish connection with".  That rules out a client that is "impossible to establish connection with", for reasons stated in the -530 Knowledge Base article;  I'll deal with which category Ed Baines' -530 errors fall into in my next post in this thread.  A client can become "difficult to establish connection with" for either software or hardware reasons.  A year ago in February I started getting -530 errors for my MacBook Pro client for software reasons; they mysteriously went away last June, as summarized in this post in an old thread and in the posts it links to in that old thread.  On 31 January of this year I started getting -530 errors for my MacBook Pro client because of a LAN hardware change; as recounted in post #4 of the thread linked to in the first sentence of this thread's first paragraph, I eliminated them by making a further hardware change to my LAN.

 

The concept of -530 Bug 1 is also a bit difficult to grasp, because it revolves around the word "establish" in "difficult/impossible to establish" in the preceding paragraph.  My discovery this February is that—if you have a potential -530 Bug 2—you can avoid getting an actual -530 error on a scheduled Backup script (I don't know about Proactive scripts because I don't use them) by one of two work-arounds.  The first work-around is to make sure that your client machine, followed by your "backup server" machine, are booted in that order at least 10 minutes before the Backup script is scheduled to run.  (Last spring I actually got a hint of this work-around, as recounted in the P.P.P.P.S. of this post in my old thread.) If you can't do that, the second work-around is to schedule a "sacrificial script" to run 10 minutes before your real Backup script is scheduled to run; a "sacrificial script" is described in the fourth paragraph of this post in the thread linked to in the first sentence of this thread's first paragraph—just substitute the word "selector" for the word "Rules" because you are using Retrospect Windows.  If either of these work-arounds avoids your getting an actual -530 error, then you know that you actually have a -530 Bug 2 for your client—because if they don't work your client is "impossible to establish connection with".  In short, -530 Bug 1 is that the Retrospect Engine software—which starts when the Mac "backup server" is booted (I don't know the Windows equivalent) and must immediately execute a scheduled script—gives a -530 error if the first client (I don't know about subsequent clients) the script says to backup is "difficult but not impossible to establish connection with".

 

P.S.: Replaced "-530 Bug 1" with "-530 Bug 2" in second and last sentences of third paragraph; added additional sentence at end of third paragraph to clarify -530 Bug 1.

 

P.P.S.: The Engine (as opposed to the UI Console) of Retrospect Mac starts when the "backup server" is booted; corrected new last sentence of third paragraph accordingly.  It's possible that -530 Bug 1 doesn't exist on Retrospect Windows, but I doubt it—since most of the underlying code is the same for both Retrospect Mac and Retrospect Windows.  A poster on my Ars Technica Networking thread commented on my description of -530 Bug 1:  “Sounds like retrospect is dumb and trying to run before the network is 100% functional. See if you can just put a pause in the beginning of the script or tell it to do a ping to the target computer before starting the backup attempt. I've seen similar problems. The switch just switches but from one bit of hardware to the next, the time for the link to become active and start passing traffic might be a few seconds different and that might be enough for poorly made software to error out.”

[DavidHertzberg]

Now let's talk about whether Ed Baines' -530 error falls into the category of -530 Bug 2, and about why my -530 past errors and somebody else's fall into that category.

 

First, since Ed Baines says "To be clear, the VM host is where Retrospect Client fails", he should look at this post in the "Windows ... Professional" forum by Scillonian.  He should also look at post #14 in the same thread, where the OP x509 says "the issue was that previously the Retrospect software on Client C was bound to a VMWare Ethernet interface, not the physical Ethernet interface".

 

Second, since Ed Baines says "I didn’t know why Apple Bonjour was there and I did not have any reason that I could think of that I would need it", he should look at the second paragraph of this section of the Wikipedia article on Apple Bonjour.  If he wants to know what Apple Bonjour is, he can start at the top of the article.  Maybe he had an obsolete version of Bonjour services, as detailed in the sixth paragraph of the linked-to section of the article.

 

Unless  Ed Baines is willing to reinstall Apple Bonjour on his client machine, we'll never know whether his -530 error is an example of -530 Bug 2—since he won't be able to try the two work-arounds in the third paragraph of my post #2 in this thread.  

 

The -530 errors for my MacBook Pro in the spring of 2016, were pretty definitely a case of -530 Bug 2, because they didn't appear on the nights when I booted my MacBook Pro—followed by my "backup server" Mac Pro tower—at least 10 minutes before my backup script's 3 a.m. scheduled time.  Those errors mysteriously went away in mid-June, apparently as a result of an automatic update to the Firefox browser.  

 

The -530 errors I had from 31 January through 27 February 2017 were definitely a case of -530 Bug 2, because they didn't appear on nights when I either booted my two machines well before 3 a.m. or scheduled a "sacrificial script" (which I devised in February) for the MacBook Pro before the real backup script.  Those errors went away as soon as I installed a gigabit Ethernet switch in one of my two LAN-covered apartment rooms to match the gigabit Ethernet switch I had hurriedly installed to replace my 100Base-T switch in the other LAN-covered room.  

 

hgv's -530 errors in the summer of 2016 went away when—as recounted in post #8 of the linked-to thread—he/she  developed an OS X work-around that became an inspiration for my less-sophisticated "sacrificial script" work-around.

 

P.S.: Split fourth paragraph into three paragraphs—with links in fifth and sixth paragraph, added a seventh paragraph about hgv's -530 errors.

[DavidHertzberg]

My further testing, at the request of Retrospect Support, indicates that the "sacrificial script" need not be "sacrificial"—meaning it need not get a -530 error—if it doesn't access a client.  

 

I created a test script that backed up from scratch a 42MB Favorite Folder (Subvolume in Retrospect Windows terms) from the _non-boot_ drive on my Mac Pro "backup server" to an extra Media Set (Backup Set in Retrospect Windows terms), and scheduled it before my regular "Sun.-Fri. Backup" script for my MacBook Pro client.  I had previously reinstalled my old 100Base-T Ethernet switch in place of my brand-new gigabit switch on my LAN.  When I awakened my MacBook Pro and then booted my Mac Pro two hours after the scheduled start time for the first of the two scripts, they both ran OK.

 

The night before, I had run only my regular "Sun.-Fri. Backup" script for my MacBook Pro client starting 1.5 hours after its scheduled time.  The old 100Base-T Ethernet switch was in place on my LAN, and the script bombed with a -530 error.

 

Once the Retrospect Engineers have recovered from the wild party they undoubtedly had upon shipping v14/v12, I think Retrospect Support should get them started on fixing -530 Bug 1 in the Engine as I have reported it.  The fix will be "just giving the Engine enough time to get things set up properly".