Not all drives on client Mac backing up error-530

[toshy]

Retrospect 13.5, up to date client. Suddenly, after months/years of working normally, retrospect server is not seeing some drives on a client, although it can see and backs up the startup disk. One of the omitted drives is internal, the other external.

I have restarted the Mac, reinstalled the client etc but nothing changes. If I forget the client drives in the console and then add them again do they have to be fully backed up or will the media set just add the changes?

 

Thanks

[twickland]

The matching/don't add duplicates options are controlled by your backup scripts, and not by the source- or media set configurations. Simply forgetting and re-adding a source will not cause it to be backed up in its entirety (unless, of course, that is what your script had been set to do).

[Lennart_T]

Please check the "Privacy" pane in the client preferences (on the client) so the volumes haven't been excluded there.

[DavidHertzberg]

This post assumes what toshy said in the title of this thread, although not in his OP, which is that the failure to backup the non-startup drives on his client is associated with a -530 error.  The error text is "Error -530 backup client [my emphasis] not found", which implies that toshy has a "Retrospect server" that cannot see his client when the non-startup drives are being backed up.  toshy, if you just threw "error -530" into the thread title because it sounded similar to what you are actually seeing, IMHO you owe us an apology.

 

IME (and I have through serial misfortune become a bit of a Forums -530 expert), a key question is:  At what point in the execution of what script can the "Retrospect server" not see his client's non-startup drives?  That is because I have discovered that there are actually two types of problems associated with error -530, to which I originally assigned numbers in what has turned out to be the wrong sequence.  Activate your little gray cells, toshy, because understanding the following is going to require a bit of sophisticated thinking:

 

The first type of problem is what I have termed -530 Bug 1.  This is a single outright Engine bug, for which I have submitted a (now escalated to Retrospect Engineering) Support Case and run tests requested by Retrospect Support.  If the Engine is started and immediately has to run a Backup script (because the script was scheduled to start at least a few minutes earlier), and the first client it has to backup has a -530 Bug 2 (see below), the "Retrospect server" will issue a -530 error for the client when it probably shouldn't.  This is evidently caused by "“Sounds like Retrospect is dumb and trying to run before the network is 100% functional ... ", which is the comment made by another Ars Technica poster in the thread I started in the Networking Matrix forums there.  The work-around I found (simplified from a solution by hgv which is technically beyond my level of expertise) is to schedule a "sacrificial script" 10 minutes before the actual Backup script.  If—when both scripts are run after their scheduled time because the "Retrospect server" was just started—the "sacrificial script" bombs with a -530 error but the actual Backup script runs OK,  but if—when both the client machine and the "Retrospect server" are running at least 15 minutes before their scheduled time—both the  "sacrificial script" and the actual Backup script run OK, you have what I have termed a -530 Bug 2.

 

A -530 Bug 2 is one of a range of bugs you have when the Engine finds a client to be "difficult to communicate with".  Not "impossible to communicate with" as defined in this Knowledge Base article, because in the cases defined in that article the Engine will issue -530 errors even if a "sacrificial script" or a real Backup script is run for the client before its scheduled time.  A -530 Bug 2 can result from either hardware or software causes.  

 

Since 31 January I have continually experienced a -530 Bug 2 because of a hardware mismatch on my LAN.  My MacBook Pro primary computer—which I backup daily—and an old G4 Digital Audio Mac—which I have resurrected for a future software project and only backup weekly, are in my study cabled to an 8-port gigabit Ethernet switch. My Mac Pro inherited from a dead friend, which starts up the "Retrospect server" upon booting from its usual disk drive but still also has the dead friend's disk drive, is in my bedroom cabled to a 5-port gigabit switch. Ethernet-cabled to the two switches are Actiontec MOCA adapters, which are connected to two ends of a between-the-study-and-the-bedroom RG-59 coax cable (re-purposed from the apartment building's original in-wall wiring), but these are MoCA 1.1 adapters that are capable of a maximum of 270Mbps.  Ethernet standards say the Engine should be able to ignore that speed mismatch, but it evidently can't if it starts to run a Backup script immediately after the Mac Pro is booted.  If the Engine can wait as little as 5 minutes before running the "sacrificial script" followed by the real Backup script, both scripts run OK, so that -530 Bug 2 is merely a LAN speed mismatch that the Engine should be fixed to ignore.

 

About a year ago for a period of 4 months, on the other hand, I experienced a -530 Bug 2 that was evidently caused by a software condition on my MacBook Pro.  Again the -530 error did not appear if the "Retrospect server" was booted as little as 5 minutes before the Backup script for the MacBook Pro was scheduled, so the condition qualified by my definition as a -530 Bug 2.  It mysteriously disappeared after an update to my Firefox browser, and so that -530 Bug 2 was probably caused by a "conceptual bug" involving automated updating of other software on the MacBook Pro client machine overlapping with Retrospect script execution.   A fix that would handle such cases would require the Engine to emit a log message on the order of "Retrospect is waiting a frigging long time to connect with this client"; it might be better in such cases to fix the Client software to use a time limit to signal an error to the Engine that would be something other than -530.

 

My guess, toshy, is that you are experiencing a -530 error when you run a Backup script that backs up the client machine first but only backs up the two non-startup drives—not the startup drive.  If so, I suggest that you precede that scheduled Backup script with a "sacrificial script" as described in the fourth paragraph in this post.  If that makes your real Backup script run OK, my further guess is that your -530 Bug 2 was caused by automated updating of other software on the client machine overlapping with Retrospect script execution.  If that "sacrificial script" doesn't make your real Backup script run OK, you should try running a Locate of the client from the Sources panel of your Console ASAP after your Backup script has bombed with a -530 error; you might have some kind of persistent "conceptual" software problem or client computer hardware problem.                                    

