waiting for backup infrastructure resources / repository

[pirx]

Hi,

I'm currently running our first round of full backups (~1000 VM's, 200TB, ~20 jobs, 9.5U1, 2x 100TB NetApp SMB SOBR), I don't start all jobs at once, only 3-4 jobs in parallel. Now I often see that jobs are waiting at 0% process and "Resource not ready: Backup repository" message in status view. I'm not sure why the job is waiting, I've seen this when 2 jobs were started, one was running backing up just one VM, the other was waiting on backup repository.

At the moment three jobs are using one repository.

1. running for 21h, one VM of 88 is waiting on repository, 87 were already backed up
2. running for 12h, 13 of 64 VM's are currently running, the others already finished
3. incr. started at the same time as job 2., status 0%, all VM's waiting on repository

The SOBR extent is set to 20 concurrent tasks, all 4 proxies are set to 20 concurrent tasks. I've enabled IO control and see throttling, but even when I disable it, the waiting job does not start. I'm not sure what the problem with the repository is. At the moment there some backups running but the other day the repository was not stressed so much, only one VM was backed up and the other job waiting.

How can I get more information what the limiting factor is?

[pirx]

Hm, I think it is related to the number of vDisks. The currently backed up VM's have ~50 vDisks. But this does not explain why one job yesterday was blocking the other, this was a backup of a VCSA vCenter with 11 vDisks, but not > 20.

[tdewin]

Well it is difficult to say why it is hanging without looking at the logs. A VMDK backup does indeed count as a task but also remember that there are other processes (like merging) that also count as a task on the repository.

There is a file called RTS.ResourceUsage.log (%programdata%\veeam\backup) which could give you a clue on resource usage but for deeper inspection, you would need to check other logs which support can assist you with

[pirx]

The last entry in RTS.ResourceUsage.log is from 19.12.2016.