Limiting task usage of a single job or VM in a job?

[pirx]

Hi,

I've the following setup at a location:

- a backup repository with concurrent tasks set to 8 (sadly a QNAP with 16 drives and SMB)
- a virtual proxy with concurrent tasks set to 6
- one backup job, backing up ~20 VM's with 10 TB
- a second job with one monster VM with 13 vDisks and 12 TB

Problem is when a full backup for this monster VM is running is occupies all available task slots. As this backup is running very long (a week...) the slots are occupied most of the time and the other job with smaller VM's is waiting on resources. No inc backup for days.

I can configure concurrent tasks on repository and proxy, but not for a job or VM. How can I prevent that one job is blocking the other one for such a long time? Adding much more concurrent task doesn't make sense with this storage and virtual Proxy doesn't make sense.

I've found several other forum posts about similar issues.

veeam-backup-replication-f2/per-vm-or-p ... 46046.html
veeam-backup-replication-f2/sobr-per-job-t46069.html

Is it planned to enhance this behavior, make things more configurable? I've created another post last week regarding concurrent task handling veeam-backup-replication-f2/concurrent- ... 74450.html

I'm still impressed how Veeam can add more and more fancy stuff, but some basic features (IMHO) are still missing.

[Dima P.]

Hello pirx,

Thank you for your feedback! Possibly you could add a dedicated repository (could be on the same QNAP) + dedicated proxy but with less amount of concurrent tasks specifically to process this huge workload?

[pirx]

Sure, but what would I do if this is not just one monster VM? Adding more and more repositories? I think there has to be a way to control this in Veeam. I've seen other backup products that have this kind of features. I really like Veeam and it has a lot or benefits but it's still missing some features that I've used a decade ago

[foggy]

The way it currently works ensures the VM for which the backup has started is completed in the shortest time possible. Taking some task slots off it to give to other VMs will mean a longer backup for this VM, which is not something that is typically desired. I would say that a backup taking a week is not normal and you should rather work on increasing the setup performance. I guess the bottleneck here is the target (QNAP), right?

[pirx]

The bottleneck is the target and in a perfect world we would have everywhere the right storage, but we haven't. It's accepted that the backup of this VM takes very long, as this is an active full an only happening once a month. The problem is, that I can't prioritize the other job. This would help a lot because this job would then be finished in a couple of hours.

[foggy]

Well, there's the job priority functionality but it will not take away already assigned slots to give them to the newly started job even if it has a higher priority. So you need to 'reserve' some slots for the quick jobs and this can be achieved by configuring a dedicated proxy/repository.