Veeam Data Platform 13 Recommended Maximums

This document contains recommended maximums and an initial sizing reference for Veeam Data Platform components.

Recommended maximums define upper guidance for a single backup server. The initial sizing reference provides practical starting configurations sized for real-world workloads.

Recommended Maximums

This document outlines recommended and consistently regression tested maximums for Veeam Backup & Replication product configuration. These guidelines are designed to help with deployment planning and ensure optimal performance and stability.

While these are not hard limits and many existing Veeam deployments already go well beyond these numbers, exceeding these recommendations significantly may lead to decreased efficiency or potential performance issues.

Veeam Backup & Replication Server

Virtual Machines

• 20000 VMs per Veeam Backup & Replication server
• 5000 VMs per backup or backup copy job
• 1000 parallel backup tasks
• 750 simultaneously running backup or backup copy jobs
• 1000 parallel VMware Instant Recovery or Full VM Recovery sessions per Veeam Backup & Replication server
• 200 parallel VMware Instant Recovery sessions per vPowerNFS server

Veeam Agents

• 7500 Veeam Agents per Veeam Backup & Replication server
• 1000 Veeam Agents per protection group
• 1000 Veeam Agents per backup or backup copy job
• 500 parallel backup tasks
• 500 parallel backup copy tasks

Application Plug-ins

Veeam Plug-in for Microsoft SQL Server

• 2000 databases per Microsoft SQL server
• 150 database servers and 10000 databases per Veeam Backup & Replication server

Veeam Plug-ins for Oracle RMAN, SAP HANA, SAP MaxDB, SAP on Oracle and IBM Db2

• Standalone mode: 250 database servers and 2000 databases per Veeam Backup & Replication server
• Managed mode: 150 database servers and 600 databases per Veeam Backup & Replication server

Unstructured Data

• 100 simultaneously running backup or backup copy jobs
• 6.5 billion files per backup job

File to Tape Backup

• 2 billion source files and 20 billion file versions per Veeam Backup & Replication server

Veeam CDP

• 2000 VMs (up to 8000 VM disks) protected by CDP jobs
• 400 simultaneously running CDP jobs

Scale-out Backup Repository

• 24 Performance Extents

Veeam ONE

• Veeam Backup and Replication: 100 servers with up to 60,000 total protected workloads
• VMware Environment Monitoring and Reporting: up to 20,000 Virtual Machines
• Hyper-v Environment Monitoring and Reporting: up to 10,000 Virtual Machines

Veeam Cloud Connect

• 1000 concurrent tasks per Cloud Connect server
• 1000 tenants per Cloud Connect server
• 500 concurrent tasks per Cloud Gateway

Veeam Enterprise Manager

• Backup servers: 100 Veeam Backup & Replication servers

Initial Sizing Reference

The document provides practical starting configurations for deploying Veeam Data Platform components. These guidelines are designed to help with deployment planning and ensure optimal performance and stability.

Veeam Backup and Replication Server

The following sizing recommendations apply to image-level backup workloads (VMs and Veeam Agents) running backup, backup copy (mirror), and offload to object storage jobs.

Each configuration includes approximately 20-30% compute headroom above observed utilization to accommodate additional workload types.

Additional Considerations

• Virtual and physical Veeam Backup & Replication servers demonstrate comparable performance and resource utilization on both Linux and Windows platforms. For deployments exceeding 5,000 workloads, a physical server or dedicated hypervisor host is recommended.
• For all-in-one deployments where additional roles such as backup repository or backup proxy are co-located on the Veeam Backup and Replication server, the additional compute and storage requirements must be factored into sizing. Work with your Veeam Solutions Architect to produce sizing for all-in-one configurations.
• Disk 1 hosts the VBR configuration database. The Veeam Backup and Replication configuration database can grow to several terabytes when file-to-tape backup jobs are configured. If your deployment includes file-to-tape jobs, work with your Veeam Solutions Architect to size Disk 1 accordingly.

VMware Backup Proxy

The following sizing recommendations apply to the VMware backup proxy server deployed as a virtual appliance. Throughput figures may differ based on server CPU generation and CPU contention in the environment. Actual throughput may vary due to the impact of other parts of the infrastructure, such as source storage, network, or backup storage performance. The throughput figures assume both data encryption and inline entropy analysis are enabled. Disabling either or both of these features can significantly increase proxy throughput.

Block Storage Repository

Virtual Proxy, HotAdd Mode

Virtual Proxy, NBD Mode

Object Storage Repository, Direct to Object mode

Backup to object storage target assumes proxies are configured as gateway server in object storage repository settings (direct to object mode).

Virtual Proxy, HotAdd Mode

Virtual Proxy, NBD Mode

Additional Considerations

