PSA: How to fix "Deferred" scheduled script executions

[DavidHertzberg]

I noticed a couple of days ago that all my script executions scheduled after 1 January were showing in Activities as "Deferred".  I figured this was Retrospect Inc.'s New Year's gift to me, so I looked in the cumulative Retrospect Mac Release Notes.  Lo and behold, Under Console for 15.6.0.125 there's "Activities: Fixed issue with scheduled activities showing up as "Deferred" (#7670)" .  As we all should know by now, 15.6.0.125 was a "bad release"—so you'll want to download and install the 15.6.1.105 "backup server" instead.

I've done this and tested it.  It fixes the "Deferred" problem, but I've kept my Mac Client at 14.1.  That's because last summer, when—at the request of Retrospect engineering—I ran an extra-logging version of the 15.0 Engine and Client to see if they'd fixed my -530 bugs, that combination of versions actually made my -530 problems worse.  So I reverted to 14.6.0 for the Engine and 14.1 for the Client.  I should also point out that, at the suggestion of henry-in-florida, I've recently switched the Console Sources definition of my MacBook Pro's Client to using Subnet broadcast instead of Multicast.  That seems to have eliminated everything except -530 Bug 1, for which I developed a work-around nearly two years ago.

For those who don't want to upgrade, here's an old post to the Mac 8 Forum that describes an alternate way to fix the problem.

[Mayoff]

A bug exists in all older Macintosh versions of Retrospect that will make scripts appear deferred.  This is a cosmetic only bug that is fixed in 15.6.1. No backups should fail to run because of this issue. 

You can either ignore the defer warnings or you can upgrade to 15.6.1 and the issue will not appear. http://www.retrospect.com/upgrade or http://www.retrospect.com/updates

 

[oslomike]

Hello Mayoff,

Just wanted to chime in here because I too am suddenly experiencing the "deferred" bug. I have an older version of Retrospect v8 that has been working for years without this bug, but suddenly all my scripts get deferred and DO NOT run. I have a long list of deferred scripts in the "scheduled" window. Just checked again this morning and I confirmed that normal scripts stopped running. Any ideas on how I can get the program back to normal again?

[DavidHertzberg]

oslomike,

You're not going to get a response from the head of Retrospect Technical Support by posting here.  He lost his phone-answering assistant over a year ago, and is ordinarily too busy to look at these Forums.  His post above yours is one of several extraordinary ones, made because several administrators running older versions of Retrospect Mac are reporting this problem.  His statement that "no backups should fail to run because of this issue" may only apply to Retrospect Mac 12.5 to 14.6, or it may be entirely wrong.  However you could try deleting the schedules for all your scripts, and adding new ones.  Please let us know how that works out.

If that doesn't work, please read this post to find a suggestion by me.

[oslomike]

Hi David,

Thanks for the reply. I understand. There must be something else wrong because I can't even delete the scheduled scripts that are set as deferred. I will do as you suggest and make all new scripts and see if that helps.

Thanks again!

[DavidHertzberg]

39 minutes ago, oslomike said:

Hi David,

Thanks for the reply. I understand. There must be something else wrong because I can't even delete the scheduled scripts that are set as deferred. I will do as you suggest and make all new scripts and see if that helps.

Thanks again!

If you want to try that, go ahead.  I suggested trying to delete the schedules for your existing scripts, not the scripts themselves.  However if you can't even delete the scripts, it sounds as if Retrospect Mac 8 has been permanently disabled by a bug caused by the year changing to 2019.  Again, to avoid repeating myself, I suggest you read this post for my suggestions on your two possible courses of action.  In case you don't know, to read a blue-underlined link in one Forums post to another post, run your mouse pointer over the blue-underlined words; your mouse pointer icon should turn into a hand with a pointing finger, and you "click the mouse" to follow the link.

[oslomike]

David,

Thanks for the detailed email. I've tried deleting the Schedules of the scripts, but not the scripts themselves, and that didn't change anything. Scripts still don't run. Under the Activities Tab/Scheduled, there are a bunch of scheduled scripts that are all set to deferred, which seem to be stuck. You can't delete them. Is the same issue others are having? BTW, I'm on Retrospect v8. I know it's old but it's been reliable up until now. I'll have to dig deeper.

[DavidHertzberg]

oslomike,

