If you've booted the Proxmox VE installer and gotten to the disk screen, you've probably noticed a dropdown labeled Filesystem with options like zfs (RAID1) and zfs (RAIDZ-2) sitting next to the familiar ext4. Most guides skip right past this screen with "just pick ZFS RAID1" and move on. That's fine advice for a two-disk homelab box, but it's not the whole story, and picking the wrong level here is annoying to fix later — you can't just click a button to switch from RAIDZ-1 to a mirror after the fact. You have to reinstall.
This guide walks through what each RAID level actually means, how many disks each one needs, and how to fill in the Advanced Options that show up once you pick ZFS. By the end you'll know exactly what to click, and just as importantly, why.
What You Will Learn
- What the ZFS RAID levels in the Proxmox VE installer actually do (RAID0, RAID1, RAID10, RAIDZ-1, RAIDZ-2, RAIDZ-3)
- How many disks each level requires, and what happens if you don't have enough
- How to set the Advanced Options: ashift, compress, checksum, copies, hdsize, and ARC max size
- Commands to check your pool's health and configuration after install
- Mistakes that waste disk space or leave you with no redundancy at all
What Is This Feature?
ZFS is a combined filesystem and volume manager that Proxmox VE can install itself onto instead of the more common ext4-on-LVM setup. It handles software RAID, checksums every block it writes so it can detect corruption, and supports snapshots natively. You don't need a separate volume manager or a hardware RAID card — ZFS does all of it in software, using the CPU and RAM you already have.
When you choose ZFS during installation, the installer asks which RAID level to use for the pool that Proxmox itself will boot from (called rpool). That choice determines how many disks you need, how much usable space you end up with, and how many disks can fail before you lose data.
Why Would You Use It?
The honest answer: because a single disk has no protection against failure. If you install Proxmox on one ext4 disk and that disk dies, your VMs are gone unless you had backups running somewhere else. ZFS RAID at install time gives your boot pool redundancy from minute one, before you've even created your first VM.
It's also worth using ZFS even on a single disk in some homelab setups, purely for the checksumming — silent data corruption on a dying drive shows up as a checksum error in zpool status long before your files actually look broken. But single-disk ZFS (RAID0 with one device) gives you zero fault tolerance. If that disk fails, you lose the pool exactly like you would with ext4.
Prerequisites
- A Proxmox VE ISO written to USB, and a server or PC to install it on
- At least 2 disks if you want any redundancy at all — more, depending on the level you pick (see the table below)
- 8 GB of RAM minimum, 16 GB or more if you're going to run ZFS seriously — it wants RAM for its ARC cache
- Disks that are the same size, or close to it. ZFS uses the smallest disk in a vdev as the ceiling for every disk in that vdev, so a 2 TB drive mirrored with a 500 GB drive only gives you 500 GB
- Access to your server's boot menu or BIOS/UEFI settings, since you'll need this later if you ever have to add a boot entry for a replacement disk
One more thing before you start: selecting ZFS at install time wipes every disk you assign to the pool. Back up anything on those drives first.
Step-by-Step Tutorial
Step 1: Boot the installer and pick a target
Boot from your Proxmox VE USB and choose Install Proxmox VE. On the "Target Harddisk" screen, click Options next to the disk selector. This opens the dialog where Filesystem lives.
Step 2: Understand the RAID levels on offer
Here's what each one actually buys you. "Usable capacity" assumes disks of equal size, call it N terabytes each.
| Level | Min. disks | Usable capacity | Disks that can fail | Good for |
|---|---|---|---|---|
| RAID0 | 1 | 100% (all disks striped) | 0 | Scratch/test boxes only — no redundancy |
| RAID1 | 2 | 1 disk's worth | 1 (of 2) | Small homelabs, NUCs, two-bay servers |
| RAID10 | 4 (even number) | Half the total | 1 per mirror pair | VM-heavy workloads that need speed and redundancy |
| RAIDZ-1 | 3 | N-1 disks' worth | 1 | Bulk storage where capacity matters more than IOPS |
| RAIDZ-2 | 4 | N-2 disks' worth | 2 | Larger arrays you don't want to babysit |
| RAIDZ-3 | 5 | N-3 disks' worth | 3 | Big arrays where a second failure during rebuild would be a disaster |
If you only have two disks, your real choice is RAID1 or nothing — RAIDZ-1 needs three. This trips people up constantly: they've got two spare 1 TB drives, pick RAIDZ-1 from the dropdown, and the installer just won't let them proceed because it's greyed out or throws an error once they try to pick disks.
The official Proxmox documentation is blunt about which one to prefer for VM storage: mirrors (RAID1 or RAID10) behave better under the small, random I/O pattern that VMs generate. RAIDZ levels give you more usable space per disk, but every write has to touch every disk in the group, which costs you IOPS. If your workload is mostly VMs and containers rather than a media library, lean toward a mirror.
Step 3: Pick your disks
Once you've chosen a RAID level, the disk list below it will only let you select the matching number of disks (or a multiple of two, for RAID10). Tick the boxes for the physical disks you want in the pool. Double check the model and size shown next to each one — this is the last point where mixing up /dev/sda and /dev/sdb is easy to undo.
Step 4: Set the Advanced Options
Click Advanced Options in the same dialog. You'll see a handful of fields:
- ashift — controls the sector size ZFS assumes for the underlying disks, as a power of two. The default of 12 (meaning 4096-byte sectors) is correct for almost every SSD and modern HDD sold today. Setting it too low for your actual disk hardware hurts performance permanently — you can't change it after the pool is created — so when in doubt, leave it at 12.
- compress — whether ZFS compresses data on the fly before writing it. Leaving this on costs a small amount of CPU and often speeds up disk I/O in practice, because there's less data to physically write. There's rarely a good reason to turn it off on a modern CPU.
- checksum — which algorithm ZFS uses to detect corrupted blocks. The default is fine; this is the mechanism that lets ZFS notice a bad sector before it silently corrupts a VM disk.
- copies — how many redundant copies of each block ZFS keeps, on top of whatever RAID redundancy you already have. Leave this at 1 unless you have a specific reason to burn extra space for belt-and-suspenders protection on a single disk.
- hdsize — how much of the disk to actually use for the pool. Leave it blank to use the whole disk, or set a smaller number if you want to reserve unpartitioned space at the end of the drive for something else later.
- ARC max size — the ceiling on how much RAM the ZFS Adaptive Replacement Cache is allowed to use. Left at the installer's default, ZFS will happily eat a large chunk of your RAM to cache reads, which is normally what you want, but on a box with only 8 GB total it's worth capping this so your VMs don't get starved.
Unless you have a specific reason, the defaults here are sane. The one field worth actually thinking about on small hardware is ARC max size.
Step 5: Finish the install and verify
Continue through the rest of the installer — time zone, network, root password — the same as any other install. Once it reboots, log in over SSH or the console and check that the pool came up the way you expect:
zpool statusYou should see your chosen RAID level (mirror, raidz1, raidz2, and so on) and every disk listed as ONLINE. If anything says DEGRADED or UNAVAIL right after a fresh install, stop and investigate before you put anything important on it — see the troubleshooting section below.
Commands Explained
| Command | What it does |
|---|---|
zpool status | Shows the pool's RAID layout, disk health, and any errors ZFS has detected |
zpool status -v | Same as above, but lists specific files affected by any checksum errors |
zpool list | Shows total size, used space, and fragmentation for each pool in one line |
zfs list | Lists the individual datasets inside the pool (rpool/ROOT, rpool/data, and so on) and how much space each uses |
zfs get compression,checksum,copies rpool | Shows the current value of those Advanced Options settings after install |
zpool get ashift rpool | Confirms the ashift value that was actually applied — useful if you're not sure what the installer picked |
arc_summary | Prints a detailed breakdown of ARC memory usage, hit rate, and the current size cap |
proxmox-boot-tool status | Shows which disks currently have a bootloader installed — important on mirrored or RAIDZ boot pools |
Common Errors
"The selected filesystem requires at least 3 disks" (or similar) — you tried to pick RAIDZ-1 with only two disks selected. Either add a third disk or drop down to RAID1.
Pool usable size is smaller than expected — almost always caused by mixing disk sizes. A RAID1 pool made from a 2 TB and a 4 TB drive only gives you 2 TB usable, and the extra 2 TB on the bigger disk just sits unused. Match your disk sizes when you can.
Installer won't let you proceed past the disk screen — usually means an odd number of disks selected for RAID10, or a leftover partition table confusing the installer. Wiping the disks first with a quick pass in a live Linux environment (or letting the installer's own disk wipe run) usually clears it.
System boots into an emergency shell after install — rare, but it happens when a disk was silently excluded from the pool during a rushed install. Check zpool status from the emergency shell if you can reach it, or from a live USB by importing the pool.
Troubleshooting
If zpool status shows a disk as DEGRADED or UNAVAIL right after a clean install, the drive itself is the first suspect — reseat the cable, try a different SATA or NVMe port, and check the disk with smartctl -a /dev/sdX if you have smartmontools installed.
A more specific gotcha with mirrored and RAIDZ boot pools: some BIOS/UEFI firmware only remembers a boot entry for one of the disks in the pool. If that particular disk fails, the system won't boot from the survivors even though the pool itself is fine. Run proxmox-boot-tool status to see which disks currently have a boot entry, and proxmox-boot-tool init <partition> against any disk that's missing one — for example proxmox-boot-tool init /dev/sdb2. Do this once, right after installation, for every disk in the pool, not just when something breaks.
If the system feels sluggish and you're running with a small ARC max size on limited RAM, run arc_summary and look at the hit ratio near the top. A low hit ratio combined with a tiny ARC cap usually means it's worth adding RAM rather than fighting the cache size.
Best Practices
Stick to mirrors (RAID1 or RAID10) for the boot pool if your VMs are the main workload. RAIDZ saves disk space, but the write penalty is real once you've got a handful of VMs all doing small random writes at once.
Don't put the ZFS boot pool on a hardware RAID controller. ZFS wants to see the raw disks directly so it can manage redundancy itself — if a RAID card sits underneath it, ZFS loses visibility into individual disk health, which defeats the whole point of using it. If your server has a hardware RAID controller, either flash it to IT mode (pure HBA passthrough) or use the onboard SATA/AHCI controller instead.
Avoid mixing an SSD and an HDD in the same vdev — the array runs at the speed of the slowest member, so you'd be paying SSD prices for HDD performance.
ECC RAM is a genuinely good idea for a ZFS box, but it's not mandatory. ZFS with non-ECC RAM is still safer than most other filesystems, since the checksums catch corruption on disk either way. Don't let the lack of ECC talk you out of ZFS entirely — that's a common myth.
Watch your pool's fill level. ZFS performance drops noticeably once a pool passes roughly 80% full, because it has to work harder to find contiguous free space. zpool list will show you the current usage at a glance.
Frequently Asked Questions
Can I change the RAID level after installing?
Not directly. Growing a mirror into a bigger mirror is possible with zpool attach, and you can add a second mirror vdev to turn RAID1 into RAID10, but you can't convert a RAIDZ-1 pool into RAIDZ-2, or a mirror into RAIDZ, without backing everything up and reinstalling.
Do I need ECC RAM to use ZFS safely?
No. It's a nice-to-have that helps catch memory errors before they ever reach disk, not a requirement. Plenty of homelabs run ZFS for years on ordinary desktop RAM without issue.
What's the difference between RAID1 in ZFS and traditional hardware RAID1?
Both mirror data across two disks, but ZFS also checksums every block, so it knows which copy is correct if the two disks ever disagree — something a dumb hardware mirror can't do. Hardware RAID just picks a copy and hopes for the best.
I only have one disk. Should I still use ZFS?
You can, and the checksumming is still useful for catching corruption early. Just understand that a single-disk ZFS pool (RAID0 with one device) has zero fault tolerance, same as ext4 on that same disk. Back up elsewhere regardless.
Can I add more disks to my pool later?
You can add an entirely new mirror or RAIDZ vdev to an existing pool to grow capacity, but you can't add a single disk to an existing RAIDZ vdev to widen it. Plan your disk count with some room to grow if you can.
Conclusion
The RAID level dropdown on the Proxmox installer looks like a small decision, but it's one of the few settings in this whole platform that genuinely locks you in without a reinstall. Two disks means RAID1. Three means you can consider RAIDZ-1, though a mirror is still often the better call for VM storage. Four or more opens up RAID10 or RAIDZ-2, and the right pick from there comes down to whether you value raw speed or usable capacity more.
Take the extra five minutes on this screen before you commit. It's a lot less painful than migrating VMs off a pool you picked in a hurry.