Jump to content
jhg

Queueing Jobs Manually

Recommended Posts

If I start Job A which uses BackupSet-1 and then attempt to start Job B, which also writes to BackupSet-1, Retrospect complains that the backup set is in use and refuses to queue the job to wait for the backup set to become available.

However, if I edit Job B and add a one-time schedule entry to start 1 minute from now, while Job A is still running, Retrospect dutifully queues Job B and runs it when Job A finishes.

This is probably a feature request.  In the first situation, where I attempt to run a job for which a resource is currently in use, I would like for Retrospect to queue the job just the way it does when the job is started by the scheduler instead of manually.

Share this post


Link to post
Share on other sites

jhg,

If you want to submit an enhancement request, here's why and how to do it.

However I suspect that Retrospect Tech Support's answer will be along the lines of "it's already the way we'd like it to be".  Their explanation would be that anyone who submits two Immediate operations whose destination is the same Backup Set is more likely than not to have made an error.  Starting with version 8.0 in 2009, Retrospect Mac did away with Immediate operations; clicking the Backup button in Retrospect Mac generates a script scheduled for the current date-time with whatever source-destination-etc. you specify.  A few weeks ago, doing an experiment for other purposes, IIRC I clicked the Run button in the Scripts panel to schedule the same script twice with exactly the same source-destination-etc..  Retrospect Mac 16 wouldn't submit the results of my second Run click, but would do so if I added  a Repeat Never schedule of the same script 2 minutes later.  That smells to me as if the engineers took the trouble to convert the Retrospect Windows behavior you don't like for a dramatically-revised GUI.  If I paraphrased H. L. Mencken to say "Nobody ever went broke underestimating the competence of backup administrators", I suspect the engineers would say they already have the equivalent statement on a wall plaque in Walnut Creek CA.;)

Share this post


Link to post
Share on other sites
On 8/22/2019 at 12:08 PM, DavidHertzberg said:

jhg,

If you want to submit an enhancement request, here's why and how to do it.

However I suspect that Retrospect Tech Support's answer will be along the lines of "it's already the way we'd like it to be".  Their explanation would be that anyone who submits two Immediate operations whose destination is the same Backup Set is more likely than not to have made an error. 

"We'd like it to be."  David, you are probably right, but it you are, that's appalling.  Retrospect exists to solve customer problems.  One of those problems is the need to do what the OP described.  In effect, "set it and forget it."  I have run into the same problem many times, and Retrospect's behavior here is annoying.  The OP definitely needs to submit an enhancement request that includes a clear rationale for why he wants this new or changed feature.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×