Proxmox VM Storage Planner

Start with usable capacity, not raw

Enter capacity after RAID or ZFS redundancy, not the sum printed on the drive labels. A 4-disk 4TB setup using RAID-Z1 gives roughly 12TB usable, not 16TB. Use the RAID and ZFS calculator to convert your disk count and layout before typing a number here.

The free-space reserve is the most commonly skipped input. ZFS and thick-provisioned LVM both need headroom to perform copy-on-write and snapshot consolidation safely. Running a pool below 5% free triggers unpredictable behavior. A 20% reserve is conservative for home labs; tighten it only if you already monitor pool usage weekly.

Allocated disk is not used data

A VM can have a 500GB virtual disk while using only 60GB on a thin-provisioned pool. This calculator models used data and expected growth, which is what actually consumes space over time. If you provision disks thickly, or have disabled discard/TRIM on an existing pool, reality will drift upward from this projection. Sample a VM with du -sh inside the guest and zfs list -o used,referenced on the host to calibrate.

This planner does not prove that a particular mini PC supports Proxmox, passthrough or a storage controller. Installation, IOMMU grouping, drivers and sustained operation require testing on the target hardware. For Windows-based virtualization planning with the same mini PC hardware, see our EQi12 Windows Home Server build guide.

Growth compounds across the horizon

The monthly growth field compounds over the planning horizon. A VM that starts at 80GB and grows 5GB per month reaches 200GB after 24 months — 2.5× its starting size. That is why the default planning horizon is two years: it forces you to think about whether your pool can survive the expected load before you move VMs onto it. For a deeper walkthrough of RAID vs ZFS tradeoffs and how pool size affects every other decision, see our storage-planning guide.

Snapshots are not free

Proxmox snapshots write delta blocks that accumulate until you delete them. The snapshot allowance field reserves pool capacity so that rolling snapshots do not silently eat into your reserve. A 25% allowance means snapshot data can grow to a quarter of live VM data before the projection warns you. Review qm listsnapshot after a few months and lower the retention if snapshots are consuming more than expected.

Backups belong on separate hardware

The backup figure is intentionally reported separately. Backups stored on the same pool do not protect against pool loss from a controller failure, accidental zpool destroy, ransomware or a damaged enclosure. The backup size vs live data default of 65% accounts for LZ4 or ZSTD compression on typical Linux guests. Windows guests with pagefile and hibernation can compress less; verify after your first backup run and adjust accordingly.

Validate after deployment

• Compare planned growth with actual guest and pool usage monthly.
• Verify discard/TRIM behavior for thin-provisioned guests.
• Test snapshot deletion and backup restoration, not only backup creation.
• Alert before the pool reaches the reserve threshold.