Proxmox Backup Server on a dedicated server: sizing, ZFS and off site sync
Proxmox Backup Server runs well on a dedicated server with several SSDs in a ZFS pool. It deduplicates every backup into shared chunks, so the datastore holds your data once plus what changes. Size it as used data plus daily change times the retention window, then leave 20 percent free. A six disk Xeon covers most Proxmox clusters.
This guide explains how deduplication works, gives a sizing method with worked numbers, compares ZFS layouts, sets up retention and off site sync, and matches the result to a server and disk option you can order.
What is Proxmox Backup Server, and why put it on a dedicated server?
Proxmox Backup Server (PBS) is the backup server made by the team behind Proxmox VE. It is free, open source software, with optional paid subscriptions for the enterprise package repository and support. Proxmox VE hosts send virtual machine and container backups to it, and any Linux machine can send file backups with proxmox-backup-client.
A backup that lives on the machine it protects is not a backup of that machine. PBS belongs on separate hardware, ideally in a different building from the hosts it protects. A dedicated server gives it that, with disks, memory and a network port that nothing else competes for. Backups write in bursts, verify jobs read everything back, and both run faster on hardware that is yours alone.
There is no PBS image at checkout, so order the server with Debian and add PBS from Proxmox's own package repository. PBS 3 runs on Debian 12 and PBS 4 on Debian 13, and both Debian releases are images on our dedicated servers.
How does Proxmox Backup Server deduplication work?
PBS splits every backup into chunks and names each chunk by its SHA 256 checksum. A chunk that already exists in the datastore is not stored again, whichever VM or day it came from. That is where the space saving comes from.
- VM disks are cut into fixed chunks of 4 MiB. Twenty VMs cloned from one template share most of their operating system chunks.
- File and container backups use variable sized chunks with boundaries set by the content, so inserting data near the start of a file does not shift and change every chunk after it.
- Compression with zstd is applied to each chunk, and optional client side encryption with AES 256 GCM means the server stores data it cannot read.
- Incremental VM backups use QEMU dirty bitmaps: while a VM keeps running, only the blocks written since the last backup are read and sent.
Every backup is still a full snapshot from the restore point of view. You can restore any of them, or a single file from inside one, without replaying a chain of increments.
Prune and garbage collection are two separate steps
Deleting a snapshot, by hand or with a prune job, only removes its index. The chunks stay until garbage collection runs: it marks every chunk a remaining snapshot still uses, then removes the unmarked ones that are older than a grace period of about a day. Schedule garbage collection after your prune jobs, and expect space to come back only after it has run.
How much storage does a Proxmox Backup Server datastore need?
Start from three numbers you can measure on your Proxmox VE hosts: the data your guests actually use, how much of it changes per day, and how far back your oldest kept backup reaches. Then an upper bound is simple:
datastore ≈ used data + (daily change × days covered by retention), then divide by 0.8 so the pool stays below about 80 percent full, a common rule of thumb for ZFS.
The bound is pessimistic on purpose. A block that changes again before the next kept snapshot is only stored for the snapshots that reference it, and zstd usually shrinks chunks further. How much it shrinks depends on the data, so treat compression as headroom, not as capacity.
A worked example
As an example, take a cluster whose guests use 1 TB of data and write 20 GB of new data a day, about 2 percent. Here is the upper bound for three retention policies.
| Retention | Days covered | Upper bound | Pool size at 80 percent |
|---|---|---|---|
| 14 daily | 14 | 1 TB + 14 × 20 GB = 1.28 TB | 1.6 TB |
| 14 daily, 8 weekly | 56 | 1 TB + 56 × 20 GB = 2.12 TB | 2.65 TB |
| 14 daily, 8 weekly, 12 monthly | 365 | 1 TB + 365 × 20 GB = 8.3 TB | 10.4 TB |
Long retention is what drives the size, not the number of VMs. The year long policy is an upper bound, and the real figure is usually lower because monthly snapshots skip most of the daily churn between them. Measure after the first month: the datastore summary in the PBS interface shows used space and the deduplication factor, and you can adjust the plan with real data instead of assumptions.
Should the datastore use ZFS, and which layout?
ZFS is the usual choice for a PBS datastore. It checksums every block, scrubs find silent corruption, and its mirrors and RAIDZ levels survive disk failures without a hardware controller. PBS adds its own verify jobs on top, which read chunks back and check them against their checksums.
With six SSDs, two layouts make sense:
- RAIDZ2 across all six disks. Four disks of usable space, and any two disks can fail. Best capacity per euro, and PBS writes in large chunks, which suits RAIDZ well.
- Three two way mirrors. Three disks of usable space, faster random reads for verify jobs and restores, and quicker resilvering after a disk swap. One disk per mirror can fail.
For most backup servers RAIDZ2 is the better trade. Pick mirrors when restore speed matters more than capacity. Creating the pool and the datastore takes two commands once PBS is installed:
zpool create -o ashift=12 backup raidz2 /dev/disk/by-id/DISK1 /dev/disk/by-id/DISK2 /dev/disk/by-id/DISK3 /dev/disk/by-id/DISK4 /dev/disk/by-id/DISK5 /dev/disk/by-id/DISK6
proxmox-backup-manager datastore create store1 /backup
Plan where the operating system lives before you order, because a six disk option replaces the single 240 GB SSD. If you need a particular disk layout at handover, ask before you order. ECC memory matters on a backup server too, since a bit flipped in RAM before a checksum is written gets stored as good data, as our guide to what ECC memory protects explains. Every dedicated server in our range has ECC memory.
How do you set up retention and off site sync?
Retention in PBS is a prune job per datastore or namespace. A sensible starting policy for business VMs:
| Option | Value | What it keeps |
|---|---|---|
keep-last | 3 | The three newest backups, whatever their age |
keep-daily | 14 | The last backup of each day for two weeks |
keep-weekly | 8 | The last backup of each week for two months |
keep-monthly | 12 | The last backup of each month for a year |
Run the prune job daily, garbage collection after it, and a verify job weekly so a damaged chunk is found long before you need it.
Off site copies with sync jobs
One backup server is one copy. The usual rule asks for three copies of your data, on two kinds of storage, with one off site. With PBS the off site copy is a second PBS in another location running a sync job that pulls new snapshots from the first.
Pulling has a security benefit: the second server holds its own credentials for the first, and the Proxmox VE hosts have no credentials for the second at all. If ransomware takes over a hypervisor and deletes what it can reach, the off site copy is not within reach. Client side encryption adds a second layer, because the off site server never holds the key.
Our dedicated servers can be ordered in 11 countries across Europe and the US, so the two backup servers can sit in different countries. Ports are unmetered, so the sync traffic between them carries no transfer bill. Our post on monitoring a server from another city shows the same two location idea applied to alerting.
How long transfers take
At the full line rate of a 1 Gbps port, 1 TB takes 8,000 seconds, about 2 hours 13 minutes, and a 20 GB daily change takes under three minutes. Real transfers run slower than line rate. The first full backup and the first sync are the long ones, and after that only new chunks move. Faster guaranteed ports of 2, 5, 10 or 20 Gbps are options at checkout if a restore window demands them.
Which voxa.host server fits a backup server?
PBS spends little server CPU, because the client does the chunking, hashing and compression before it sends anything. The server needs disks, memory for the ZFS cache and a good port. That makes the Dual Xeon E5 2630 v3 the natural choice: 16 cores and 128 GB of ECC memory for €209 a month, with six SSD options at checkout. Our Xeon E5 2630 v3 guide covers the machine itself.
| Six disk option | Server plus disks, per month | RAIDZ2 usable | Mirrors usable | Per RAIDZ2 TB |
|---|---|---|---|---|
| 6 × 1 TB SSD (+€60) | €269 | 4 TB | 3 TB | €67.25 |
| 6 × 2 TB SSD (+€120) | €329 | 8 TB | 6 TB | €41.13 |
| 6 × 4 TB SSD (+€360) | €569 | 16 TB | 12 TB | €35.56 |
| 6 × 8 TB SSD (+€798) | €1,007 | 32 TB | 24 TB | €31.47 |
Prices are monthly, exclude VAT and include the 1 Gbps guaranteed unmetered port. Usable figures are raw disk capacity before filesystem overhead. The Xeon servers deliver in about 45 minutes.
Against the worked example, the 14 day and 8 week policies fit the 6 × 1 TB option with room to spare, and the year long upper bound of 10.4 TB fits 6 × 4 TB in RAIDZ2. If the datastore has to be in the tens of terabytes on NVMe, the EPYC servers take 24 NVMe drives at checkout, as covered in our EPYC 9254 guide, but for backups the Xeon with SSDs is usually the better value.
Questions people ask
Can Proxmox Backup Server run on the same server as Proxmox VE?
It can be installed alongside Proxmox VE, and some people do that to back up a second host. It is no protection for the host it runs on: if that server fails or is compromised, the VMs and their backups go together. Use a separate server, or at least sync off site.
Does Proxmox Backup Server need a subscription?
No. PBS is free and fully functional without one, using the no subscription package repository. A paid subscription gives access to the enterprise repository and Proxmox's support. That choice is between you and Proxmox and does not change anything on our side.
Can I back up servers that are not hosted with you?
Yes. Any Proxmox VE host or Linux machine that can reach the PBS server on TCP port 8007 can back up to it. Restrict that port to your hosts' addresses in the server's firewall and turn on client side encryption for data crossing the internet.
How fast can I restore a VM from a dedicated backup server?
Mostly as fast as the port and disks allow. At 1 Gbps line rate, 100 GB takes about 13 minutes. Proxmox VE can also start a VM while it is still restoring from PBS, which shortens the outage for large disks.
Next step
Work out used data, daily change and retention for your cluster, pick the pool size from the table above, and order the Dual Xeon E5 2630 v3 with the matching disk option. If your Proxmox VE hosts are due for new hardware too, our guide on how many VMs fit on a dedicated server sizes the other side, and the full dedicated server range lists every configuration.
Deploy what you just read about
Deploy your first server now.
No minimum term. Intel Xeon builds carry a delivery estimate of under an hour; AMD EPYC builds are made to order. Every configuration has full root, ECC memory and a guaranteed 1 Gbps unmetered port.
Dedicated billed monthly · No setup fee · Full root on every server
- IPv4 address
- One included
- Unmetered port
- 1 Gbps guaranteed
- DDoS protection
- 100 Gbps · L3/L4
- Root access
- Included
- Setup fee
- €0.00
- Minimum term
- None