Jump to content

Frustrating Error -530 ( backup client not found)... but it is...


Recommended Posts

I am a long time Retrospect user and I must say, a long time frustrated user whenever there is a problem. Nothing is ever simply fixed. This time...

 

 

Problem 1:

I have one machine (MacPro OSX 10.8.5) on my all-Mac network that has been backing up happily to our server (MacMini OSX 10.8.5, Retrospect 11.5.3 (103)) for ever and a day. Last week I changed the name of the machine (in Retrospect > Sources > Rename) and ever since the automatic backup (each morning) fails with error -530 ( backup client not found)... BUT... when I get in the office, if I just manually run the script then the backup runs perfectly. I have been round the houses on this one – I have removed the source, un-installed the client, re-installed the client, re-added the source and updated the script... nothing appears to work. No network or firewall settings have changed on either the client machine or the server, nada, nothing.

 

 

Problem 2:

I have a new machine on the network (iMac OSX 10.10.5) which has the same problem namely, having installed Retrospect Client the automated backups have never worked (Error -530) but if I manually run the script on the server then the backup works perfectly. All network and firewall settings are the same as other machines on the network that are backing up properly.

 

 

Can someone suggest how to fix this and make the automated backups work please?

 

Thanks,
Tom.

Link to comment
Share on other sites

Hi Lennart,

Thanks for the reply but no, client computers energy saver preferences are set to never sleep and wake for network access. I have also tried them set to start up at the user selection screen and also to automatically log in to an admin user account but neither setup makes a difference.

 

To expand the backup process (which has been the same for years):

The client machines start switching on at 7am, staggered by 5 minutes intervals from each other. The server machine then switches on at 7:20 am and runs the backup scripts.

Link to comment
Share on other sites

It sounds to me as if Lennart is right. The inability of Retrospect 8 and above (IIRC Retrospect 6 didn't have this limitation—maybe for OS 9 clients) to backup sleeping clients is well-known. It is also well-known that wake for network access is not effective for Retrospect backups. My own experiments on my little LAN have shown these facts to be true.

 

However, also consider my posts here and here and here in a thread on a very similar topic.

Link to comment
Share on other sites

Hi David,

Thanks for the reply, but please see my reply to Lennart regarding Macs sleeping.

 

I have looked at your other posts and we already use static IPs and the other machines on the network are backup up normally, as was the MacPro before it's name was changed within Retrospect, so ports are open and working properly.

 

Tom.

Link to comment
Share on other sites

Hi Tom,

 

You made your second post in this thread, specifying your client Energy Saver preferences, after I had drafted—but not yet posted—the first version of my post above.  I then considered deleting my first paragraph in that post, but decided instead to add the sentence about wake on LAN—since what I said bears repeating even if it doesn't apply in your case.

 

However I failed to spot the clue in Problem 1 in your OP.  IMHO your mistake was in changing the name of your machine in Retrospect->Sources->Rename, instead of changing it in System Preferences->Sharing->Computer Name.  Although I did not mention it in this thread, I had tried changing the machine name in Retrospect and found it to be ineffective.  Assuming the machine is a client, Remove the machine as a Source first, make the name change in System Preferences (if that doesn't change the Client Name in the Status tab of your machine's Retrospect Client, you may have to stop and start the client), then Add it back as a Source and re-checkmark it in your script.

 

As currently programmed, Retrospect->Sources->Rename seems to be a snare and a delusion.  At best it is good for neatening the machine name for clarity purposes in the Retrospect Console.  It may have been more effective in Retrospect 5, which dealt with machines pre-OS X.

 

P.S.: Added parenthesized note about stopping and starting client to last sentence of second paragraph.

Link to comment
Share on other sites

The client machines start switching on at 7am, staggered by 5 minutes intervals from each other. The server machine then switches on at 7:20 am and runs the backup scripts.

I suggest getting in at 7 am and see for yourself what happens. Especially if the clients indeed starts up and is ready for backup at 7:20.

Link to comment
Share on other sites

For anyone that has this problem and finds this thread, first the solution, then the testing that we went through.

The problems:

1 - Changing a backup source's name from within Retrospect (11.5.3 (103)) stopped that source automatically backing up during a scheduled backup.

2 - A newly added iMac has never automatically backed up on a scheduled backup.

Note - Other machines are backed up successfully on the same scheduled backups and in the same script.

 

For both of the above problems, the backups can be successfully run manually from within the Retrospect application.

 

The solution:

We have had to add the Retrospect.app (Application) to the start up items on the server. This solves the problem and both machines now backup automatically on the old scheduled scripts.

 

 

Testing:

We got up at 7am and watched what happened. There sources in question failed to backup, error -530.

 

We made a temporary script and added small folders from both problem machines. This script runs successfully when manually started. We then set a schedule for 10 minutes later and the scheduled script ran successfully. We then altered the schedule to run another 10 minutes later and restarted all the machines, this time the scripts failed, error -530 for the two problem machines.

 

It was therefore obvious that the Retrospect application needed to be open to successfully backup these two sources. We added the Retrospect app to the Login Items on the server. The next morning the normal scripts ran perfectly and the problem machines backed up succesfully.

 

So, in our case, whilst you should not need the Retrospect application open (you should only need the Retrospect Engine to be installed) this is no longer the case. I remind you that other scripts and sources were happily backing up without the app being a Login Item and this setup has been in place for years, working perfectly.

 

I surmise that something such as an Apple security update applied to the server has affected the OSX permissions system and how Retrospect 11.5.3 works with it.

 

 

We would like to know from someone at Retrospect if this is a known issue and if it has been fixed in Retrospect 12?

 

 

I hope this post helps other people.

 

Tom.

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.

Guest
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.

Loading...
×
×
  • Create New...