Given that you still can't get your scripts to run, there's no point in your digging deeper.  You're going to have to spend some money "upgrading" to a version of Retrospect Mac that doesn't have this Console bug.  (I have never worked for Retrospect Inc., or its predecessor companies; I'm just repeating that sad fact to a fellow administrator.)

Right now the only version you can "upgrade" to is Retrospect Mac 15.  That will be charged at the full purchase price, not at the upgrade price, because your version of Retrospect Mac is older than version 14.  Maybe you can talk someone at Retrospect Sales into giving you the upgrade price for the license of whatever Edition you need. 

I've also submitted a Support Request, suggesting that Retrospect Inc. offer everybody with Retrospect Mac 11 or earlier a cheap price for an upgrade to the appropriate Edition of Retrospect 12.5.  If you had that, then—with the free upgrade to a new version of the Retrospect Mac 14.6 Console offered in this Knowledge Base article—your scripts would start running again.  But you'd need a license code for Retrospect Mac 12.5, because the license code for Retrospect Mac 8 won't work for the Retrospect Mac 12.5 Engine.

BTW, if "digging deeper" means looking at buying a different Macintosh client-server backup application, I predict you won't be happy with what you find.  AFAIK the only other two such applications (whose names I can't mention on these Forums) that can run their "backup server" on a Mac are much more expensive.

[oslomike]

Thanks David,

I’ll  see about an “upgrade.” Thanks for the help. 

[Mayoff]

My own update to this:

This is a cosmetic issue fixed in Retrospect 15.6. You can upgrade at http://www.retrospect.com/upgrade or you can download a patch for older versions of Retrospect at https://www.retrospect.com/en/support/kb/deferred_date_on_mac. The patch is free.

If you find the issue is not cosmetic for you, please contact support directly because you are experiencing a totally different issue. 

[oslomike]

Thanks Mayoff,

I appreciate you taking the time to reply. I understand that you don't have the resources to hang out on the forums. In my case, I'm running version 8 and it seems my "deferred" problem is basically the same, but actually a lot more involved than what you're describing. I'm experiencing that all scheduled scirpts get set to deferred and then stop working altogether. Is there a patch for v8? The KB page didn't adress any versions as far back as v8.

[DavidHertzberg]

oslomike,

Here's why and how to file a Support Case. In the Support Case I already filed on this bug, which Retrospect Tech Support claims is "cosmetic", I included a link to your previous post in this thread.  However having you independently file a Support Case should help persuade R.T.S. to do further testing.

 

[oslomike]

David,

Thanks I'll do this now.

 

[DavidHertzberg]

Contrary to what the head of Retrospect Tech Support has said above, the issue that causes a script to appear deferred as of January 1st is definitely not just a cosmetic issue. The deferred scripts, when they run, do not backup "client" machines, only local drives.

I did a fairly definitive test last night using my "backup server" Mac Pro, which is a 2010 "cheesegrater" model containing 3 drives. Disregarding the late original owner's inherited "Macintosh HD" HDD (on which I do a Recycle backup once a week in case one of his students wants to work with the contents), there is the "Macintosh HD New" HDD—a boot drive containing the Retrospect Mac 14.6.0 Engine and Console—which I have not updated to 14.6.2 with the patch, and there is the "Macintosh HD SSD" SSD—a boot drive onto which last Friday evening I copied the contents of "Macintosh HD New" and then installed the Retrospect Mac 15.6.1.105 Engine and Console. The scripts on both drives use the same Media Sets, stored in the default Catalogs folder on "Macintosh HD New".

