Hello,
I tried to calculate the CPU/RAM resources for my VMware environment.
When I follow the VBR user guide and the BP Veeam, I troubled by the rule from the BP “1 repository core per 3 proxy cores” because there is no mention of the tasks limitation in relation to this rule.
I worked with the following information:
Proxy:
• 1 CPU = 2 tasks (user guide = BP Veeam)
• 1 CPU = 2 GB RAM (user guide = BP Veeam)
Repository:
• 1 CPU = 2 tasks (user guide)
• 1 CPU = 2 GB RAM (user guide)
• 1 repository CPU per 3 proxy CPU (BP Veeam)
• 1 CPU = 4 GB RAM (BP Veeam) I do not follow this rule
For example for an all-in-one server, I want 6 concurrent tasks for the proxy role.
For the Proxy role, I can set CPU/RAM resources without difficulty.
If I apply the rule 3 proxy CPU / 1 repo CPU repo, I have the following result.
So I should limit the concurrent task for the repository role to 2 for a VM with 6 VMDK.
VMware Backup Proxy :
- Tasks = 6
- CPU = 3 (6 / 2 )
- RAM = 6
Backup Repository:
- Tasks = 2
- CPU = 1 (3 / 1)
- RAM = 2
I guess I will be limited by the repository with 4 pending tasks for the proxy?
VBR 12 set the option “use per-machine backup files” for the repository role by default.
My understanding and that this option change:
• Backup Chain Formats : a separate backup file for every machine in the job
• How the repository tasks are managed (job vs VM disk)
If I understand correctly, this difference is essential for task management and therefore for the CPU/RAM resources of the repository role. In this case, the "3 proxy processors / 1 repository processor" rule makes no sense?
Task Limitation for Backup Repositories
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).
Would it be better to have the same concurrent task limit for both roles and allocate resources accordingly?
Note: I know each role need minimum CPU/RAM resources and I know the bandwidth impact the performance.
I read the user guide, BP and the forum but the product has evolved and perhaps the answers have too.
vmware-vsphere-f24/repository-tasks-cal ... 73244.html
https://helpcenter.veeam.com/docs/backu ... ml?ver=120
veeam-backup-replication-f2/concurrent- ... 62605.html
-
- Lurker
- Posts: 2
- Liked: 1 time
- Joined: May 12, 2025 2:12 pm
- Full Name: Stephan KROMAREK
- Contact:
-
- Veeam Software
- Posts: 2644
- Liked: 612 times
- Joined: Jun 28, 2016 12:12 pm
- Contact:
Re: Concurrent tasks Proxy and Repository
Hi StephKT, welcome to the forums.
While the Best Practices Guide is useful for seeing how things work in the field, but the official sizing guidelines to follow are those from the User Guide System Requirements and Concurrent Tasks sections.
The main rule of thumb is "no more than 2 concurrent tasks per 1 cpu core" as per the User Guide, and you can potentially exceed this, but it may result in a negative impact on your backup and restore operations depending on the server load at the time.
I would start by working through the scenario with our Veeam Calculators, as they specifically are designed to help you understand the compute power necessary based on the workload you mean to protect and the desired backup window. Based on that, you can decide on the infrastructure composition (e.g., many proxies or a single powerful proxy).
Your understanding on Per-VM backups is mostly correct -- this option primarily changes how the backups are managed and offers quite a few features that non-perVM backups cannot utilize as well as having some impact on the inline deduplication and compression ratios, but the sizing of the proxy/repository is not so much affected by PerVM backups -- the sizing is driven by the workload you need to process and your backup window.
I'm not sure of the basis for the 3:1 rule, but I don't think it's intended as a ratio for your concurrent tasks and more a comparison of how far each role can be pushed per core. If you set 6 proxy tasks but the repo is allowed only 2 tasks, then you will only have 2 concurrent tasks running at a given time, as the scheduler will not assign more tasks to the repo once it already has 2 set.
PerVM is the default for some time now and a lot of functionality is included by using it, so I would plan around using PerVM; give the User Guide and Calculator links above a try and if you have questions on the proposed sizing, share your results and we can comment further.
While the Best Practices Guide is useful for seeing how things work in the field, but the official sizing guidelines to follow are those from the User Guide System Requirements and Concurrent Tasks sections.
The main rule of thumb is "no more than 2 concurrent tasks per 1 cpu core" as per the User Guide, and you can potentially exceed this, but it may result in a negative impact on your backup and restore operations depending on the server load at the time.
I would start by working through the scenario with our Veeam Calculators, as they specifically are designed to help you understand the compute power necessary based on the workload you mean to protect and the desired backup window. Based on that, you can decide on the infrastructure composition (e.g., many proxies or a single powerful proxy).
Your understanding on Per-VM backups is mostly correct -- this option primarily changes how the backups are managed and offers quite a few features that non-perVM backups cannot utilize as well as having some impact on the inline deduplication and compression ratios, but the sizing of the proxy/repository is not so much affected by PerVM backups -- the sizing is driven by the workload you need to process and your backup window.
I'm not sure of the basis for the 3:1 rule, but I don't think it's intended as a ratio for your concurrent tasks and more a comparison of how far each role can be pushed per core. If you set 6 proxy tasks but the repo is allowed only 2 tasks, then you will only have 2 concurrent tasks running at a given time, as the scheduler will not assign more tasks to the repo once it already has 2 set.
PerVM is the default for some time now and a lot of functionality is included by using it, so I would plan around using PerVM; give the User Guide and Calculator links above a try and if you have questions on the proposed sizing, share your results and we can comment further.
David Domask | Product Management: Principal Analyst
-
- Lurker
- Posts: 2
- Liked: 1 time
- Joined: May 12, 2025 2:12 pm
- Full Name: Stephan KROMAREK
- Contact:
Re: Concurrent tasks Proxy and Repository
Thanks David,
I tried the Veeam calculators, but I wasn't entirely satisfied.
I'll use PerVM and continue to follow the main rule "no more than 2 concurrent tasks per 1 cpu core" for proxy and repository roles.
I tried the Veeam calculators, but I wasn't entirely satisfied.
I'll use PerVM and continue to follow the main rule "no more than 2 concurrent tasks per 1 cpu core" for proxy and repository roles.
-
- Veeam Software
- Posts: 2644
- Liked: 612 times
- Joined: Jun 28, 2016 12:12 pm
- Contact:
Re: Concurrent tasks Proxy and Repository
You're very welcome. Regarding the calculators, if there are challenges with them, feel free to leave feedback on our community forums for the Calculators.
And yes, no more than 2 is a good rule of thumb. Just remember this part from the User Guide for all-in-one setups as you had mentioned it:
https://helpcenter.veeam.com/docs/backu ... tallations
And yes, no more than 2 is a good rule of thumb. Just remember this part from the User Guide for all-in-one setups as you had mentioned it:
https://helpcenter.veeam.com/docs/backu ... tallations
So the roles are cumulative, just you can subtract 2 GB of memory resources from the total cumulative system requirements once all added up for an all-in-one.All-in-One Installations
For all-in-one installations, you can subtract 2 GB of memory resources from each but one role. These 2 GB are allotted to the OS itself, assuming each component is installed on the dedicated server.
David Domask | Product Management: Principal Analyst
Who is online
Users browsing this forum: Bing [Bot] and 58 guests