Suggestion: Cancel all chained jobs

[ChrisFindley]

This is not an error, just a time saving request. When you manually start a job that has dependent jobs attached, Veeam asks if you want to run them as well: "Job has one or more other jobs chained to it. Would you like to execute chained jobs as well? Yes/No"

Nice idea, Veeam! But when you cancel a running job with dominoes queued up, Veeam doesn't ask if you want to cancel the series. So now there is a cascade of 'failures' from chasing these chained jobs down, canceling them one by one as Veeam forces them to start.

I tried disabling the next job in the chain before canceling the parent. It doesn't help. The first job cancels and everything is quiet. Wait 5 minutes then enable the disabled job, and Veeam kicks it off immediately!

Please add this dialogue and function when canceling a job: "Job has one or more other jobs chained to it. Would you like to cancel chained jobs as well? Yes/No" If they still have to say 'failed' for this functionality to work, I suppose that's better than the current click-fest. But it'd be best if they never even try to start.

Thanks for reading.

[foggy]

Hi Chris, thanks for the feedback, much appreciated. Just wanted to make sure you're aware of other consequences of job chaining - that is why they are not considered as best practice. Thanks!

[ChrisFindley]

Thank you for the link, foggy. I read the entire thread. I was not aware that chaining was a fringe-case tool. Honestly, I am not sure what to think, now. Recently, we had one backup job that handled all 120 of our VMs and it took days to complete, which isn't useful to us. I contacted Veeam support and they recommended I break the large job into 4 or 5 medium sized jobs to improve performance. I did so, and identified chaining as a helpful way to start what is still effectively 1 backup job. Total backup time dropped to around 8 hours, so that was a win. Now this thread from 2014 is saying I should start all my jobs at the same time and let B&R handle the resource allocation. You can hopefully see why this contradiction makes me skeptical. But I will give it a try and see if 5 medium jobs started simultaneously can handle resources better than 1 large job. If it takes longer, I will also try a staggered approach. In the linked thread, I saw a Veeam employee recommend 1 minute separation between jobs, and another saying 5 minutes might not be enough. Has Veeam narrowed down an optimal interval delay? (We have no requirements to start/finish our backups in any order)

[Gostev]

(We have no requirements to start/finish our backups in any order)

In that case, don't worry about having the delay at all, and just set them all to start at the same time. The linked thread is extremely old, as for a few years now the scheduler staggers jobs automatically to avoid putting peak loads on the backup server.

I am extremely curious though why splitting a single 120 VM job into 4 or 5 has improved the performance. Frankly, I have no explanation for this, because 120 VM is very little number by itself. Can you share the case number where the split was suggested? Perhaps I will be able to find the root cause mentioned in the internal comments. Thanks!

[ChrisFindley]

Case number sent via PM

[ChrisFindley]

Removed chained jobs and have a few backups now to examine from the weekend. I was pleasantly surprised to see total job duration is the same. I feel better kicking off everything at once in case one of my jobs spirals out of control. It also means my maintenance rotation schedule won't delay other jobs.
(Job 1 performs a health check on the first Monday of the month. Second Monday is a defrag. Job 2 does maintenance on those Tuesdays, etc.)

Thanks for the advice, Veeam.

[Gostev]

I am extremely curious though why splitting a single 120 VM job into 4 or 5 has improved the performance. Frankly, I have no explanation for this, because 120 VM is very little number by itself.

Just to follow up on this, after investigating debug logs, we found that the slow down after migration from NetApp to Synology target was caused by different repository settings (per-VM backup file chains was enabled on the old NetApp repository, but not on the new Synology repository). Creating multiple jobs was effectively a small step towards re-enabling per-VM backup file chains back - sort of