Proxmox ZFS topology guide
Proxmox ZFS Mirror vs RAIDZ: Capacity, IOPS and SSD Count
A Proxmox ZFS pool is defined as much by its vdev layout as by the SSD model. Mirrors spend more raw capacity on duplicate copies and are easy to scale in pairs; RAIDZ spends capacity on parity and can be attractive when usable terabytes matter. The correct choice depends on VM I/O, bay count, failure tolerance, expansion plans and how much raw flash you can afford.
Quick answer
Which ZFS vdev layout matches the host?
Use mirrors when simple two-device redundancy, strong random-I/O behavior and pair-by-pair expansion fit the host. Consider RAIDZ1 for capacity-focused non-critical pools with an appropriate drive count, and RAIDZ2 when two-device parity is worth the extra raw capacity. None of these layouts replaces an independent backup.
Live Amazon SSD listings
Current drives that fit this Proxmox decision
These cards come from this sprint's dedicated catalogue. NVMe, SATA and enterprise SSDs are classified separately. External drives, enclosures, adapters, barebones systems, multipacks and ambiguous capacity listings are rejected.
Buying decision
Choose vdev topology before choosing SSD capacity
Compare topology before buying SSDs. A 4×2TB purchase can produce very different usable space depending on mirrors, RAIDZ1 or RAIDZ2. The calculator subtracts parity/mirror capacity and your chosen free-space reserve so the decision is based on operating capacity rather than raw labels.
Interactive decision tool
ZFS Mirror vs RAIDZ Calculator
Size capacity, layout and drive class before comparing SSDs. The result is planning guidance, not a substitute for checking current Proxmox documentation, motherboard slot support, exact SSD endurance specifications and independent backups.
Compatibility checklist
Four checks before buying Proxmox storage
Endurance before headline speed
VMs, databases, logs and snapshots can turn a light desktop SSD workload into sustained writes.
Redundancy changes capacity
A mirror or RAIDZ layout changes usable space, failure tolerance and the number of drives you must buy.
Interface is not the whole answer
PCIe 5.0 can benchmark faster than PCIe 4.0, but many homelab workloads are limited elsewhere.
Backups remain separate
Snapshots and mirrors improve recovery options but they do not replace an independent backup target.
Vdevs are the unit that matters
ZFS combines devices into vdevs and vdevs into a pool. The redundancy characteristics of the pool are therefore determined by how the devices are grouped, not simply by the total number of SSDs installed.
A four-drive server could be two mirrored vdevs, one RAIDZ1 vdev or one RAIDZ2 vdev. Those choices have different capacity, fault domains and expansion paths even though the hardware list is identical.
Two-way mirrors are easy to understand
A two-way mirror writes each block to both members, so one member worth of capacity is usable before filesystem overhead. If one device in a mirror fails, the remaining member still holds the data for that vdev.
For Proxmox VMs, mirrors are popular because additional mirror vdevs create more independent I/O paths and expansion can be done in pairs. The tradeoff is buying two units of raw capacity for roughly one unit of mirrored capacity.
RAIDZ1 uses one parity device equivalent
RAIDZ1 uses single parity across the vdev. Basic shopping arithmetic subtracts one device worth of capacity, but real ZFS space is not exactly the simple disk-count formula because metadata, slop and allocation details reduce what users see.
Single parity can be attractive when capacity efficiency matters and the data is well backed up. Consider rebuild exposure, device size and the importance of the workloads before choosing it solely for more usable terabytes.
RAIDZ2 uses two parity device equivalents
RAIDZ2 can tolerate more device failures within the vdev than RAIDZ1 because it uses double parity. The price is another drive worth of raw capacity, making the layout less efficient in small arrays.
It becomes more compelling as the device count grows or the data matters enough to justify stronger parity. A four-drive RAIDZ2, for example, spends half the raw device count on parity-equivalent capacity before overhead.
Random VM I/O favors many independent paths
Virtual machines create many small, unrelated I/O operations. Multiple mirror vdevs can service concurrent operations independently, which is one reason mirrors are frequently chosen for VM-heavy ZFS pools.
RAIDZ can still host VMs, but a capacity-efficient topology is not automatically the fastest small-block topology. Test the actual workload and avoid claiming one layout is universally superior.
Capacity efficiency can favor RAIDZ
A wide RAIDZ vdev preserves more usable capacity than the same number of disks arranged as two-way mirrors, depending on parity level. That can matter when the primary objective is storing large datasets rather than maximizing random IOPS.
For mixed Proxmox hosts, decide which data really belongs on the VM pool. Large media or backup datasets may be better placed on a separate capacity tier instead of forcing the active VM pool into a topology chosen mainly for terabytes.
Expansion strategy should be planned early
Mirror pools can be expanded by adding another mirror vdev, assuming ports and bays remain. RAIDZ expansion options depend on current OpenZFS capabilities and version support, so read current documentation before designing around an expansion path described in an old forum post.
The safest design buys enough capacity for the near future and leaves physical room for the next planned expansion. An array that consumes every bay on day one limits later choices.
Mixed SSD sizes waste predictable capacity
A mirror is constrained by the smaller member, while RAIDZ layouts also become awkward when device sizes differ. Mixing capacities can be useful during staged upgrades, but the buyer should understand which space will be unavailable or underused.
Matching capacities make the calculator and replacement process simpler. If you intentionally mix models, document the exact device map so future maintenance does not rely on memory.
Free-space reserve changes the usable answer
Raw redundancy arithmetic is only the first subtraction. ZFS metadata, allocator behavior and operating headroom reduce the capacity you should assign to guests. A pool designed around “100 percent usable” is not an operationally comfortable pool.
The calculator applies a user-selected reserve after topology. That lets you see the difference between nominal capacity and a practical target for VM allocations.
Drive endurance still matters after topology
A mirror or parity layout protects against device failure, but it does not increase the write endurance rating of each SSD. A write-heavy database pool can wear every member faster than a read-heavy file pool using the same vdev design.
Choose topology and SSD class together. Enterprise drives may be justified for sustained write workloads even if a cheaper consumer model offers enough raw capacity.
Failure tolerance is not backup
RAIDZ2 can survive more device failures than a mirror vdev, but no local topology protects against every cause of data loss. Accidental deletion, host theft, software mistakes and pool-wide damage can still affect the primary storage.
Use Proxmox backup workflows or another independent system and test restores. Redundancy is about keeping storage available through device failures; backup is about recovering a separate copy.
Use the calculator as purchasing arithmetic
The tool intentionally simplifies capacity to make hardware decisions understandable. It does not model every ZFS metadata rule, compression ratio, recordsize or sparse VM allocation.
After choosing a topology and drive count, validate the final pool with current OpenZFS and Proxmox documentation. The shopping decision should be conservative enough that small differences in real formatted capacity do not matter.
Questions people ask
Proxmox ZFS Mirror vs RAIDZ questions
Is ZFS mirror faster than RAIDZ for Proxmox?
Mirrors are often attractive for random VM I/O because multiple mirror vdevs provide independent paths, but workload and hardware determine actual performance.
How many SSDs do I need for a mirror?
A basic two-way mirror needs two devices. Additional mirror vdevs are commonly added in pairs.
How many drives do I need for RAIDZ1?
RAIDZ1 requires multiple devices; practical layouts commonly use at least three, but choose width from capacity, performance and failure requirements.
How many drives do I need for RAIDZ2?
RAIDZ2 needs enough devices to support double parity; four is the minimum meaningful count, though wider layouts may be more practical.
Can I expand a mirrored ZFS pool?
Yes, a common approach is adding another mirror vdev when bays and ports are available.
Can RAIDZ be expanded?
OpenZFS capabilities evolve, so verify the expansion feature set in the version shipped with your Proxmox release before designing around it.
Does RAIDZ2 replace backups?
No. It improves device-failure tolerance inside the pool but does not create an independent copy.
Can I use different SSD brands together?
Yes in many configurations, but matching capacity and performance makes behavior and replacement planning easier.
Why reserve free space?
ZFS and operational tasks need working room. Keeping headroom reduces the risk that snapshots or growth push the pool to an unhealthy full condition.
Is the calculator byte-exact?
No. It is conservative purchasing arithmetic. Real formatted ZFS capacity is affected by metadata, slop and device geometry.
Official references and methodology
Verify Proxmox and OpenZFS behavior before deployment
Topology guidance is based on current OpenZFS RAIDZ concepts and Proxmox local-ZFS support. Capacity results are deliberately approximate and then reduced by the user-selected reserve. Cloudzat does not present simple parity arithmetic as byte-exact formatted capacity.
- Proxmox VE Storage Manager
- Proxmox VE Administration Guide - ZFS
- Proxmox VE Administration Guide - Installation
- Proxmox VE Administration Guide - Backup and Restore
- OpenZFS - RAIDZ
- OpenZFS - zpool properties
As an Amazon Associate, Cloudzat may earn from qualifying purchases. Prices, exact SSD revisions, warranty terms, firmware, endurance ratings and marketplace conditions can change. Verify the exact model before purchase.