Veeam v13: Backup Proxy Design and Sizing -- HotAdd, NBD, Direct SAN, and Multi-Site Placement

Veeam v13 Series | Component: VBR v13, VIA v13 | Audience: Enterprise Architects, Hands-on Sysadmins

The backup proxy is the workhorse of a Veeam environment. Every byte of backup data passes through it. Every incremental, every synthetic full, every replication job. Get the proxy design right and your backup windows are comfortable with capacity to spare. Get it wrong and your jobs overrun, your storage I/O is a mess, and you end up bolting on more proxies reactively trying to fix a problem that should have been sized correctly from the start.

This article covers transport mode selection, CPU and RAM sizing with worked examples, network bandwidth calculations, virtual proxy versus VIA, and proxy placement in multi-site and stretched cluster environments. It's the article that makes the rest of the infrastructure decisions easier.

1. What a Proxy Actually Does

The proxy sits between the data source and the repository. It reads VM disk data from the hypervisor or storage, applies inline deduplication, compression, and encryption, and sends the processed data stream to the backup repository. Everything that makes Veeam incrementals efficient (dedup, compression, CBT) happens on the proxy. The VBR server orchestrates but doesn't touch backup data directly.

A task is one VM disk. A four disk VM counts as four tasks. This is the foundational unit for every sizing calculation in this article. When you set Max Concurrent Tasks on a proxy, you're setting how many VM disks it can process simultaneously. The official guidance from the Veeam helpcenter is no more than 2 tasks per CPU core and at least 1 GB RAM per concurrent task for VMware backup proxies.

2. Transport Mode Selection

Transport mode determines how the proxy physically reads data from the VM disk. It's the single most impactful configuration decision for backup performance and the one that most teams don't think about deliberately.

HotAdd vs NBD: The Practical Tradeoffs

HotAdd is the default choice for most all virtual environments because it avoids backup traffic on the management network. But it has a constraint the documentation buries: if you back up the proxy VM itself using HotAdd, CBT is disabled on that proxy. This is an official VMware limitation. Your proxy needs a separate backup job that either excludes the proxy or uses NBD mode for the proxy VM itself.

HotAdd also doesn't work well for encrypted VMs unless the proxy itself is encrypted with the same key policy. NBD handles encrypted VM backups without that constraint, because it reads via the VMkernel which handles decryption. If you have VM encryption in your environment, NBD is simpler for those VMs specifically.

On vSAN, HotAdd reads create I/O on the production vSAN datastore during the backup window. NBD reads move that I/O to the network instead. In environments where vSAN I/O is constrained during backup windows, NBD with 10 GbE backup VMkernel interfaces can actually produce better results than HotAdd because it removes the storage contention.

Direct SAN: The Physical Proxy Play

Direct SAN is the highest throughput option and the most infrastructure intensive. You need physical proxy servers with FC HBAs or iSCSI NICs connected to the same fabric as your VMware hosts. The VMs stay on the SAN. The proxy presents itself to the SAN and reads the VMDK files directly, bypassing VMkernel entirely.

The best practice sizing for a physical Direct SAN proxy is a sweet spot around 20 concurrent tasks: a dual socket server with 10 cores per socket (20 cores total), 48 GB RAM, two 16 Gbps FC cards for reading from the SAN, and one or two 10 GbE network cards for writing to the repository. That proxy can sustain roughly 20 simultaneous disk reads at full fabric speed, which is difficult to exceed with any virtual proxy configuration.

3. CPU and RAM Sizing with Worked Examples

Veeam's official sizing formula is straightforward. Here's how to apply it:

Required CPU cores = (Source Data Size GB * Change Rate %) / Backup Window Hours / Throughput per Task GB/h

Where:
  Source Data Size = Total protected data in GB
  Change Rate      = Daily change percentage (typically 2% to 5% for most workloads)
  Backup Window    = Available hours for backup to complete
  Throughput       = GB processed per hour per task (typically 100 to 150 GB/h for HotAdd/NBD)

