Hi LKLD,
Indeed I think there's a bit of confusion here on how Concurrent Tasks work.
There are unfortunately a few variables that need to be checked to give a complete answer on why your jobs are queuing at the moment, such as the parallel processing settings for the media pool, number of drives, other activities that may be occurring, etc.
It would be best to open a Support Case and allow support to review the logs from the Tape and Daily VM Backup job in order to properly review your configuration and understand the reason for the queuing. Use the 1st radio button to export logs from jobs and ctrl+click to select the tape and VM job. That should be enough for Support to start with.
Additionally, I'm guessing you have the option to Prevent this Job from being interrupted enabled; by default, if a Tape job has locked a resource a primary backup requires, the tape job will abort and surrender its lock to the primary job. With this option enabled, the primary job queues.
As mentioned before, a few too many variables to give you a complete answer on why in your environment the jobs are queuing in an undesirable way, so please do proceed with a Support case and let Support review the behavior.
Please share your case number once created. Thanks!
Indeed I think there's a bit of confusion here on how Concurrent Tasks work.
So depending on how you have the repository configured, a task is either a single job (legacy configuration) OR per VM disk for (true) per-VM backups (current default).The number of tasks that Veeam Backup & Replication creates during data protection or disaster recovery jobs depends on the type of backup chains stored on the backup repository:
For regular backup chains, Veeam Backup & Replication creates 1 task per job.
For per-machine backup chains, Veeam Backup & Replication creates 1 task per every VM disk (that is, a disk of a VM added to the job).
Synthetic operations performed in the backup repository (such as synthetic full backup, backup files merge and transformation) are also regarded as tasks. The number of tasks performed during these operations also depends on the type of backup chains stored on the backup repository:
For regular backup chains, Veeam Backup & Replication creates 1 task per job.
For per-machine backup chains, Veeam Backup & Replication creates 1 task per every VM chain (that is, every VM added to the job).
There are unfortunately a few variables that need to be checked to give a complete answer on why your jobs are queuing at the moment, such as the parallel processing settings for the media pool, number of drives, other activities that may be occurring, etc.
It would be best to open a Support Case and allow support to review the logs from the Tape and Daily VM Backup job in order to properly review your configuration and understand the reason for the queuing. Use the 1st radio button to export logs from jobs and ctrl+click to select the tape and VM job. That should be enough for Support to start with.
The Scheduler follows this Job Priority logic, and if the job priorities are equal based on the first two checks, StartTime is used to determine priority.If the daily backup job currently processed by the Backup-to-Tape job is effectively blocked (stuck on “initializing storage”), why doesn’t Veeam pause that job and instead start processing other daily backup jobs that are waiting? It seems inefficient that Veeam keeps trying to work on the blocked job instead of using available task slots to process other backup jobs that aren’t blocked.
Additionally, I'm guessing you have the option to Prevent this Job from being interrupted enabled; by default, if a Tape job has locked a resource a primary backup requires, the tape job will abort and surrender its lock to the primary job. With this option enabled, the primary job queues.
As mentioned before, a few too many variables to give you a complete answer on why in your environment the jobs are queuing in an undesirable way, so please do proceed with a Support case and let Support review the behavior.
Please share your case number once created. Thanks!
Statistics: Posted by david.domask — Jul 08, 2025 1:07 pm
