Chained jobs

[perjonsson1960]

Folks,

I have understood that it is not Veeam's recommendation to chain jobs, thus it is better to use fixed start times.
My question is why? And if it is not recommended, why do you even have that option?

PJ

[vmtech123]

Sometimes it's required. Maybe one job has to back up before another. I have encountered issues backing up 2 clustered servers at the same time when the snapshots go at the same time. The stun causes a blip. I'll do one after the other.

The reason they advise against it because if you have 10 jobs chained, and the first one fails, all 10 jobs fail. If they were all scheduled the last 9 would still run.
If you schedule your jobs to run at the same time they will, and if you run out of task slots, the jobs will sit there and wait and run anyways.

I still use a few chained jobs for my file servers to run one after another. They are monsters and I can't guess how long they will take. This way I don't overpower my SAN, but it keeps my windows short.

[perjonsson1960]

Ah... I see. Well, it's not good if all jobs coming after a failed job also fail... Thank you!

PJ

[foggy]

Here's a bit more on the consequences of job chaining.

[AndrewAdvnetsol]

The reason they advise against it because if you have 10 jobs chained, and the first one fails, all 10 jobs fail. If they were all scheduled the last 9 would still run.

I don't believe that is an accurate statement. If a chain job fails the remain jobs will still run after the failed job. The only time a job would not run in a chain is because you disabled a job in your chain or changed the order of jobs in the chain.

That being said is the best practice to have each job run on its own. Example: Job 1 starts at 10:00 PM, Job 2 starts at 10:01 PM, Job 3 starts at 10:02 PM, etc. https://bp.veeam.com/vbr/4_Operations/O ... b-chaining. I am currently still using job chains for my jobs. This is mostly just carry over from legacy practices and lack of resources. I am working to move my jobs way from chaining as I now have better resources.

[BackupBytesTim]

Example: Job 1 starts at 10:00 PM, Job 2 starts at 10:01 PM, Job 3 starts at 10:02 PM, etc.

I've seen that suggestion before, as a solution to "chain" jobs without actually chaining them, first job finishes and then Veeam will start the next job automatically. However that always seemed like a bad way to do that to me. The tediousness of manually scheduling a bunch of jobs 1 minute apart seems like a poor user experience, and then if you ever have to change the schedule it takes considerable time compared to if you only have 1 actual schedule to change.

I have no customers with the 100s of TB of data being backed up like some companies have, and for those companies I certainly understand the need to carefully balance the load on the servers efficiently to avoid clogging up one server or one network connection with a ridiculous amount of data, but for the vast majority of my customers, which are almost all small businesses, they don't care a whole lot about what time of day backups occur, just so long as they occur sometime each day. And for some they find once every couple of days acceptable. Personally I'd hate to lose 2 days of business data, or even 1 day, so I personally think everyone should be on hourly backups, or continuous backups for that matter. But I seem to be an outlier in that opinion, so ultimately we just let everything run on individual schedules and let Veeam handle balancing things with manually specified limits on how many jobs can be running simultaneously.

[vmtech123]

I back up 100's of TB's of data

Previously, chained jobs would stop if the first failed, maybe that has changed.

How about you delete a job in the middle, the rest stop, Or if you disable one because it has an issue and you are troubleshooting. Do you really want to modify the schedule of the next job in the chain or possibly forget?

You also lose the concurrency which really shortens your backup window allowing you to backup more frequently.

The only reason you are chaining jobs is to save resources right? Well set your proxy and repo limits appropriately. Veeam will queue up the jobs for you and run when they are available.

The "Manual" backup chain isn't great either. If I schedule my jobs at say, 1:30, 2:00, 2:30, 3:00 etc. If something finishes early, My Veeam servers are sitting there doing nothing when they could be working backing up data.

There are really no valid reasons for this method anymore except 1 I can think of.

- You have some extremally large servers. (lets say 50TB servers, and 10 of them)
- Synthetic operations take FOREVER on these beasts. Merges etc.
- 95% of the time, you can run a ton of concurrent tasks with no issues.
- 5% of the time, when dealing with these servers, and specific tasks run your SAN crawls to a halt.
- Take the Large servers, chain them, and have most of the other jobs run concurrently.

Ask me why I know this lol, I currently have some file servers still in this config. But that's not a Veeam issue. It's the old SAN

[SAFA_IT]

Chaining can be useful, but I had a case a while back where immutable backups were never expiring - after changing from chained to scheduled the backups worked as expected.
#05854805

[BackupBytesTim]

That's interesting, I'm curious if support had an explanation for what the problem was with that or if they did they usual "it's not broken anymore, so we're done" thing and didn't bother to figure out what was actually wrong with it?

Also curious if all of your chained jobs had the same relevant immutability settings or if maybe it could be that some backups were just not expiring until other chained jobs' backups were?

[SAFA_IT]

I think the theory of why scheduled worked but chained didn't developed during the support case. My issue was that I had one backup that was chained but was filling up the repository and never deleted anything and a separate chained backup copy to a hardened repository that was working as expected. The issue turned out to be fairly simple - the problem job had daily incrementals running in the evening and a synthetic on Saturday. The Friday incremental didn't always finish before midnight, so the synthetic didn't complete the chain to allow deletions.
So, it wasn't directly down to the chaining, just a consequence of the previous job running on a bit. The immutable backup copy job has always worked fine as a chained job, so I kept it chained, but I would set up any new job as scheduled - cleaning up a full hardened repository isn't a fun task.