Chained Jobs - Retry

[scottf99]

Hi. V10
I use the "After this job" schedule to essentially chain all my jobs together. Works well.
I had a single VM fail on one of the jobs. The job retried 3 times then failed and the next job ran. All good so far.
Next morning I fixed the issue with the VM and "Retry" the job.
The job ran successfully BUT then the following job started. This is illogical as the subsequent jobs ran successfully the night before and do not need to be run again.

If I "Start" a job I get asked if I also want to run the chained jobs. This should apply to "Retry"

[HannesK]

Hello,
in general: job chaining is not recommended. You can probably achieve the same by scheduling the jobs just after each other. Example

22:00
22:01
22:02
22:03

But you are bringing up a valid point. There were changes in V10 and the documentation does not reflect the behavior you see (I also reproduced it)

I will check and come back on this

thanks again for reporting,
Hannes

[JPMS]

Is there any update on this? I've also experienced this in v10 and it didn't happen in v9.5

[HannesK]

yes, it's confirmed as an issue. I was just waiting until I get response when it will be fixed.

Edit: we will try with the next patch update, but no guarantee that it will make it.

[acatic]

I face the same issue with v10. Now I have to remember to disable the subsequent job before retrying a prior failed one.
The subsequent scheduling has been a blessing for me over the past couple years. I don't want defined start times for each job. I want resources committed to one job at one time for maximum efficiency, and I want the next job to start immediately after the prior one finishes, for the shortest backup window. This also allows me to plan for any infrastructure work by simply disabling one job and not all of them, and not having to wait for all of them to finish or stain my records with a 'failure' by having to stop running jobs.
Looking forward to the patch!

[foggy]

I want resources committed to one job at one time for maximum efficiency, and I want the next job to start immediately after the prior one finishes, for the shortest backup window.

This is what actually happens when you start the jobs with some short intervals one after another. In general, the job that starts first gets priority for resources. Of course, there are many factors like the total number of snapshots per datastore, proxy task slots, repository task slots, etc., but again, in general, assuming all the proper resources are available, they are assigned to the first job.

[cnwi.cschissler]

This is extremely frustrating. Even if I disable a subsequent job, run a retry and wait for it to finish, as soon as I re-enable the subsequent job, it starts running anyway.

Then if I stop that one, the next one in the chain starts. The only way I can get it to stop is to restart the entire Veeam server, and I shouldn't have to punch my server in the head just to get it to behave and retry a single failed VM.

Scratch that - even after a restart the jobs insisted on kicking off again.

This really needs to be fixed.

[foggy]

Hi Conrad, is there any specific reason why you're using job chaining instead of the automatic resource scheduling?

[eric.fuller]

As for autoscheduling resources, I cannot speak for him but we run jobs by chaining them due to running almost 40 jobs nightly all linked/chained (backups, replication, etc). If someone dumps a 100gb SQL database to a server I don't want that job to run over it's alloted "time frame" and cause issues with the NAS we back up to (70tb that also has other access to it at night). I want it to run, have full access and then when it's DONE kick off the next job. It's what I like and don't plan to change anytime soon (maybe someday!).

This issue is a bug in the v10. Apparently it is effecting a lot of people so I would say it is a production bug. Per the notes for v10 off the website -- https://helpcenter.veeam.com/docs/backu ... r=100#cont

And I quote....
NOTE:

If you start the initial job manually, Veeam Backup & Replication will offer you to start jobs chained to it as well. Click Yes to start the whole job chain or No to start only the first job in the chain.

...end quote.

That is currently broken. I speak for the rest of us in this thread, we would like it fixed... please... lol

[check4backup]

Hi,

I have many scheduled Jobs for Hyper-V VMs. Some jobs start when other jobs end (job chain). Bevor installing Veeam 10, Veeam asks for running subsequent jobs. Now the subsequent jobs run without asking. This could be a mistake.

greetings

[foggy]

Hi, do you mean a prompt when starting the job manually?

[check4backup]

Hi, yes the prompt (MessageBox yes/no). In Veeam 9.5 a MessageBox with the selection yes/no was displayed.

[foggy]

Thanks for the clarification. I'm merging this thread to another existing one regarding a similar matter. This is an already known issue that will be addressed in the next Veeam B&R update.

[Morc]

Just to warm this thread up, this is still a problem in V11. Running jobs manually after a failure or warning executes the whole chain even if No is selected on the "Run chained jobs" pop-up. Editing the dependent jobs prior to re-running to remove scheduling altogether does not stop this behaviour. Once the failed job completes and I re-edit the jobs to be ran after the job that just completed, they get executed immediately. I want a few higher data volume jobs to run first, on their own, parallel, so their backup is not dragging on due to other jobs tying up the available slots, and then run a number of small data also in parallel.

@foggy: can you provide a link to that other thread as I could not find it.

[foggy]

Hi Gábor, we've checked internally and the issue doesn't actually show up on the last version - in case you select 'No', the next chained job is not triggered. If you're seeing different behavior, please open a case with our technical support.

As for the other threat, then I meant this very one, where I merged the previous post related to this matter. Thanks!

[Morc]

Hi Foggy,

We're on 11.0.0.837. Is that what you checked, or some internal, yet to be released version? Although you'd not ask me to open a ticket, if it's a to be released version that works fine So should I open a case?

Morc

[foggy]

Yes, please.