Last night, having first booted my MacBook Pro "client" machine, I changed System Preferences->Startup Disk to make the Mac Pro boot from "Macintosh HD New" and restarted. I immediately Paused the "NoOp MBP Sat. Backup" script which had begun to run (two days after it was scheduled), did a Locate of my MBP, and then Stopped the "NoOp MBP Sat. Backup" script; this is the procedure which I have developed to avoid -530 errors for the MBP. The "Sat. Backup" script immediately began to run (two days after it was scheduled), but got -530 errors for both the MBP and my Digital Audio G4 "client" (which I had not bothered to boot) before going on to do a specified Recycle backup of both the local (original owner's) "Macintosh HD" and "Macintosh HD New" HDDs.

I then changed System Preferences->Startup Disk to make the Mac Pro boot from "Macintosh HD SSD" and restarted. I immediately Paused the "NoOp Sun.-Fri. Backup" script which had begun to run (3.5 hours after it was scheduled), did a Locate of my MBP, and then Stopped the "NoOp Sun.-Fri. Backup" script. The "Sun.-Fri. Backup" script immediately began to run (3.5 hours after it was scheduled), and ran OK—although it did a Recycle backup of the MBP rather than the specified No Media Action backup.

The 4 paragraphs above are copied from a Support Case I have just submitted, slightly edited to underline words that had to be given leading and trailing underscores in the Support Case system—which does not allow rich text.

My results are consistent with what boegly reported here, which is that "It appears to not be cosmetic. No scripts are running. I have a number of clients using this version." In the OP for that thread,  boegly says his/her clients are running "Version 14.6.1 on MacOS 10.12.6".

P.S.: See this post below; i turns out that the issue is cosmetic, and fixable with Console 14.6.2, for Retrospect Mac 12.5-14.6—unless you have the -530 Bug problem I had.  Sorry for testing that indicated otherwise.

Edited January 11, 2019 by DavidHertzberg
Added P.S. saying the issue _is_ cosmetic and fixable for _normal_ 12.5-14.6

[geryoei]

On 1/3/2019 at 4:41 PM, Mayoff said:

A bug exists in all older Macintosh versions of Retrospect that will make scripts appear deferred.  This is a cosmetic only bug that is fixed in 15.6.1. No backups should fail to run because of this issue. 

You can either ignore the defer warnings or you can upgrade to 15.6.1 and the issue will not appear. http://www.retrospect.com/upgrade or http://www.retrospect.com/updates

 

Sorry it is NOT cosmetic as I can not identify the backup date within the backup sets anymore. You try to force me to a paid upgrade (which has bugs as well) instead of fixing an obvious bug. Really? 

[swednet]

Yep, I can only verify that a client of mine running version 8 has the same problem, and it is NOT "cosmetic", no scripts run whatsoever. . .

[DavidHertzberg]

geryoei and swednet,

As the Knowledge Base article says, the free Console fix only works for Retrospect Mac versions 12.5, 13, and 14.  Thus swednet, who is running version 8, must upgrade; I don't know about geryoei, because he/she hasn't stated his/her version.  I don't think that a perpetual license for an older version of Retrospect—Retrospect Mac 12 was released in March 2015 IIRC—obligates Retrospect Inc. to fix a bug that just showed up in January 2019 for versions that are more than 4 years old.

However I feel your pain.  That's why I submitted a Support Case suggesting that Retrospect Inc. offer license codes for the appropriate Edition of version 12.5 at a price less than the new-purchase price for the appropriate Edition of Retrospect Mac 15.  That Support Case has been marked Closed.  I therefore suggest that you speak to your local Retrospect Inc. salesperson/agent; my experience is that the salespeople are anxious to make a deal that will bring in some revenue—and can put pressure on Retrospect Inc. Product Management to make that deal possible.

I just negotiated a deal in which I belatedly paid for a Desktop Edition license for Retrospect Mac 15, but—since I was forced to upgrade from version 14.6.0 by this bug—the deal will give me a free upgrade to version 16 even though I am purchasing almost a month earlier than the 1 February 2019 cutoff date.

P.S.: I'm assuming that Retrospect 16.0 will be released sometime in March 2019, since early March has been the usual date for the first release of previous major versions.  In case any of you folks have failed to realize it, Retrospect Inc. Engineering is under tremendous pressure to get several "go big or go home" features out of beta.  That explains the 15.5 and 15.6.0 "bad releases", and probably the hasty claim that the "Deferred" bug is only a "cosmetic" problem for Retrospect 12.5 and up.

 

Edited January 9, 2019 by DavidHertzberg
Product Mgmt. would have to allow the cut-price deal for upgrading to 12.5; added P.S.

[DavidHertzberg]

To keep the third paragraph of the above post short enough to avoid exceeding the approximately-20-line limit for Support Case entries, I left out a mention that two subsequent attempts to run the "NoOp Sun.-Fri. Backup" script under the 14.6.0 Engine and Console resulted in -530 errors, even though in the same execution on the Mac Pro I had previously done a successful Locate of my MacBook Pro "client". The same was true today, after I updated the Console on "Macintosh HD New" to the 14.6.2 "fix".

So today I changed System Preferences->Startup Disk to make the Mac Pro boot from "Macintosh HD SSD" and restarted. I then submitted the "NoOp Sun.-Fri. Backup" script and the "Sun.-Fri. Backup" script. After the "NoOp Sun.-Fri. Backup" script passed the 3-minute mark still "Finding ...", I Paused it, did a Locate of my MBP "client", and Stopped the "NoOp Sun.-Fri. Backup" run. "Sun.-Fri. Backup" immediately started and ran OK.

This seems to show that Retrospect Mac 15.6.1.105 doesn't have -530 Bug 2 (see this post in another thread) any worse than it did before, on the same "backup server" machine where the pre-"fixed" and "fixed" Retrospect Mac 14.6.0 runs worse than it did before. Thus I'm sticking with Retrospect Mac 15.6.1.105 as my production version, and I've just paid for an upgrade license code (I was given a permanent one last summer, because I needed it to run R.T.S.-requested tests for a supposed -530 bug fix).

[DavidHertzberg]

Hold everything, folks!  What I reported in this post above seems to have been an artifact of my -530-bug-prone "backup server".  Very early yesterday morning I received the following response from Retrospect Tech Support:

Quote

I just tried to reproduce the issue you experienced on an OS X 10.11.6 (El Capitan), I can close console, restart Engine, reboot. Activity threads keep to the set value with version 15.6.1.105.  I might try  later on a 10.12.x but I don't think that will change anything.

It can be a corrupted Config, could you try the below and reboot before restart the Engine.

Stop Retrospect Engine in MAC OS System Preferences

Browse to the main Retrospect folder: Library/Application Support/Retrospect/

Check for the configXX.dat and configXX.bak. 

Move the 2 files (you might have only .dat file) to your Desktop

Start Retrospect Engine and Launch Retrospect. (reboot first)

Thank you for using Retrospect,
Marc Retrospect Support

I saw the e-mail on my MacBook Pro "client" in the study and—in moving rapidly back and forth between the study and the bedroom—mentally converted it into a reply to my Support Case about the "Deferred" bug.  I also mentally converted "configXX.bak" into "configs.xml", based on a vague memory of what Scillonian had said in this 2016 post.  Moving both files to my "Macintosh HD SSD" SSD's desktop wiped out all the saved info from my copy of Retrospect Mac 15.6.1.105, so I spent several hours recreating the "client" machines and scripts and Media Sets (for which I trickily used the existing "1-..." folders from my two at-home portable backup HDDs—the third one being in my bank safe deposit box). 

When I had done all that yesterday afternoon,  I ran tests of my "NoOp Sun.-Fri. Backup" and "Sun.-Fri. Backup" scripts.  They all ran OK, even when I booted the "backup server" a half-hour after the scheduled time for the test scripts.  So causing Retrospect to recreate config80.dat and configs.xml fixed—at least temporarily—my -530 Bug 1 and -530 Bug 2 problems for Retrospect Mac 15.6.1.105.

This morning I repeated the same testing procedure on my "Macintosh HD New" HDD, except—belatedly realizing my mistake—I only moved config80.dat to the desktop.  The equivalent tests again all ran OK, proving that the "Deferred" error is indeed a "cosmetic" one—one that is fixed by installing the Retrospect Mac 14.6.2 Console.  Sorry about that, administrators and Retrospect Inc. personnel.

BTW the fixes to my -530 Bug 1 and -530 Bug 2 may not last, because my -530 Bug 3 is essentially a corruption of some Retrospect configuration file after a couple of weeks—causing my -530 Bug 1 and/or -530 Bug 2 to reappear.

[Lindsay Robertson]

[Edit: This is sorted now, see my reply below]

I have version 15.6.1 and I'm also seeing this issue. Its real AND its cosmetic.

I checked my server tis morning, and found nothing had backed up fro a week.

All scripts were showing "deferred" and all individual backup clients were showing "deferred".

I ran a couple of manual backups and they went fine.

Rebooted the server, then checked the scripts and clients, and they're now showing activity at the time that they were showing deferred, and proactive scripts are going again.

 

I'm highly suspicious and will watch it like a hawk for the next few days. 

Edited February 3, 2020 by Lindsay Robertson
Showing the solution to the problem

[Lindsay Robertson]

Oops. I had upgraded the server, but my remote console was still on 15.0. 

My mistake. 

Now that Ive sorted that it appears to be behaving.