• 12 vCPUs is the recommended maximum proxy configuration. Configurations of 16 vCPUs and above may not be practical due to VM network bottleneck and potential hypervisor CPU resource contention.
• HotAdd transport mode introduces additional per-disk processing overhead, which can disproportionately increase incremental backup duration in environments with low data change rates. For large-scale environments with thousands of VMs and daily change rates below ~10%, NBD transport mode is generally recommended. For higher change rates, where the volume of changed data becomes the primary driver of processing time, HotAdd transport mode typically provides better performance than NBD.

VMware CDP Replication Proxy

The following sizing recommendations apply to the VMware CDP Replication proxy, which can only be deployed as a virtual appliance at both source and target ESXi clusters. Throughput figures may differ based on server CPU generation and CPU contention in the environment. Actual throughput may vary due to the impact of other parts of the infrastructure, such as source storage, network, or target storage performance.

Additional Considerations

• The CDP proxy intercepts write I/O at the source VMware cluster level. Proxies should be sized based on the aggregate write I/O profile of each protected cluster. Source-side data reduction is applied by the proxy, averaging approximately 50%, meaning the network link between source and target clusters should be provisioned to accommodate at least half of the average write I/O throughput. Target storage must also be capable of ingesting the incoming I/O stream at this rate.
• If source I/O spikes or network link saturation prevent real-time replication, the CDP replication will fall back to CBT (Changed Block Tracking) mode. In this state, replication is out of sync until source I/O subsides or sufficient network bandwidth becomes available to re-establish a full sync.

Backup Worker

The following sizing recommendations apply to backup workers. Veeam Backup & Replication automatically deploys workers for the following hypervisor platforms: Nutanix AHV, Proxmox Virtual Environment, HPE VM Morpheus Essentials, oVirt KVM, and Scale Computing HyperCore. The recommended worker configuration is the default: 6 vCPU, 6 GB RAM. To increase aggregate throughput, scale horizontally by deploying additional workers rather than increasing resources on individual workers.

Block Storage Repository

Object Storage Repository

Workers cannot write directly to object storage. A gateway server is required when the backup target is an object storage repository.

The gateway server sizing is based on the aggregate worker throughput received by the gateway using the following formula:

• CPU cores: 1 core per 300 MB/s (≈1 TB/h) of worker throughput received by the gateway
• RAM: 0.5 GB per CPU core

Additional Considerations

• The default worker configuration of 6 vCPU, 6 GB RAM provides the most efficient per-core throughput. Increasing individual worker resources beyond this configuration yields diminishing returns.
• Gateway server throughput scales linearly with CPU cores. For large-scale deployments with many concurrent workers, verify that the gateway server network connectivity can sustain the aggregate throughput.
• Multiple gateway servers can be assigned to a single object storage repository to distribute the load. When aggregate worker throughput exceeds the capacity of a single gateway server, add additional gateway servers rather than scaling a single server beyond practical hardware limits.

Unstructured Data

Unstructured Data Backup Proxy

The following sizing recommendations apply to the unstructured data backup proxy, configured as a General-Purpose Backup Proxy in the Veeam Backup & Replication console. The proxy deploys reader agents that pull data from source NAS shares, filers, or object storage buckets and transmit it to the backup repository. When the target is a block storage, the writer process runs on the repository server. When the target is an object storage, the writer runs on the proxy.

Unstructured data backup performance is highly dependent on the source dataset file size distribution. Environments dominated by large files (10 MB and above) typically achieve throughput in the GB/s range, limited by network and storage bandwidth. Environments with small files (KB range) are constrained by source storage IOPS, with throughput significantly lower than large file workloads regardless of available network bandwidth. Sizing recommendations are provided separately for each dataset profile.

Large File Dataset (10 MB and above)

Virtual Proxy

12 vCPUs is the maximum recommended configuration for virtualized proxy deployments. Throughput figures may differ based on server CPU generation and CPU contention in the environment. Actual throughput may vary due to the impact of other parts of the infrastructure, such as source storage, network, or target storage performance.

Physical Proxy

Physical proxy deployment is a flexibility choice that avoids introducing additional load on the virtual environment.

Physical proxies can saturate high-bandwidth network links and are recommended for large-scale NAS environments with high-performance block storage targets.

For large file datasets, multiple virtual proxies can be deployed to achieve aggregate throughput comparable to a physical proxy. In tested configurations, physical proxies saturated both 50 GbE and 25 GbE links in full duplex.

Small File Dataset (1 KB – 1 MB)

For small file workloads, proxy sizing is driven primarily by source storage IOPS rather than network throughput. A single reader agent can fully saturate the CPU on a proxy when processing large file datasets, but with small files the bottleneck shifts to source storage IOPS. The number of proxies should therefore be planned based on the IOPS capacity allocated to backup operations on the source storage system, not total array IOPS.

