ZFS / RAIDZ capacity calculator and Proxmox Backup Server storage
How much space is really left after parity, RAIDZ rounding and the ZFS reserve? And how much will your backup retention take? Two calculations, with the OpenZFS method shown under the result.
The calculation runs in your browser: nothing you type is sent anywhere.
Usable capacity of a ZFS pool
Result
Usable capacity
28.98 TiB
31.86 TB
Keep below (80 %)
23.18 TiB
Efficiency
66.4%
6 disks in total
Tolerated failures
2 disks
| Raw capacity | 43.66 TiB |
| Parity or copies | − 14.55 TiB |
| RAIDZ allocation padding | 0 GiB |
| ZFS reserved space (slop) | − 128 GiB |
| Usable capacity | 28.98 TiB |
Space used by a Proxmox Backup Server datastore
Result
Space used at full retention
1.32 TB to 5.28 TB
17 restore points kept
Datastore to plan (80 % full)
1.65 TB to 6.6 TB
First full backup
1 TB
0 % gain
Low bound: the same chunks change every day. High bound: every day touches different chunks.
Carry the high bound into the pool calculator above to choose your disks.
How the calculation works
The calculator follows the OpenZFS allocation rule, not the simple "(disks − parity) × size" formula. For each block, RAIDZ writes the data sectors, adds parity for each row, then rounds the total up to a multiple of (parity + 1) sectors. This is the vdev_raidz_psize_to_asize() function in the source code:
sectors = ⌈ block_size / 2^ashift ⌉
sectors += parity × ⌈ sectors / (width − parity) ⌉
sectors = rounded up to a multiple of (parity + 1)
efficiency = data sectors / allocated sectorsZFS reports the space of a RAIDZ vdev by applying this efficiency to a 128 KiB reference block. So does the calculator. At most widths you get the theoretical efficiency: 66.7% for a 6-disk RAIDZ2, 80% for a 5-disk RAIDZ1. At others, rounding costs space: a 10-disk RAIDZ2 gives 76.2% instead of 80%, an 8-disk RAIDZ3 57.1% instead of 62.5%.
Then comes the reserve ZFS keeps for its own writes, the slop space: 1/32 of the pool (spa_slop_shift = 5), at least 128 MiB and at most 128 GiB. Finally, the "keep below" capacity applies your target fill level. Beyond 80%, the allocator spends longer finding free blocks and writes slow down: a rule of thumb, not a hard limit.
Sources: vdev_raidz.c (OpenZFS), spa_slop_shift parameter (OpenZFS documentation).
The space a Proxmox Backup Server datastore needs
Proxmox Backup Server splits each backup into chunks and stores a known chunk only once. A datastore therefore holds the first full backup, then the new chunks of every restore point kept. The second calculator turns that into a range:
full = data × (1 − gain)
low bound = full × (1 + (points − 1) × chunks_changed_per_day)
high bound = full × (1 + Σ min(1, gap_days × chunks_changed_per_day))
gap = 1 day (daily), 7 days (weekly), 30 days (monthly)The rate to enter is not the share of data changed, but the share of chunks touched by at least one write (4 MiB by default). The difference is decisive for a database: on our MariaDB backup bench, scattered updates to one row in a hundred gave 0% deduplication, because every chunk contained a change. Clustered, the same updates deduplicate well. The low bound is the case where the same chunks change every day, the high bound the case where every day touches different chunks, like a file server receiving new files. Reality sits in between. The keep-daily, keep-weekly and keep-monthly options are those of PBS pruning. The calculation adds them without overlap, which slightly overestimates: on purpose.
The gain reference points come from our published measurements, not a market average. The first backup of a 1 TB Windows server sent 374 GB for 876 GB backed up, a 57% saving. On our time-series MariaDB database, the recommended way to back up MariaDB to Proxmox Backup Server, an SQL dump, cut the first backup by 86% (29.73 GiB → 4.3 GiB). A physical file copy does less well, 79% (45 GiB → 9.6 GiB), because it carries the indexes and the free space inside the files. On the following backups, seven hours later, 99.15% of the 4 MB chunks were already present: that is a reference point over 7 hours, for a database mostly fed by appends, not a daily rate. Hence the "up to": a very active database will deduplicate less. Start from 0% and adjust after a first real backup.
After the calculation
A local ZFS pool protects against a disk failure, not against losing the server, a fire or ransomware. The next copy must go elsewhere. For a NAS, see offsite TrueNAS backup. For a Proxmox VE cluster, offsite Proxmox backup sends backups to a PBS datastore operated in France. And to take a copy off the network, we documented how to take a PBS datastore offline with zfs send.
Once the volume is known, duration remains: do the first upload and the daily incremental fit your link? The backup window calculator answers for uploads to Nimbus. If the link is long, our TCP throughput calculator shows what latency takes away from replication. And if your disks sit behind a hardware controller rather than ZFS, the RAID calculator covers levels 5, 6, 10, 50 and 60.
If you would rather hand over the sizing and operation of your ZFS pools, that is what our managed Proxmox service does.
Frequently asked questions
How much usable space does a 6-disk RAIDZ2 give?
Four disks out of six, or 66.7% of raw capacity, minus the ZFS reserved space (1/32 of the pool, capped at 128 GiB). With six 8 TB disks, the pool shows about 29 TiB and 28.98 TiB remain usable. To keep good write performance, aim for 80% fill, about 23 TiB.
Why does my RAIDZ pool show less than (disks − parity) × size?
Three reasons. Disks are sold in decimal TB (10¹² bytes) while ZFS shows binary TiB (2⁴⁰ bytes): 8 TB is 7.28 TiB. RAIDZ rounds each block up to a multiple of (parity + 1) sectors, which costs space at some widths, for example 3.8 points on a 10-disk RAIDZ2. Finally, ZFS keeps a reserve (slop) of 1/32 of the pool, at most 128 GiB.
Mirror or RAIDZ for Proxmox virtual machines?
For VMs, a pool of mirrors is often the better choice: each mirror adds IOPS, a rebuild reads a single disk, and the small blocks of zvols avoid RAIDZ rounding. RAIDZ2 suits large files and backup datastores better, where capacity matters more than IOPS.
How much space should I plan for a Proxmox Backup Server datastore?
The first full backup, then, for each restore point kept, the blocks that changed since the previous one. The calculator gives a range: the low bound assumes the same chunks change every day, the high bound that every day touches different chunks. The rate to enter is the share of chunks changed, not the share of data: scattered updates to 1% of rows can touch almost every chunk. Then add 20% headroom for fill level and PBS garbage collection.
Are the deduplication gains shown guaranteed?
No. They are measurements published on our own data, as reference points: 57% on the first backup of an 876 GB Windows file server, and, on a time-series MariaDB database, up to 86% on the first backup of an SQL dump and 79% on the first pass of a physical file copy. Another dataset will give another result. To size without surprises, start from 0% and adjust after a first real backup.
Contact
Address
5 B RUE DES NOYERS, 95300 PONTOISE, FRANCE