Question About Repositories and Max Concurrent Tasks

[HJAdams123]

Hello and Good Day Veeam Community...

Question about Veeam Repositories and and what is considered a task for a repository....

I understand the processing of a disk is considered a task for a repository. My question is, is a backup file merge process considered a task as well? How many backup merge processes can a repository do at once?

I have two jobs that I would like to send to the same repository. Both jobs are forever incrementals with a 30 day restore point setting, and each jobs typically takes about an hour to merge the oldest increment to the full. If I configure both to use the same repository, and all disk processing is done for both jobs, will it only do the merge process for one job and make the other one wait, or will it go ahead and do them both concurrently? (assume the backup repository has a 4 task concurrent limit configured)

-Harold

[foggy]

Hi Harold, each backup chain merge process takes a separate repository task. So, if you have per-VM chains enabled for repository, each VM will take a separate task for the merge (since each VM has a separate backup chain), if per-VM is disabled - a single task will be required for the entire job merge process. There are no limitations on the number of concurrent merges, so theoretically, all the repository slots may be taken by them (this can be controlled by ingestion rate limits).

[HJAdams123]

Thanks foggy, thats what I needed to know.

-Harold

[mkretzer]

I found this to be one of the reasons we cannot use per-VM chains. Concurrency limits effectively lead to all the tasks beeing taken by merges and other backups could not run...

It would be better to have limits per type of action (merge, backup and so on).

[mkretzer]

Hello,

we have a remote repository which holds about 2000 VM backups copies with per-VM files from about 20 copy jobs. This runs quite well in day to day business.
Problem is that when there are merges or compactions the repo allocates all ressources to these kind of tasks in jobs with alot of VMs. That means that while such a operation is running no network transfer is going on which is bad because we only have a small window where we can use the full bandwith between sites.
Best option would be a limitation of tasks slots per type of operation. For example for us it is not importand if a compaction takes 24 hours or 2 hours so we could allocate that kind of operation much less resources.

Perhaps there is something new in U3?

Markus

[foggy]

Hi Markus, thanks for repeating your request. There's nothing new in this regard in the latest update though.