It is recommended to analyze source storage the IOPS utilization during the backup window and determine the IOPS capacity available for backup operations.

The following recommendations are based on observed IOPS consumption per proxy using an 8 vCPU, 16 GB RAM configuration.

Peak source IOPS consumption per proxy

Recommended Proxy Count by Source Storage IOPS

Note: proxy counts differ because each dataset type drives a different IOPS-per-proxy rate (round up as needed).

Additional Considerations

• For small file datasets, adding proxies increases aggregate IOPS consumption on the source storage. Monitor source array utilization and reduce the source I/O Control setting or the number of proxies if production workload performance is affected.
• Modern storage systems typically provide between 200,000 and 400,000 IOPS. Not all of this capacity should be allocated to backup — reserve sufficient IOPS for production workloads and schedule backup during periods of lower utilization where possible.

Unstructured Data Cache Repository

The following sizing recommendations apply to the unstructured data cache repository, which is a required component for all unstructured data backup jobs. The cache repository stores a local index of the protected NAS share structure and acts as the controlling unit for unstructured data backup jobs. During each backup run, it coordinates the unstructured data proxy to scan the source share, identifies changed objects by comparing current state against the cached index, and directs data retrieval accordingly.

Cache repository sizing is driven by the number of concurrently processed unstructured data sources (tasks), the total protected file or object population, and the daily file or object change volume. Cache Repository Resource requirements depend on the backup target type.

• Block storage and NAS backup repositories store metadata directly on the target, resulting in lower cache repository resource requirements.
• When Object Storage repositories are used the active metadata is stored locally on the cache repository server, requiring dedicated fast SSD storage and higher compute resources.

Block or NAS Storage Repository

The following sizing recommendations apply to the cache repository when the backup target is a Block storage repository or NAS repository.

The cache repository does not require a dedicated metadata volume for this backup repository type, however, when unstructured data backups are written to a block, NAS, or deduplication appliance repository backed by slow spinning disks, metadata I/O can become a bottleneck, especially in large NAS environments with small-file datasets. In such cases, use a Scale-Out Backup Repository (SOBR) and assign a dedicated SSD-based extent to the metadata role. This allows metadata operations to benefit from SSD performance while backup data remains on capacity-oriented storage. Extent roles can be assigned manually as described in the User Guide.

Object Storage Repository

The following sizing recommendations apply to the cache repository when the backup or backup copy target is an object storage or Deduplication Appliance. SSD storage is mandatory for the cache repository metadata volume.

The Metadata Disk sizing figures below are based on a 1% daily change rate and 30-day retention, for accurate sizing specific to your environment, contact your Veeam Solutions Architect.

Additional Considerations

• The cache repository operating system must match the backup server operating system. For Linux-based backup servers, deploy the cache repository on Linux; the Veeam Infrastructure Appliance ISO can be used for this purpose.
• For Windows-based backup servers, deploy the cache repository on Windows and format the metadata volume as NTFS with a 4 KB allocation unit size.

Veeam Hardened Repository

The Veeam Hardened Repository is a Linux-based backup repository providing immutable backup storage protected against ransomware and malicious deletion. The Veeam Hardened Repository can be deployed on a supported Linux distribution or using the Veeam Infrastructure Appliance ISO. For ISO-based deployment, the server hardware must be listed on the Red Hat Enterprise Linux 9.2 hardware compatibility list.

The following sizing recommendations apply to generic NL-SAS drive-based storage servers and are intended as a reference for planning repository hardware configurations.

Backup throughput figures assume 2:1 source-side data reduction. The repository receives and writes post-reduction data.

Storage Configuration

• Modern RAID controllers with battery-backed write cache are recommended. A stripe size of 256 KiB should be used for all data volumes.
• Hot spare drives are not included in usable capacity figures and must be factored separately based on server configuration and total drive count.
• A dedicated ~240 GB boot volume is required, configured either on the data controller or on a separate controller. If a separate controller is used, two 240 GB drives in RAID 1 are recommended for fault tolerance.

Additional Considerations

• In dual RAID controller configurations, the two storage volumes can be combined into a single Scale-Out Backup Repository. This allows Veeam Backup & Replication to treat both volumes as a single logical repository, distributing the load across both controllers.
• The VMware backup proxy role is supported on the Veeam Hardened Repository server. If the VMware proxy role is co-located on the repository server, compute resources must be increased to account for the additional proxy workload. Refer to the VMware Backup Proxy sizing section for proxy resource requirements.
• The Veeam Mount Service and vPower NFS Service cannot be configured on the Veeam Hardened Repository. Recovery operations requiring these services, such as Instant VM Recovery, must be performed through a separate Veeam Backup Infrastructure component.