RAM = 2 GB base + 1 GB per concurrent task (VMware proxy minimum)
      Use 2 GB per task for working headroom with dedup/compression/encryption enabled

Worked Example: 200 VM Mid-Size Environment

Environment:
  Total protected data:  20 TB (200 VMs, average 100 GB each)
  Average disks per VM:  2 disks (400 total tasks)
  Daily change rate:     3%
  Backup window:         8 hours
  Transport mode:        HotAdd (vSAN environment)
  Throughput per task:   120 GB/h (conservative HotAdd estimate)

Daily changed data:
  20,000 GB * 0.03 = 600 GB changed per day

Required task throughput to fit window:
  600 GB / 8 hours = 75 GB/h total throughput needed

Required concurrent tasks:
  75 GB/h / 120 GB/h per task = ~1 task (but this ignores full backup runs)

Full backup sizing (monthly active full):
  20,000 GB / 8 hours / 120 GB/h per task = ~21 concurrent tasks

Recommendation: Size for full backup, not just incremental
  Tasks needed:    22 (adding 5% buffer)
  CPU cores:       11 cores minimum (2 tasks per core), use 12
  RAM:             2 GB base + 2 GB x 22 tasks = 46 GB, round to 48 GB

Proxy configuration options:
  Option A (virtual proxies): Three 4-vCPU / 16 GB proxies = 12 total tasks each
                               Total: 36 tasks, 48 GB RAM across three VMs
  Option B (single larger):   One 12-vCPU / 48 GB proxy = 24 tasks
                               Less resilient but simpler to manage
  
Recommended: Option A. Multiple proxies distribute load across ESXi hosts
             and survive a single proxy failure without stopping all backups.

Worked Example: 1,000 VM Enterprise Environment

Environment:
  Total protected data:  150 TB (1,000 VMs, average 150 GB each)
  Average disks per VM:  2.5 disks (2,500 total tasks)
  Daily change rate:     5% (mixed workload including databases)
  Backup window:         6 hours
  Transport mode:        Mixed (HotAdd primary, NBD for encrypted VMs)

Daily changed data:
  150,000 GB * 0.05 = 7,500 GB changed per day

Required concurrent tasks (incremental):
  7,500 GB / 6 hours / 120 GB/h per task = ~10.4 tasks concurrent

Full backup (10% of VMs weekly = 100 VMs * 150 GB = 15,000 GB):
  15,000 GB / 6 hours / 120 GB/h per task = ~21 tasks concurrent

Proxy resource requirement:
  Tasks needed: 24 (full backup sizing with buffer)
  CPU cores:    12 minimum
  RAM:          2 GB + (2 GB x 24) = 50 GB

Recommended deployment:
  6 x VIA proxy nodes (pre-hardened, no Windows to manage)
  Each VIA: 4 vCPUs, 10 GB RAM = 8 tasks per VIA
  Total: 48 tasks across 6 VIAs
  Placement: 1 VIA per ESXi cluster to distribute HotAdd reads
  
Note: The job concurrency sweet spot for VBR is 80-100 simultaneous jobs.
      In this environment, use multiple smaller jobs (50 VMs each) rather
      than a few large jobs. This parallelizes the synthetic operations
      that run after the last VM in each job completes.

Virtual Proxy vs VIA: Which One

For new deployments there's rarely a reason to choose a Windows VM proxy over a VIA. The OS management overhead is real and the security posture difference is significant. The only clear reason to use a Windows proxy is if you need Direct SAN access, which requires a physical server with FC HBAs anyway.

4. Network Bandwidth Sizing

Two network flows matter for proxy sizing: the read path from source to proxy, and the write path from proxy to repository. They have different bandwidth requirements because Veeam applies deduplication and compression on the proxy before writing to the repository. Typically, optimized data on the write side is roughly 50% of the source data size after compression and deduplication. The read side needs to handle the full source change rate.

Read path (source to proxy):
  Required bandwidth = Concurrent tasks * Throughput per task
  
  Example: 12 concurrent HotAdd tasks at 120 GB/h each
    = 1,440 GB/h = 400 MB/s = 3.2 Gbps

  For NBD mode: 10 GbE gives ~700-900 MB/s usable (protocol overhead)
  Each 10 GbE NIC can handle roughly 6-8 concurrent NBD tasks at full speed

