The official Proxmox Backup Server requirements are intentionally conservative. They describe what PBS will run on — not what it will run well on when protecting production workloads at scale. Teams that provision PBS to the published minimum quickly encounter deduplication bottlenecks, slow restore performance, and backup windows that exceed what the environment can tolerate. The minimum is a floor, not a target.
This guide covers what Proxmox Backup Server actually requires for production use: hardware sizing by VM count, RAM requirements for the deduplication chunk index, CPU requirements for backup ingestion and garbage collection, port requirements for PVE-to-PBS connectivity, and network bandwidth planning. Whether you are sizing a new PBS deployment or evaluating why an existing one underperforms, the numbers here reflect real production deployment patterns. For the broader PBS architecture context, see the complete Proxmox Backup Server guide.
Proxmox Backup Server Requirements: Minimum vs Recommended System
Proxmox publishes the following minimum system requirements for PBS. These are suitable for a lab or evaluation setup protecting fewer than 5 VMs. They are not appropriate for any production workload.
| Component | Published Minimum | Production Recommended (Small) | Notes |
|---|---|---|---|
| CPU | 64-bit (Intel/AMD) | 4+ cores | More cores reduce backup window for concurrent jobs |
| RAM | 2 GB | 8 GB minimum | 1 GB RAM per 1 TB deduplicated data — see RAM section below |
| OS Disk | 32 GB | 64–128 GB SSD | Never use OS disk for backup datastore storage |
| Backup Storage | Any separate disk | ZFS on dedicated HDDs | RAIDZ1 minimum; RAIDZ2 for drives >8 TB |
| Network | 1 GbE NIC | 1 GbE for <20 VMs; 10 GbE for larger | Dedicated backup VLAN recommended |
| OS | Debian 12 (via PBS ISO) | Same — installed via PBS ISO only | Do not install PBS on existing Debian; use the ISO |
Proxmox Backup Server Hardware Requirements by VM Count
The right way to size PBS is bottom-up: start with VM count, average VM size, and retention depth, then derive the storage, RAM, and CPU requirements. The table below gives practical baselines across common environment sizes.
| Environment | VMs | CPU | RAM | OS Disk | Backup Storage | Network |
|---|---|---|---|---|---|---|
| Lab / Small | <20 | 4 cores | 8 GB | 64 GB SSD | 4–8 TB HDD | 1 GbE |
| Medium | 20–100 | 8 cores | 16–32 GB | 128 GB SSD | 16–32 TB (ZFS RAIDZ1) | 10 GbE |
| Large | 100–500 | 16+ cores | 64 GB | 256 GB SSD | 50–200 TB (ZFS RAIDZ2) | 10–25 GbE |
| Enterprise | 500+ | 32+ cores | 128 GB+ | 512 GB SSD RAID 1 | 200 TB+ (ZFS / SAN) | 25 GbE+ |
Proxmox Backup Server RAM Requirements: Why Memory Gets Underestimated
RAM is the most frequently under-provisioned PBS resource. The reason is straightforward: PBS builds an in-memory chunk index for deduplication operations. As the datastore grows, so does the index. The sizing rule of thumb:
- 1 GB RAM per 1 TB of deduplicated backup data
- Plus 2–4 GB for the OS and PBS service baseline overhead
A PBS instance managing 10 TB of deduplicated data therefore requires approximately 12–14 GB of RAM. Under-provision RAM and the chunk index spills to swap, causing PBS to write deduplication index lookups to disk on every backup and restore operation. The result: backup jobs that should complete in 30 minutes take 3–4 hours, and restore performance degrades proportionally. The fix is simply adding RAM — but it requires a service restart to take effect.
A practical implication: size RAM based on your expected datastore size at maximum retention depth, not your current data volume. If you plan 30-day retention for 50 VMs averaging 300 GB each with a 2:1 dedup ratio, your datastore will eventually hold approximately 2.25 TB of deduplicated data — plan for at least 6–8 GB RAM for the chunk index alone.
Proxmox Backup Server CPU Requirements
CPU load in PBS is dominated by two distinct operations: backup ingestion (chunking, hashing, compressing incoming data) and garbage collection (walking the entire chunk store to identify unreferenced chunks). These operations have different profiles.
Backup ingestion scales horizontally with core count — PBS parallelizes concurrent backup jobs across available CPU cores. For environments backing up multiple clusters simultaneously, each additional core meaningfully reduces the backup window. For a single-cluster environment running sequential nightly jobs, a 4–8 core CPU handles ingestion without issue.
Garbage collection is more CPU-intensive per operation and runs against the entire chunk store. On large datastores (20 TB+), a GC run can take 30–60 minutes and consume significant CPU. Schedule GC jobs during off-hours and ensure sufficient cores are available. For environments over 100 VMs, 16+ cores reduce GC job duration enough to allow nightly GC runs without impacting the backup window.
Proxmox Backup Server Port Requirements
PBS uses a small number of ports. All PVE-to-PBS backup traffic flows through a single HTTPS connection:
| Port | Protocol | Direction | Purpose |
|---|---|---|---|
| 8007 | TCP (HTTPS) | PVE nodes → PBS | PBS API, web UI, and all backup data transfer — primary communication port |
| 22 | TCP (SSH) | Admin → PBS | Administrative access; restrict to management subnet |
| 80/443 | TCP (HTTP/HTTPS) | PBS → internet | Package updates (outbound only; can be proxied) |
The Proxmox Backup Server default port is 8007. This single port handles all communication between Proxmox VE and PBS — backup data transfer, API calls, and the web management interface. If your firewall or network segmentation blocks port 8007 from PVE node IPs to the PBS host, Proxmox VE will not be able to add PBS as a storage target, and all backup jobs will fail with a connection error.
To change the default port, edit /etc/proxmox-backup/proxmox-backup-proxy.cfg and restart the service:
systemctl restart proxmox-backup-proxy.servicePort changes require updating the storage configuration in PVE to match.
Proxmox Backup Server Requirements: Storage and Sizing
Storage sizing requires three inputs: total source data size, expected daily change rate, and retention window. The simplified formula:
Required storage = (Source data × daily change rate × retention days) ÷ dedup ratioUsing conservative assumptions (5% daily change rate, 2:1 dedup ratio):
| VMs | Avg VM Size | Total Source | Retention | Estimated PBS Storage Needed |
|---|---|---|---|---|
| 10 | 100 GB | 1 TB | 30 days | ~1.5 TB |
| 25 | 200 GB | 5 TB | 30 days | ~7.5 TB |
| 50 | 300 GB | 15 TB | 60 days | ~22 TB |
| 100 | 400 GB | 40 TB | 90 days | ~60 TB |
| 250 | 500 GB | 125 TB | 90 days | ~187 TB |
Real-world dedup ratios on template-based VM clusters (cloned Windows Server builds, for example) are substantially higher — often 5:1 to 10:1 — which proportionally reduces actual storage requirements. Use 2:1 as a conservative planning baseline and refine after initial deployment data is available. Always add 20–30% overhead above the calculated estimate: backup data tends to grow faster than expected as VM count increases.
Network Requirements and Bandwidth Planning
Network throughput determines your maximum backup window. At practical throughput limits:
- 1 GbE: ~80–90 MB/s real-world. Suitable for environments under 5 TB source data with a 2–4 hour backup window. Adequate for small deployments; becomes a bottleneck as VM count grows.
- 10 GbE: ~800–900 MB/s real-world. Required for environments over 10 TB source data or with backup windows under 4 hours. The practical minimum for medium-to-large PBS deployments.
- 25 GbE: Recommended for large environments (100+ VMs) running concurrent backup jobs from multiple Proxmox nodes.
Place PBS on a dedicated backup VLAN or network segment separate from VM production traffic. Backup jobs saturating the same network used by production VMs cause latency spikes. A dedicated backup network also simplifies firewall rule management — you can allow port 8007 from the entire PVE subnet to PBS without opening it on the production network.
Common Proxmox Backup Server Sizing Mistakes
- Running PBS as a VM on the same host it backs up. A single point of failure by definition. If the host fails, both the VMs and the backup server are unavailable simultaneously.
- Installing the datastore on the OS disk. Backup data fills the OS disk, making PBS unmanageable. Always use a separate dedicated disk or ZFS pool for the datastore.
- Under-provisioning RAM for chunk index growth. Size RAM for your retention-depth datastore size, not the current volume. The index grows as data accumulates.
- Using spinning disks without RAID. A single drive failure destroys all backup data on that disk. Use ZFS RAIDZ1 at minimum; RAIDZ2 for drives over 8 TB.
- Skipping GC job scheduling. Pruned backups are not storage-freed until GC runs. Without scheduled GC, storage fills despite configured retention.
- No UPS protection. Unexpected power loss during garbage collection or chunk index operations can corrupt the datastore. PBS hardware should be on UPS-protected power.
Beyond PBS: When Sizing Isn’t the Bottleneck
Once PBS is correctly sized, teams managing multiple Proxmox clusters often find that the bottleneck shifts from hardware to management complexity — visibility across clusters, alerting on failures, policy enforcement, and compliance documentation. These are not hardware problems; they are management architecture problems.
Zmanda Pro addresses the management layer that PBS doesn’t provide: centralized multi-cluster backup management, automated alerting, immutable storage via S3 Object Lock for ransomware protection, and compliance-ready reporting for HIPAA, SOC 2, and PCI DSS requirements. For environments using NFS or iSCSI storage as backup destinations, Zmanda Pro manages these centrally without per-node configuration overhead.
Also read: Enterprise Proxmox Backup: A Complete Guide for IT Teams →
FAQs
