Jump to content

Proactive backups - waking up and staying awake (error -559)


Recommended Posts

I do proactive backups of my laptops. I have a set of OS X (El Capitan) laptops connected to a local WLAN and a OS X (El Capitan) backup computer connected to LAN. I have set my laptops to "Wake for Wi-Fi network access" and my sources are set up to "Enable Wake-on-LAN".

 

My problem is that unattended backups always time out with error message: Scanning incomplete, error -559 (network connection timeout)

 

Backups work if I'm actually using or logged in to the laptop when backup begins.

 

Is Retrospect supposed to be able to wake up the laptops if they are in sleep mode? What causes the backup to timeout after a while?

  • Like 2
Link to comment
Share on other sites

See my bug report here.  My report was for scheduled scripts, but it references an item which is now on page 329 in the Retrospect Windows 11 User's Guide.  Maybe whoever wrote that manual knew something that never made it into the Retrospect Mac User's Guide—namely an admission that Enable Wake-on-LAN does not in fact work even for proactive backups (which I don't use).

Link to comment
Share on other sites

See my bug report here.  My report was for scheduled scripts, but it references an item which is now on page 329 in the Retrospect Windows 11 User's Guide.  Maybe whoever wrote that manual knew something that never made it into the Retrospect Mac User's Guide—namely an admission that Enable Wake-on-LAN does not in fact work even for proactive backups (which I don't use).

 

The "item which is now on page 329 in the Retrospect Windows 11 User's Guide" was on page 328 (right-hand column) in the Retrospect Windows 7.5 User's Guide.  It seems that Enable Wake-on-LAN was known not to work for Macs at least as early as 2011.  OTOH I happen to have saved a Retro-Talk e-mail announcing the beta of Retrospect Mac 8 in early 2009.  Some of the new features it announces are "Advanced network client support with support for multiple network interfaces and a wake-on-LAN feature [my emphasis] to wake sleeping computers for backup, reducing overall energy expenditure".

 

Here's one hypothesis: Wake-on-LAN never worked for Macs, in the Retrospect Mac 8 client or thereafter, but Retrospect Inc. left the option in the app and in the Mac User's Guide in hopes that they could fix it in a subsequent release.  I have recapped the history of Retrospect Mac 8 in the first 4 sentences of the third paragraph in this post; I will not repeat that history here to avoid causing pain to certain readers.

 

Here's another hypothesis: Wake-on-LAN did work for Macs in the Retrospect Mac 8 client, but it stopped working by 2011 because of Apple changes to Mac OS X.  At that point Retrospect Inc. didn't have the heart to remove the option either from the app or from the Mac User's Guide.

 

Either way it didn't work for me in a test on a scheduled script in February 2016.

 

The -559 error is not related to Wake on LAN in any way. If the client was sleeping, you would see a 530 error or other error.

 

The -559 error is a client connection issue that we can help you with by contacting support directly.

 

 

You're right for scheduled scripts, Mayoff; my test in February 2016 produced -535 errors for my two sleeping clients.

 

However, since I don't do proactive backup, I don't know what would happen if one connected a sleeping client to a LAN.  Maybe it would get a -559 error from a proactive script even if the connection were totally OK.

 

So, Mayoff, it's time for you to come clean.  Does Wake-on-LAN work to backup a sleeping Mac client for Mac proactive scripts?  Feel free to run a test.

Link to comment
Share on other sites

  • 2 weeks later...

Wake on Lan works for Proactive backup and traditional backup scripts. If it isn't working for you, please contact support directly. It is supported with Macintosh and Windows clients.

 

 

As a result of tests made this afternoon, I have resolved this problem—which has bedeviled the Retrospect community for years—into three different basic cases for scheduled scripts.  In the first case, when a Mac client is put to sleep via the Apple Menu, Wake-On-LAN fails with a -519 error.   In the second case, when a Mac laptop client is put to sleep via a special keyboard combination on the laptop keyboard, Wake-On-LAN works.  In the third case, when a Mac laptop client is put to sleep via the same special keyboard combination on an attached keyboard, the script  goes into a Retry loop until it fails with a -559 connection error.

 

The special keyboard combination is Shift-Control-PowerButton or Shift-Control-MediaEject.  To understand how I came to know about and be using this combination, see the fourth and sixth paragraphs of this post in the Ars Technica Other Hardware forum.  To understand the hardware problem behind it, follow the link in the first paragraph in the linked-to post—which is in a thread that so far mostly describes my experiences with ATEN's CS782DP KeyboardVideoMouse switch.  I was putting my MacBook Pro to sleep via the Apple Menu until early May, when I started using the special keyboard combination; that explains this bug report in mid-February.  Note that I had updated the Retrospect Client on my Macbook Pro from 12.0.2 (116) to 12.5.0.111 just before running the test described in the bug report, which may explain why I got -535 errors instead of -519 errors on the February test.

 

I am running Retrospect Mac 12.5 on my Mac Pro "backup server", but I reverted to version 12.0.2 (116) of the Retrospect Client on my MBP to try to avoid -530 errors on scheduled backups.  Both my MBP and my Mac Pro are booting OS X 10.10.5.

 

Since I don't use proactive scripts, I can't speak definitely as to whether and under what circumstances they work with Wake-on-LAN.  However I can easily imagine a user bringing a laptop to the office already put to sleep with the special combination on its own keyboard, cabling the laptop to the office LAN, and having a proactive script work to successfully back it up.

 
From the cases described in the first paragraph above, the client Wake-on-LAN problem sounds like an interaction between the Retrospect Mac Client software and Mac OS X 10.  Note that on the February test of my "Sat. Backup" Recycle Media Set script, with both my MBP and my Digital Audio G4 (which boots OS X 10.3.9) put to sleep via the Apple Menu, both the MBP and the G4 got -535 errors.
Link to comment
Share on other sites

The plot thickens slightly.  Just a few minutes ago I put my MacBook Pro to sleep using the special keyboard combination on the laptop keyboard, then booted my Mac Pro "backup server" (Retrospect automatically starts).  The "Sun.Fri. Backup" script got a -505 (backup client reserved) error.  I pressed Shift on the attached USB keyboard to awaken the MBP, logged in, and stopped-started the Retrospect Client—which IME is slightly faster than rebooting the MBP to get rid of a -505.  I then manually started the "Sun.Fri. Backup" script, which ran OK.

 

FWIW I have occasionally noticed that, when I put my MacBook Pro to sleep using the special keyboard combination on the laptop keyboard, the MBP later turns out to be awake.

 

The MBP is an Early 2011 MacBook Pro.  Software is per the preceding post.

Link to comment
Share on other sites

Random -505 errors on clients is an issue we are investigating. In this case, it could have been a timing issue between when the machine woke up and when the client started and bound itself to the network adapter. Most users will not get that error.

 

The Wake on LAN works by Retrospect sending a magic packet to the client machine. The Magic Packet should then wake the machine and allow a backup.

Link to comment
Share on other sites

Random -505 errors on clients is an issue we are investigating. In this case, it could have been a timing issue between when the machine woke up and when the client started and bound itself to the network adapter. Most users will not get that error.

 

The Wake on LAN works by Retrospect sending a magic packet to the client machine. The Magic Packet should then wake the machine and allow a backup.

 

 

I'd love for not-Waking-on-LAN to be a peculiarity of my MacBook Pro hardware and/or its OS.  However color me sceptical.

 

Mayoff, the key word for me in "The Magic Packet should then wake the machine and allow a backup" is should.  How recently has Retrospect Inc. tested that it does do this?  On what versions of Mac OS X?  With what versions of client hardware?  With scheduled scripts or only with proactive scripts?  Were the clients put to sleep via the Apple Menu, or only from the keyboard?

 

Note that Apple itself has gotten sloppy with testing recently, which is why I have never upgraded either of my two modern Macs to OS X 10.11 El Capitan.  And Apple has a lot more money than Retrospect Inc..

 

And what of Retrospect Windows, as discussed in my first paragraph of post #5 in this thread?  Is a Retrospect Windows 11 "backup server" still incapable of sending a Magic Packet to an OS X client?

 

Finally, for completeness, how about my Digital Audio G4 (mentioned in the last paragraph of post #7, but whose test is linked-to in my fourth paragraph in post #5 ) booted under OS X 10.3?  Obviously it runs the legacy Mac PowerPC 6.3.029 Retrospect Client.  Is that Client incapable of acting on a Magic Packet, because Apple's last PowerPC Mac came out 3 years before Retrospect Mac 8?

Link to comment
Share on other sites

It just occurred to me that Magic Packet might not just be a Retrospect, or even Mac OS X, term.  So I did a Google search, and found it in the Wikipedia article on Wake-on-LAN.  Since that section of the article mentions the "target computer's 48-bit MAC [Media Access Control] address", it reminded me that both my client computers have static DHCP addresses set on the router—done at the direction of A. of Retrospect Support back in July 2015 to make sure the "backup server" can find them (this is not mentioned in the Retrospect Mac 13 User's Guide, so I mention that in any post on these forums where it seems appropriate).

 

That in turn reminded me that I had done a Sources->Locate immediately after both of the first two cases described in the first paragraph of post#7 in this thread.  In both cases, put to sleep via the Apple Menu and put to sleep via a special keyboard combination on the laptop keyboard, Locate failed.  I did Locate after the tests because, when I ran the test for the second case first—expecting it to fail, it unexpectedly succeeded (I then ran Locate after the test for the first case, because my experience has shown that running Locate before a script usually causes it to succeed when it would otherwise fail with a -530 error.) 

 

Thinking of this just now caused me to wonder if some setting in my Internet-facing router might inhibit Magic Packets, thus inhibiting Retrospect Wake-from-LAN.  I do not have any software firewalls on any of my LAN computers, nor do I have an internal router on my LAN.

Link to comment
Share on other sites

Received this reply to my case from Retrospect Support this morning (13 September):

 

"Agent Response: 

The Wake on LAN feature is tested with every Retrospect product release. Retrospect 11/13 was released in March and we have really not had any significant reports of trouble with the feature. In fact, I think you are probably the only customer who has been directly asking support about it in the last few months (outside of how to turn the options on). When testing sleep, we typically test after the machine has automatically gone to sleep, since that is what the majority of customers experience. 

Wake on LAN is supported on Macintosh and Windows with normal backup scripts and proactive backup scripts.  The option must be turned on in the client properties screen and turned on inside the script options. 

Wake on LAN is not supported with the 6.3 client version.
"

 

I have both those options on.  I am using Retrospect Mac 12.5, with version 12.0.2 (116) of the Retrospect Client on my MacBook Pro; I mentioned both those version numbers in my Support case—which is pretty much a copy of my posts in this thread.

 

The only thing I can speculate at this point is that a machine automatically going to sleep might not have the same effect as putting it to Sleep on the Apple menu.  In my MBP's System Preferences->Energy  Saver, I have both Computer Sleep and Display Sleep set to Never;  I also have Wake for Network Access checkmarked in that same Preferences pane.

Link to comment
Share on other sites

Received this reply to my case from Retrospect Support this morning (13 September):

 

"Agent Response: 

The Wake on LAN feature is tested with every Retrospect product release. Retrospect 11/13 was released in March and we have really not had any significant reports of trouble with the feature. In fact, I think you are probably the only customer who has been directly asking support about it in the last few months (outside of how to turn the options on). When testing sleep, we typically test after the machine has automatically gone to sleep, since that is what the majority of customers experience. 

 

....

...."

 

I have both those options on.  I am using Retrospect Mac 12.5, with version 12.0.2 (116) of the Retrospect Client on my MacBook Pro; I mentioned both those version numbers in my Support case—which is pretty much a copy of my posts in this thread.

 

The only thing I can speculate at this point is that a machine automatically going to sleep might not have the same effect as putting it to Sleep on the Apple menu.  In my MBP's System Preferences->Energy  Saver, I have both Computer Sleep and Display Sleep set to Never;  I also have Wake for Network Access checkmarked in that same Preferences pane.

 

 

Last night in my MacBook Pro's System Preferences->Energy  Saver, I changed both Computer Sleep and Display Sleep to 1 hour, and left it running. Early this morning, after verifying by there being no longer any light under the KB that the MBP had gone to sleep, I booted my Mac Pro "backup server".  The scheduled "Sun.-Fri. Backup" got the the following log:

 

Normal backup using Sun.-Fri. Backup at 9/14/16, 3:36:55 AM

    To Backup Set Media Set White...

   

    9/14/16 3:37:17 AM: Connected to David’s MacBook Pro

    *  Resolved container David’s MacBook Pro to 1 volumes:

    Macintosh HD on David’s MacBook Pro

    -  9/14/16 3:36:55 AM: Copying Macintosh HD on David’s MacBook Pro

    Using Instant Scan

    9/14/16 3:38:17 AM: Found: 626898 files, 150652 folders, 46.6 GB

    9/14/16 3:39:21 AM: Finished matching

    soccRecv: recv failed, error 60

    9/14/16 3:39:46 AM: Copying: 1760 files (3.6 GB) and 0 hard links

    !Trouble reading files, error -559 (network connection timeout)

    9/14/16 3:39:53 AM: Execution incomplete

    Remaining: 1,760 files, 3.6 GB

    Completed: 0 files, 0 B

    Performance: 0 MB/minute

    Duration: 00:02:58 (00:02:49 idle/loading/preparing)

 

I then pressed the Shift key on the attached USB KB to wake up the MBP, and manually ran "Sun.-Fri. Backup" again to get the following log:

 

Normal backup using Sun.-Fri. Backup at 9/14/16, 3:44:32 AM

    To Backup Set Media Set White...

    Can't access backup client David’s MacBook Pro, error -505 (backup client reserved)

    9/14/16 3:44:54 AM: Execution incomplete

 

I noticed that there was an automatically repeated updating notice for Adobe Reader (after I had already updated it) on the MBP's monitor.  

 

I then stopped-started Retrospect Client on the MBP, and manually ran "Sun.-Fri. Backup" again.  This time it ran fine.

 

I will reboot my MBP now to see if that gets rid of the Adobe message—which has caused -505 trouble in the past. I will then retry the same test overnight.

Link to comment
Share on other sites

Last night in my MacBook Pro's System Preferences->Energy  Saver, I changed both Computer Sleep and Display Sleep to 1 hour, and left it running. Early this morning, after verifying by there being no longer any light under the KB that the MBP had gone to sleep, I booted my Mac Pro "backup server".  The scheduled "Sun.-Fri. Backup" got the the following log:

 

Normal backup using Sun.-Fri. Backup at 9/14/16, 3:36:55 AM

    To Backup Set Media Set White...

   

    9/14/16 3:37:17 AM: Connected to David’s MacBook Pro

    *  Resolved container David’s MacBook Pro to 1 volumes:

    Macintosh HD on David’s MacBook Pro

    -  9/14/16 3:36:55 AM: Copying Macintosh HD on David’s MacBook Pro

    Using Instant Scan

    9/14/16 3:38:17 AM: Found: 626898 files, 150652 folders, 46.6 GB

    9/14/16 3:39:21 AM: Finished matching

    soccRecv: recv failed, error 60

    9/14/16 3:39:46 AM: Copying: 1760 files (3.6 GB) and 0 hard links

    !Trouble reading files, error -559 (network connection timeout)

    9/14/16 3:39:53 AM: Execution incomplete

    ....

 

I then pressed the Shift key on the attached USB KB to wake up the MBP, and manually ran "Sun.-Fri. Backup" again to get the following log:

 

Normal backup using Sun.-Fri. Backup at 9/14/16, 3:44:32 AM

    To Backup Set Media Set White...

    Can't access backup client David’s MacBook Pro, error -505 (backup client reserved)

    9/14/16 3:44:54 AM: Execution incomplete

 

I noticed that there was an automatically repeated updating notice for Adobe Reader (after I had already updated it) on the MBP's monitor.  

 

....

 

I will reboot my MBP now to see if that gets rid of the Adobe message—which has caused -505 trouble in the past. I will then retry the same test overnight.

 

 

The automatically repeated updating notice, which continued even after I had done the update,  turned out to be from Adobe Flash Player Install Manager.app.  I deleted the install app.  I then reran the same tests early this morning.  I got a -519 error on the first test, but the second test ran fine.

 

My guess is that, on my MBP, letting the computer go to sleep after 1 hour temporarily disables the Retrospect Client.  This may have something to do with my now having an ATEN CS782DP KVM switch, but I didn't have that switch in February.

Link to comment
Share on other sites

Received this reply to my case's Additional Notes—which were the contents of my early-morning-15-September post above—from Retrospect Support this morning (15 September):

 

"Agent Response: 

We do have open bugs for users getting -559 and 505 errors at random times during backup, but for most users they are not related to Wake on LAN operations.  I will pass your experience onto our engineers so it is included in the bug report for those errors."

 

I'm going to retry the same tests overnight, but with my ATEN CS782DP KeyboardMouseVideo switch disconnected from my MacBook Pro—to see if that makes any difference.

Link to comment
Share on other sites

The automatically repeated updating notice, which continued even after I had done the update,  turned out to be from Adobe Flash Player Install Manager.app.  I deleted the install app.  I then reran the same tests early this morning.  I got a -519 error on the first test, but the second test ran fine.

 

My guess is that, on my MBP, letting the computer go to sleep after 1 hour temporarily disables the Retrospect Client.  This may have something to do with my now having an ATEN CS782DP KVM switch, but I didn't have that switch in February.

 

 

After disconnecting the ATEN CS782DP KeyboardVideoMouse switch from my MacBook Pro, repeated the same two tests early this morning.  Got exactly the same results: "Sun.-Fri. Backup" script got a -519 error (which would be a -530 error after #6080 fix) with the MBP having gone to sleep after one hour per revised System Preferences->Energy Saver options, but ran fine with the MBP awake.

 

So—after eliminating oddities such as simultaneous Adobe updater messages—the results for Wake-on-LAN for my MBP seem to be: works fine when a Mac laptop client is put to sleep via a special keyboard combination on the laptop keyboardfails with a -519 error (which would be a -530 error after #6080 fix) when a Mac client automatically goes to sleep per System Preferences->Energy Saver optionsfails with a -519 error (which would be a -530 error after #6080 fix) when a Mac client is put to sleep via the Apple Menu

 

To me that sounds as if presumably greater OS X involvement in the second and third cases is what causes Wake-on-LAN to fail on my MBP.  That may not apply to other peoples' Mac clients with their own installations of OS X.

 

P.S.: Just noticed (on 18 September) a bug fix for Retrospect Mac 13.0.1 "Fixed issue where clients not found on network incorrectly reported as error -519 instead of -530 (#6080)"; put in parenthetical note after every mention of -519 in this post—no doubt you should mentally do the same for previous posts in this thread.

Link to comment
Share on other sites

  • 2 weeks later...

....

 

So ... the results for Wake-on-LAN for my MBP seem to be: works fine when a Mac laptop client is put to sleep via a special keyboard combination on the laptop keyboardfails with a -519 error (which would be a -530 error after #6080 fix) when a Mac client automatically goes to sleep per System Preferences->Energy Saver optionsfails with a -519 error (which would be a -530 error after #6080 fix) when a Mac client is put to sleep via the Apple Menu

 

To me that sounds as if presumably greater OS X involvement in the second and third cases is what causes Wake-on-LAN to fail on my MBP.  That may not apply to other peoples' Mac clients with their own installations of OS X.

 

P.S.: Just noticed (on 18 September) a bug fix for Retrospect Mac 13.0.1 "Fixed issue where clients not found on network incorrectly reported as error -519 instead of -530 (#6080)"; put in parenthetical note after every mention of -519 in this post—no doubt you should mentally do the same for previous posts in this thread.

 

 

The special keyboard combination in the first sentence of the first quoted paragraph is not really applicable.  It turns out Shift-Control-PowerButton or Shift-Control-MediaEject doesn't really put a Mac to sleep; it only puts the built-in display on a Mac laptop to sleep.  It looks like either Barry misunderstood me back in May, or I didn't make it clear that I wanted to put my MBP to sleep.  I believed Barry because he's a second-level Apple Support guy, but also because the combination he gave me causes the lights behind the MBP's built-in KB to go out and the Sleep light to come on—which seemed to me to indicate the computer has gone to sleep.

 
I only found out differently because someone made a post 27 September on an Ars Technica Mac Ach thread that said some keyboard shortcuts have been eliminated in macOS 10.12.  I replied with a post expressing concern about whether Shift-Control-MediaEject would continue to put my MBP to sleep, and was told that that keyboard shortcut doesn't do what I thought it did.  I confirmed that by looking at the Apple Knowledge Base article on keyboard shortcuts (which I had previously been unable to find via the Apple Menu) the replying post linked to, and also by phoning Apple Support—from whom I learned that the lights behind the keyboard are linked to the built-in display rather than the HDD.
 
I've learned of a substitute workaround that seems to work for tower Macs (and maybe iMacs) as well as notebook Macs.  The workaround is to push the Power button on a computer one time after the CS782DP KVM switch has already been switched to the other computer.  I tested this on my 2010 Mac Pro tower—to verify that pushing the Power button once puts the Mac Pro to sleep, as well as on my Early 2011 MacBook Pro—to verify that pushing the Power button after the CS782DP has already been switched doesn't inhibit my LED Cinema Display from showing the G4's screen.
 
However last night (28 September) I determined that Wake-on-LAN by the Mac Pro "backup server" also doesn't work (a -519 error, which would be a -530 error after the #6080 fix) if my MBP client has been put to sleep by pushing the keyboard Power button once, which means that pushing that button does something more than what Ctrl+Shift+Eject on the MBP's keyboard does.  The Retrospect incremental backup I did this morning (29 September a.m.) confirmed that by backing up a sleepimage file; I remember it did backup that file starting in February when I began using the Sleep option on the Apple Menu, but it hasn't backed it up since I started using Ctrl+Shift+Eject in May.
 
The bottom line is that Wake-on-LAN doesn't work at all for my MBP client, running the Retrospect 12.0 client under OS X 10.10.5 Yosemite, from my Mac Pro running Retrospect 12.5 under OS X 10.10.5.  This may be a peculiarity of my Retrospect and OS X installations, but from other users' reports I don't think I'm the only one for whom this is the case.
Link to comment
Share on other sites

Having yesterday evening added the contents of my post above as an Additional Note to my Retrospect Support Case, I received the following e-mail from Mayoff this morning:

 

"Dear David,

Retrospect Agent Reply can be found below.
 

 

Agent Response:

>The bottom line is that _Wake-on-LAN doesn't work at all_ for my MBP client, running the Retrospect 12.0 client under OS X 10.10.5 Yosemite, from my Mac Pro running Retrospect 12.5 under OS X 10.10.5. This may be a peculiarity of my Retrospect and OS X installations, but from other users' reports I don't think I'm the only one for whom this is the case.

Thank you for the feedback. Our QA team has found results that are similar to your own experiences and we are continuing to investigate the issues so they can be addressed in a future release.

Please let us know if you have any additional questions,
The Retrospect Support Team

 

...."

 

Need I say more?

 

Or let me put it another way: Is there anyone for whom Retrospect Wake-on-LAN does work?

Link to comment
Share on other sites

  • 2 years later...

I didn't use the Wake On LAN checkbox and in my case the Deep Sleeping client still doesn't wake up in the latest (15.6[125] Client). Since Mojave came out there doesn't seem to be a way to have the CPU run 24x7 while allowing the screen sleeps. Which makes coping with the non-fixed issue of error-559 impossible to work around. Comments? See my posting about this similar issue in the newest version of Client. 

Link to comment
Share on other sites

On my MacBook Mojave test machine, screen sleeping/CPU working works just the same as always -- tick the box to "Prevent computer from sleeping..." in Energy Saver's "Power Adapter" tab, leave "Wake for network access" and "Enable Power Nap..." untucked (since we don't need them), screen will eventually go black but computer is still available over ssh, sharing, etc.

What machine(s) are you using? I might have something around I can try and duplicate on.

Link to comment
Share on other sites

  • 4 weeks later...

henry-in-florida,

You should look at the cumulative Release Notes.  For 15.1 they say :  "Mac Client: Fixed issue where client did not prevent macOS from going to sleep during backup (#7273)".  Also for 15.6.1.105, an emergency release you may not have upgraded to, they say: "Remote Backup: Fixed issue where remote backup connection was incorrectly closed (#7735)".

I'm pretty sure you are not using Version 15's new Remote Backup capability, but the 15.6.1.105 fix for #7735 may also have fixed your problem.  Try installing it, and file a Support Case if your problem is still not fixed.

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