Write path (proxy to repository):
  After dedup/compression, typically 40-60% of source change rate
  
  Example: 400 MB/s read, 50% compression ratio
    = 200 MB/s to repository = 1.6 Gbps
    A single 10 GbE link is sufficient for most configurations

Rule of thumb:
  Each 10 GbE NIC supports 8-10 concurrent tasks in NBD mode
  For HotAdd: network NIC primarily for repository write path (10 GbE is almost always sufficient)
  For Direct SAN: 16 Gbps FC per proxy for reads, 10 GbE for repository writes

For NBD mode, dedicate separate VMkernel interfaces for backup traffic. Mixing backup NFC traffic with vMotion or management traffic causes contention and unpredictable throughput. Create a dedicated backup VMkernel network on a VLAN separate from production and management, with dedicated physical uplinks if your environment supports it.

5. Proxy Placement in Multi-Site and Stretched Cluster Environments

Proxy placement is where architects make the most consequential mistakes. The wrong proxy placement can double your backup window or saturate your WAN link.

The Core Principle

Proxies should be as close to the source data as possible. A proxy reading VM data over a 1 Gbps WAN link can process at most 100 MB/s, which limits it to roughly one task at full speed. A proxy co-located on the same cluster as the source VMs can run 8 to 10 concurrent tasks. Put your proxies in the same site, ideally on the same cluster, as the VMs they protect.

Multi-Site Environments

In a multi-site environment, deploy proxies at each site. The proxy at the remote site reads from local VMs using HotAdd or NBD, compresses and deduplicates the data, and then sends the optimized data stream (typically 40 to 60% of original size) across the WAN to the central repository. Without a local proxy, the raw unoptimized VM data would travel the WAN. You'd use 2 to 3 times as much WAN bandwidth for the same backup job.

• Deploy at minimum two proxies at each site for resilience. One proxy failure shouldn't stop all backups at that site.
• The central repository doesn't need proxies unless it's also protecting VMs. Repositories receive data, they don't process it for proxy reads.
• Use WAN acceleration if your remote sites are on low bandwidth links (under 100 Mbps). WAN acceleration applies additional global deduplication against the repository's existing data, further reducing what crosses the WAN.

Stretched Cluster Environments

A stretched vSphere cluster where VMs can run on either side of a WAN link is a proxy placement challenge. VMs migrate between sites, and if your proxy is only on Site A, a VM that moves to Site B now requires its backup data to travel back across the WAN to reach the Site A proxy.

The right approach: deploy proxies on both sites and use DRS affinity rules or VBR's proxy selection logic to prefer the proxy co-located with the VM. In VBR, when you have proxies at both sites, the job automatically selects the proxy closest to the VM being backed up based on the network infrastructure topology you've defined in VBR's Network Traffic Rules. Getting the traffic rules right ensures data takes the local path, not the WAN path.

In a stretched cluster with vSAN, set your repository at the preferred site. Backup data from Site B VMs will cross the WAN after being processed by the Site B proxy, but that's the compressed optimized stream, not the raw VM data. That's an acceptable trade.

DRS Co-Stop: The vCPU Ceiling for Virtual Proxies

Virtual proxies running on vSphere have a practical vCPU ceiling. VMware's DRS scheduler has to coordinate all vCPU ready states simultaneously, and proxies with too many vCPUs can experience co-stop delays where all vCPUs have to wait for each other to be simultaneously ready on physical cores. The Veeam best practices guide sets the limit at 8 vCPUs per virtual proxy, with an upper ceiling of 16 vCPUs in environments where the physics support it. Beyond that, add another proxy rather than adding more vCPUs to an existing one.

This is why the sizing examples above used multiple 4-vCPU proxies rather than one 16-vCPU proxy. The aggregate task capacity is the same, but the smaller proxies each carry a lighter co-stop risk and survive a single proxy failure without losing all capacity.