Veeam Backup for VMware: The Configuration That Actually Works in Production
We have designed Veeam Backup & Replication architectures for more than 40 companies across Southeast Asia. The configurations that survive real disasters share a common structure. Here is the production-proven setup we use for a typical 500-VM VMware environment.
The Reference Architecture
Our standard deployment uses three tiers:
| Tier | Role | Spec Guidelines |
|---|---|---|
| Backup Server | Veeam B&R console, SQL catalog | 8 vCPU, 32 GB RAM, fast OS disk |
| Proxy Servers | Handle VM snapshot and data movement | 2-4 proxies, 4 vCPU / 16 GB each |
| Repository | Store backup files | Local RAID, NAS, or object storage |
For the 500-VM example: - Backup Server: One Windows Server 2022 VM, joined to management domain - Proxy: Four hot-add proxies distributed across hosts - Repository: A hardened Linux repository with immutability enabled, plus a copy to S3-compatible object storage
Backup Job Design
We split VMs into jobs by recovery priority, not by department.
| Job Group | VMs | Retention | Schedule |
|---|---|---|---|
| Tier 1 — Critical | ERP, databases, domain controllers | 30 restore points | Every 4 hours |
| Tier 2 — Business | File servers, internal apps | 21 restore points | Nightly |
| Tier 3 — Standard | Dev/test, low-priority workloads | 14 restore points | Weekly |
Each job targets 8-12 VMs. Jobs with too many VMs take too long; jobs with too few create management overhead.
Transport Mode Selection
Veeam offers three transport modes for VMware:
| Mode | When to Use | Performance |
|---|---|---|
| Hot-Add | Most environments | Good, minimal network impact |
| Network (NBD/NBDSSL) | Physical proxy or no SAN access | Lower, uses management network |
| Direct SAN | FC/iSCSI SAN with proxy access | Highest, but complex |
For 90% of our deployments, hot-add with Virtual Appliance proxies is the right choice. It is simple, fast enough, and does not require SAN zoning.
Repository Configuration
Primary Repository: Hardened Linux
We deploy a Linux repository with the following settings: - Immutability: 14 days minimum - XFS file system: Required for fast cloning - Encryption at rest: AES-256 - Network isolation: Separate backup VLAN, no domain membership
Secondary Copy: Object Storage
We configure a capacity tier copy to S3-compatible storage with: - 180-day retention - Encryption before upload - No direct public internet access; traffic goes through VPC endpoint or private link
The 3-2-1-1-0 Rule in Practice
| Principle | Implementation |
|---|---|
| 3 copies | Production + backup + copy |
| 2 media types | Disk repository + object storage |
| 1 offsite | Object storage in different region |
| 1 immutable | Hardened Linux repository |
| 0 errors | SureBackup job validates backups weekly |
SureBackup and Recovery Verification
A backup you cannot restore is worthless. We configure SureBackup to automatically verify: - Bootability of critical VMs - Network connectivity inside the isolated lab - Application-level checks: SQL service status, web server response
We schedule SureBackup every Sunday at 2 AM. If a VM fails verification, the job opens a ticket in our PSA system.
RPO and RTO Targets
For the 500-VM reference environment:
| Tier | RPO | RTO |
|---|---|---|
| Tier 1 | 4 hours | 1 hour |
| Tier 2 | 24 hours | 4 hours |
| Tier 3 | 7 days | 48 hours |
These targets drive the job schedule and replication strategy.
Common Mistakes We Fix
- Single backup server with no HA. If the backup server fails, recovery takes longer. We keep configuration backup enabled and document rebuild steps.
- Overloading one proxy. Distribute proxies across hosts and datastores.
- No backup network isolation. Backup traffic should not share the production VM network.
- Keeping backups on the same SAN as production. A SAN failure takes both copies down.
- Never testing restores. SureBackup is not optional.
Real-World Recovery Example
A manufacturing client in Cebu lost a production database VM due to storage corruption. Using Veeam Instant VM Recovery, we had the VM booting from the backup repository within 12 minutes. The actual restore to production storage completed in the background over the next 4 hours. Total business downtime: under 15 minutes.
Sizing Cheat Sheet
| VMs | Proxy Count | Repository Capacity (30 days) | Backup Window |
|---|---|---|---|
| 100 | 2 | 40-60 TB | 6 hours |
| 500 | 4 | 200-300 TB | 8 hours |
| 1,000 | 6-8 | 400-600 TB | 10 hours |
These numbers assume 50% data reduction through compression and deduplication.
Bottom Line
A reliable Veeam environment is not about buying the most expensive license. It is about separating workloads by recovery priority, using hot-add proxies, storing backups on immutable Linux with an offsite copy, and verifying restores every week.
Want to go deeper? Explore VMware alternatives, Run infrastructure services, or platform comparison.