Don't start job if another job is running

Hello,

You could try reducing the number of concurrent tasks in the jobs/proxies/repositories to avoid overloading the network. 

As far as I know, Veeam does not provide a native way to insert pauses between scheduled jobs chained with the “run after” option. Once the previous job finishes, the next one starts immediately.

I would look at the schedule where you can run jobs after each other as noted by Matheus.  That is the easiest way to avoid conflicts as you can chain jobs so job 1 starts and when done job 2 goes, etc.  Otherwise, you need to look at the average time duration for jobs and try to manually schedule them with a time window in between.

There is no native way to insert a “pause period” between chained jobs as Matheus shared. I think your thinking like the same thing you can do with failed Jobs? You can configure a wait period between retries. Yeah..nothing in Veeam like this for chained Jobs.

What I do is just stagger my Jobs. And this is on the VBR server I use for just Backups. I have a 2nd VBR server I use for Replication, and I just configure those Repl Jobs outside of times when my Backups run. Replication Jobs should be less of a critical need than your Backups so should have more infrequent schedules than your Backups. For me also, Snapshotting is not that intrusive because my Backup Jobs use BfSS and so the VM snaps are fairly quick. For my Repl Jobs, snaps are obviously retained longer since I have to use hotadd.

That’s about the only way I know of to do what you want, other than suggestions already noted by Matheus & Chris.

This is the way. Build the Veeam environment wth the proper task limits so that it can't get overloaded no matter how many jobs are running. 

By default Veeam will only allow 4 active snapshots per VMware datastore, limiting how many snapshot can be open at any given time.

For more information on that, check out this page which talks about the active datastore snapshots limit as well as some other VMware tuning methods.

Would love to do that. But how/where? Haven’t found anything related in the job settings or options.

Task counts are part of the Proxy and Repository settings, not the job FYI.  So edit your Proxy or Repo and set the task counts there.

Thanks!! I will try to set this to one snapshot, and see what happens :-)

Ah...you mean Backup Proxies → Backup Proxy → Server → Max concurrent tasks?

And also Backup Repositories → Backups Drive → Repositories → Limit maximum concurrent tasks?

Thanks a lot, I will try that, this looks promising.

That is correct.

And FYI, the max snapshots per Datastore is a VMW limitation inherently...not realy Veeam. Keep us posted how it goes!

Yes those are the exact settings to change and try.

As mentioned, Reducing the number of concurrent tasks is your best bet. If there are no slots available, it will wait.  There is no setting to pause after a job is complete. Chains are another option to complete one job after another, but if your first job fails, they all fail. Veeam is set up for concurrency.  I often have many jobs running at once. Using the network throttle is a great way to not overload the bandwidth limits of your network.  Veeam will use what it is given so fast storage and network make things really nice. 

The real question and answer are, where is the bottleneck? Is it between Veeam and VMware, Proxy and Repo, storage? etc.

What is your current setup and networking? Adding a few fast network cards, a few IP addresses and direct connecting things is even an option if needed. I recommend fixing the issue as  once you get over 30 hours daily backups become an issue.  It’s nice to be able to back things up quickly. 

Also make sure it’s not using the VMware management port if you have 1Gb management in your servers as that can be VERY slow. 

I’ll end with this. If you ever need to do a mass restore, you will want to be restoring more than a few VM’s at a time.  This is often overlooked as restore time is actually more important than backup time when you are in a critical situation.