How to properly size concurrent task to backup repository?

[hod928]

Hey everyone,

I recently got back from VeeamOn 2022 and it has me taking a hard look at how we do things today with our Veeam ecosystem...Maybe my wheels are turning with a little too much excitement! I think we do it pretty well today but after talking to those around me and seeing the sessions I know we can do better!

How does someone go about sizing how many concurrent jobs to run against a backup repository? And if you set say 8 concurrent task on all the repos does that mean it will try to run 56 concurrent jobs task (I have 7 repos total set to 8 concurrent task each).

Our backups today are going to a physical Linux Hardened Repository with 7 repositories attached. The hardened repository server is an old R730 host we decommed so the Linux server has 32 cores and 512GB of Ram. Monitoring the physical server with PRTG we are only putting like a 5% load on the server during backup time. In front of the Linux repository we have 3 virtual (2 windows and 1 Linux) backup proxies each with 8vcpu and 16GB of ram currently set to do 8 task each. Our backups are being written to a VNX5600 with a mixture of 7.2K and 10K drives.

So I know today with the way we have the proxies setup and the repo set up at times we have the "waiting for backup repository availability " message in our jobs. How does one correctly size how many concurrent task you can do at one time?

[jorgedlcruz]

Hello,
Thanks for sharing such a great detail about your environment.
So far, I think it is alright in terms of resources, I would recommend you to use our best practices where you can find some formulas:

• https://bp.veeam.com/vbr/2_Design_Struc ... ositories/[/ist]
  
  In terms of CPU and RAM consumption sounds okay, lot of margin as I can see by the PRTG report, my bet is that either networking, or perhaps read/write on the Repo might be the bottleneck, and what you can scale more anyways.
  
  You say that your Physical Repo, writes the data to the VNX? Is this FC, iSCSI?
  
  Sometimes is better having the waiting for tasks from the repo, and do less concurrent than faster, rather than more concurrent but struggle with read/writes, or other resources, not on your case on CPU and RAM.
  
  Please look into the BP page, make your formulas, and try to adjust accordingly, if required. But give an extra monitor to bandwidth, and read writes to the final target as that might be the limit.
  
  Hope it helps