[toshy]

Twickland, Lennart, David – thanks for your replies - see below

 

Twickland - that's good to know

 

Lennart - there are no restrictions in the privacy pane of the Client preferences (on the client)

 

David - I'll try to ignore the aggression in your first paragraph and give you a full account of what has been happening:

 

I have two backup scripts which run on alternate days, backing up to separate local disk media sets, but otherwise they are identical. I have used them for years and occasionally they fail - in a logical way that is easily sortable, often with the help of this list. Recently each has failed to fully back up one client - it will backup the startup disk on that client (which is an external SSD) but the internal disk and another external fail with a -530 error. I can send you a screen shot if you don't believe me. Yesterday the client was upgraded from MacOS 10.11 to 10.12 and I took the opportunity to run DiskWarrior on all the disks. It found no reportable damage but in my experience it can correct directory errors that are not apparent. I then opened Retrospect and ran one of the scripts that was reporting errors. It operated perfectly, backing up all three disks on the client.

These scripts are part of a series which run every (other) day; the Engine is not shut down between the operation of each script so none of what you describe in para 3 is relevant. The script which ran perfectly when triggered manually then operated automatically later that day. It failed to find the client or any of its drives reporting -530 errors for each drive (backup client not found). Again, I can send you screenshot of the log if you need it.

All of the other clients on the script continue to be accessible to Retrospect Server and are backed up. 

 

Any suggestions?

 

Thanks

 

Toshy

[DavidHertzberg]

Sorry, toshy, but the aggression in my first paragraph was because I have trouble believing the situation you describe more fully in the first substantial paragraph in post #5 of this thread.  I suggest that you look again carefully at this Knowledge Base article.  The only thing I can imagine is that your two scripts backup the startup disk on that client first, and that the client then goes to sleep before the internal disk and another disk can be backed up.  However there may be some weirdness such that the client is accessible through the external SSD but not through the internal and external spinny disks.  I have no personal experience with any kind of SSDs.  Please post your screenshot in this thread.

 

As for your second substantial paragraph in post #5, that corresponds more closely to my -530 experiences as described in post #4—in which I failed to mention that in both my separate -530 problems the script would also run perfectly if triggered manually after failing when run automatically via its schedule.  I'm wondering whether the Retrospect Engine is finding your problematic client "difficult to communicate with" even when the Engine has been running for a while before trying to backup that client.  I didn't say that my -530 Bug 1 is the only bug the Engine has, nor do I rule out other varieties of what I called -530 Bug 2.  Please post your other screenshot in this thread. 

[DavidHertzberg]

A second thought, toshy:  Down at the very bottom of the "What's New" for Retrospect Mac 14, the Other Enhancements say "Network Connectivity – Retrospect 12 for Windows and Retrospect 14 for Mac include clients that are more resilient to network hiccups and outages."

 

When I was running tests for -530 Bug 1 at the request of Retrospect Support, they provided me with a trial version of Retrospect Mac 13.5—13.5.0(317)—a late build that contained networking bug fixes that Support wanted me to test on my problem.  I suspect that these were the same fixes that are incorporated in Retrospect Mac 14 as the Network Connectivity enhancement.  The trial client release didn't fix my -530 problem, but the fixes might work for your problem.  One easy test would be to upgrade the Client software on your problematic machine to the Retrospect Mac 14 Client, doing the usual Console-Client-Console dance for dropping and adding a client.  Another approach would be to start a Support Case—which I have been informed by Mayoff can be done for a bug even if you don't have Annual Support and Maintenance, and ask Support for a trial of the 13.5.0(317) release.

 

P.S.: I would also suggest setting up "sacrificial script" versions of your two Backup scripts, as linked to in the last paragraph of post #4.  If you schedule these 10 minutes ahead of the real Backup scripts, they may fix your problem even if the Engine is not shut down between the operation of each script.  That would be consistent with the phenomenon you report in your second substantial paragraph of post #5.

 

P.P.S.: toshy, you should have made post #5 in place of post #1.  If you don't give us all the information you can in your OP, we have to drag it out of you post by post.  Either that, or we have to make a WAG which—as in my post #4—may turn out to be wrong because of lack of information.  In the case of post #4, it took a lot of effort for me to write it.  It's not totally wasted effort, because it will help others if I can have an as-clear-as-possible explanation of -530 Bug 1 and -530 Bug 2 to link to.  However, I think my aggression at the end of the first paragraph of post #4 was justified, considering how little information you supplied in post #1.

[DavidHertzberg]

toshy, a further thought:

 

In your scripts that get the -530 error when backing up the two non-startup disks on one client, what is the sequence in which the disks are supposed to be backed up—and in which the disks are backed up when you run one of the scripts manually?  Is it the startup disk first, followed by the internal disk and the other external disk?  Or is the startup disk last, preceded by the internal disk and the other external disk?

 

If so, I wonder whether you are getting some variant of the software-caused -530 error I described in the sixth paragraph of post #4 in this thread.  This would be a "conceptual bug" involving automated updating of other software on the affected client machine overlapping with Retrospect script execution.  Think about whether you have recently installed additional software on the affected client machine.

[DavidHertzberg]

toshy, this is a little late, but I just found this post while trying to solve someone else's problem in another thread.  Although the thread linked to is about someone's -519 errors (which would probably be changed to -530 errors by the #6080 fix in Retrospect Mac 13), the post stimulated my little gray cells—because it suggested a possible cause for your problem with getting a -530 error on only some of the disks on a client.  Try unchecking the "Put hard drives to sleep when possible" checkbox in System Preferences->Energy Saver on your problematic client.