Veeam sizing for 500 to 2,000 VMs: proxies, repositories, transport modes and the backup window

Veeam sizing for 500 to 2,000 VMs: what sets the numbers

Veeam sizing for a large VMware estate starts from two inputs: the amount of source data the jobs read and the length of the backup window. Data divided by window gives the throughput the backup proxies must sustain, and Veeam’s Best Practice Guide converts that throughput into proxy cores, then proxy cores into repository cores and memory. The daily change rate sets the incremental load, while the full backups that read every VM from production storage usually set the peak.

Figures are from Veeam’s Best Practice Guide (bp.veeam.com) and the Help Center for Veeam Backup & Replication 13 (13.1 since 29 July 2026, per KB2680), read on 10 October 2026.

Veeam Best Practice Guide for Veeam Backup & Replication (bp.veeam.com, © 2025): vSphere proxy design, repository design, initial sizing recommendations and backup job storage pages; Veeam Data Platform 13 Recommended Maximums. Read on 10 October 2026.

Veeam proxy sizing: cores, tasks and memory

The guide gives throughput per core for a VMware backup proxy: 180 MB/s for full backups and 80 MB/s for incrementals on a virtual proxy writing to block storage, and 250 MB/s for both on a physical proxy. To object storage, the figures are 110 and 80 MB/s for a virtual proxy and 150 MB/s for a physical one.

A task processes one VM disk at a time. The guide recommends two proxy tasks per physical core or vCPU and up to 2 GB of RAM per core. Veeam’s backup job guidance notes that by default a proxy with eight CPU cores runs up to eight concurrent tasks, so two tasks per core means setting each proxy’s concurrent task limit above that default. The guide asks for at least two proxy servers per site, and replication jobs need proxy resources at the source and the target, which our comparison of Veeam replication, backup copy and Cloud Connect explains.

Version 13 can scan the backup stream with inline entropy analysis, which raises a malware detection event when encrypted data exceeds the sensitivity limits. In Veeam’s proxy test table, a virtual hot-add proxy with 8 vCPU and 16 GB RAM wrote active fulls to direct-attached block storage at 1,440 MB/s, and at 800 MB/s with the analysis enabled, while incrementals stayed at 640 MB/s. That is about 100 MB/s per vCPU for fulls with the scan on, the figure our example uses, and Veeam adds that production throughput may vary.

Veeam transport modes: direct storage access, hot-add and network mode

The Veeam Help Center lists three transport modes “starting from the most efficient”: direct storage access (Direct SAN, Direct NFS or storage integration), virtual appliance (hot-add) and network mode. Veeam recommends hot-add when the proxy runs as a VM; network mode works with any configuration but has, in Veeam’s words, “low data transfer speed”.

Veeam Help Center, Veeam Backup & Replication 13 user guide (Transport Modes, Direct Storage Access, Virtual Appliance Mode, Network Mode); Veeam BP guide, vSphere proxy build page; Veeam KB1681 (modified 3 August 2026); Broadcom, Best Practices for NBD Transport (24 January 2025).

Veeam’s KB1681 describes VMs on NFS 3.0 datastores that stall during snapshot removal when a hot-add proxy on another host processes their disks; the KB says this “was resolved in VMware ESXi 8.0 Update 2b”. It also points to Broadcom’s KB428200, a related stall on NFSv3 datastores with Changed Block Tracking that remains on later builds, and calls Direct NFS Access “the recommended solution”.

Broadcom recommends backing up 50 or fewer disks in parallel through each ESXi host, and since vSphere 7.0 hosts support a dedicated NBD network, the vSphere Backup NFC service of a VMkernel adapter.

Veeam repository sizing and scale-out backup repositories

For repository servers, Veeam’s guide recommends physical machines where possible and anti-affinity rules that keep virtual ones on different hosts. Its capacity assumptions are a data reduction of “usually 2:1 or more” and a typical daily change rate of 2 to 5 per cent, with database servers at up to 30 to 50 per cent in the worst case and about 10 per cent as the planning value where databases are a large share. It adds space for one-off full backups, and for backup chain transformation at least a full backup multiplied by 1.25; that reserve comes with the remark that these chain types are not recommended and that forward incremental with synthetic fulls is. Veeam’s build guide advises limiting volumes to 500 TB and not filling them “above 80 percent”.

XFS with block cloning keeps synthetic fulls and GFS points small, and a synthetic full is built inside the repository with “no impact on the source storage or production networks”, while an active full reads production again. Building such a repository with immutability is covered in our guide to the Veeam hardened repository.

A scale-out backup repository is, in Veeam’s words, “a repository system with horizontal scaling support for multi-tier storage of data”. One or more repositories form its performance tier, and object storage extends it as capacity and archive tiers. The guide calls the Data Locality placement policy “the recommended setting for most deployments”, and 10 Gb networks as the recommended minimum.

The capacity tier copies backups as soon as they are created, or moves inactive chains as they age out of the operational restore window; the offload session that moves them runs every 4 hours. Restores from the archive tier take longer than from the capacity tier. How long each tier keeps data is covered in our guide to backup retention and GFS, and whether the object storage copy counts as off-site in our article on the 3-2-1-1-0 backup rule.

Job layout by tier and the backup window

The guide gives a maximum recommended job size of 16 TB of source data for 1 MB blocks to a local target, and 64 TB with 4 MB blocks; a block size change takes effect only after an active full. Veeam’s recommended maximums for version 13, which Veeam calls “not hard limits”, are 5,000 VMs per job and 20,000 VMs per backup server.

1. Sort the VMs into tiers by RPO, and keep database servers apart, because of their change rate.
2. Within each tier, split jobs so that none exceeds the recommended source size for its block size.
3. Group VMs that share retention and repository, so that each job has one schedule and one target.
4. Stagger job starts by a minute instead of chaining jobs, as the guide advises, and let load balancing spread tasks over proxies and repositories.
5. Back up vCenter with its file-based backup as well, as our guide to vCenter backup and restore describes.

Worked example: Veeam sizing for about 800 VMs

This example is ours, with the guide’s formulas. It assumes 800 VMs with 120 TB of source data, virtual hot-add proxies writing to block storage, a daily change rate of 3 per cent, nightly incrementals in an 8-hour window, weekly synthetic fulls on XFS, 14 daily restore points, and a 24-hour window for the first full and any active full.

For the full backup, 120 TB is 125,829,120 MB; over 86,400 seconds that is about 1,456 MB/s, and at 180 MB/s per core the proxies need 9 cores, or 15 at about 100 MB/s with inline entropy analysis. The nightly increment of 3 per cent is about 3.6 TB, or 131 MB/s over 28,800 seconds, which needs 2 cores at 80 MB/s. If 20 TB of the 120 TB are database servers changing 30 per cent a night, the increment grows to about 9 TB and needs 5 cores.

Four virtual proxies with 4 vCPU and 8 GB RAM, the configuration in Veeam’s test table, give 16 cores and 32 tasks. With one proxy down, 12 cores still finish the full in about 16 hours, or about 29 hours with the inline scan. Sixteen proxy cores call for 6 repository cores and 24 GB of RAM. The backup server for 800 workloads falls in the guide’s row for 500 to 1,000: 24 vCPU and 32 GB RAM.

At 2:1 reduction, the full takes about 60 TB on disk and each nightly increment about 1.8 TB. With weekly synthetic fulls on XFS, 14 daily restore points keep up to about 20 days of increments, so the chain holds roughly 60 + 20 × 1.8 = 96 TB. An active full does not use Fast Clone, so space for one more full, as the guide asks for one-off fulls, brings this to about 156 TB, or about 195 TB of volume at no more than 80 per cent fill, before GFS points and any immutability period. With the database share above, the chain grows to about 150 TB. The guide’s 1.25 reserve for chain transformation (75 TB here) is left out, because the example uses the recommended mode. 120 TB at no more than 16 TB per job means at least 8 jobs. The guide expects about half of the source data on the link from proxy to repository, so a full spread over the 24-hour window sends about 730 MB/s, or 5.8 Gbit/s, and 10 GbE links carry it. At 2,000 VMs with the same profile, cores and capacity grow in proportion and the backup server moves to the next row.

The technical assessment in our cyber resilience service reviews backup along with infrastructure and access, and ends with a risk map and a prioritised action plan. Send us your VM count, source data and backup window through the form below.

Backup infrastructure outside the production directory

Veeam’s security best practice guide states that “a data protection system should not rely on the environment it is meant to protect in any way.” For the most secure deployment, it recommends adding the Veeam components to a management workgroup, or to a management domain in a separate directory forest with two-factor authentication on the administrative accounts. A backup server joined to production depends on the production domain controllers for console authentication and DNS, so a restore can stall when they are down.

Network segmentation, multi-factor authentication and privileged access management are part of our cyber resilience service. Tell us which directory your backup servers and proxies are joined to and who holds their administrator accounts.

Monitoring the backup window and job health

Watch each job’s duration against its window, because snapshot removal “significantly reduces the total IOPS that can be delivered by the VM” (KB1681), and users notice it in business hours. The job statistics in version 13 identify bottlenecks in the data transmission process, which shows whether to add proxy cores, repository disks or bandwidth. Route malware detection events from the inline scan to the security team, and schedule test restores of each tier, timed against the RTO.

What we do

Under our cyber resilience service, the team of our engineering partner Vixen.UNO delivers Veeam-based backup with regular test restores to verify backup integrity, on one contract with Eurokommerz. The technical assessment of security and backup also covers environments we did not build, and its price is fixed before work begins. For a second site, our disaster recovery service replicates virtual machines from a 15-minute interval via Veeam Cloud Connect to Baltneta’s Tier-3 data centres in Lithuania.

FAQ