ZFS vs Btrfs: Which Filesystem for Your NAS or Homelab?

ZFS for a dedicated NAS with stable drive counts and enough RAM; Btrfs when you need flexibility, mixed drive sizes, and in-kernel simplicity — as long as you avoid RAID 5/6.

Published: 2026-08-28

Short answer: pick ZFS if you are building a dedicated NAS with a stable set of drives and enough RAM. It has the most battle-tested data-integrity story available in any filesystem, and its RAID (RAIDZ), snapshot, and replication tooling has been hammered on in production for two decades. Pick Btrfs when you need flexibility: mixed drive sizes, adding a single drive to a pool whenever you like, and native support in every mainline Linux kernel with no extra modules — as long as you stay away from its RAID 5/6 modes. Both checksum everything and self-heal when given redundancy. The difference is temperament and operational shape, not whether your data is safe.

The rest of this post covers what copy-on-write filesystems actually buy you, the honest strengths and weaknesses of each, and why in most homelabs the platform you run ends up choosing the filesystem for you.

Quick comparison

Why a copy-on-write filesystem at all

The reason ZFS and Btrfs exist is a failure mode that traditional filesystems cannot even see: silent corruption. Drives occasionally return wrong data without reporting an error — a flipped bit from a failing sector, a firmware hiccup, a bad cable, a controller writing to the wrong place. On ext4 or XFS, that corrupted block is simply your data now. Nothing checks it, nothing notices, and the corruption quietly propagates into your backups until the day you open the file and find garbage. This is what people mean by bitrot.

Copy-on-write filesystems attack this with three mechanisms working together. First, checksums: every block of data and metadata is written with a checksum stored separately from the block itself, so a wrong read is detectable. Second, scrubs: a scheduled job walks the entire pool, verifies every checksum, and reports or repairs what it finds. Third, redundancy: when the filesystem has a mirror or parity copy, a failed checksum is not just detected but repaired automatically from the good copy. Detection plus redundancy equals self-healing, and neither ext4 nor XFS can do it, because they checksum (at most) metadata and have no idea what your file contents are supposed to look like.

Copy-on-write also makes snapshots nearly free. Because the filesystem never overwrites data in place, a snapshot is just a promise not to garbage-collect the old blocks. You get instant point-in-time copies of a whole dataset, instant rollback after a bad upgrade or a fat-fingered delete, and an efficient way to ship incremental changes to another machine. For a NAS holding years of family photos or a homelab running services you actually depend on, this combination — checksums, scrubs, self-healing, snapshots — is the whole reason to bother with either of these filesystems.

ZFS: strengths and weaknesses

Where ZFS is genuinely strong:

• Maturity at scale. ZFS has run under enterprise storage, backup appliances, and petabyte-scale archives since the mid-2000s. Its failure modes are documented, its recovery paths are well-trodden, and the collective operational knowledge around it is enormous. When something goes wrong at 2 a.m., someone has written up your exact situation.

• RAIDZ. Single, double, and triple parity (RAIDZ1/2/3) that avoids the classic RAID 5 write hole by design, because copy-on-write means a stripe is never partially overwritten in place. RAIDZ2 on six to eight drives is the boring, correct default for a serious NAS.

• send/receive replication. Snapshot a dataset, then stream it — or just the incremental delta since the last snapshot — to another pool or another machine. This is the backbone of most serious homelab backup pipelines and it is rock solid.

• ARC caching. ZFS keeps its own adaptive read cache in RAM, and it is very good at it. Give a ZFS box 32 GB of RAM and repeated reads of hot data barely touch the disks. Optional L2ARC on an SSD extends this further.

• Native encryption and delegation. Per-dataset encryption without a LUKS layer, plus fine-grained properties (compression, quotas, recordsize) settable per dataset.

Where it is weak:

• Licensing friction. The CDDL is incompatible enough with the GPL that ZFS will likely never ship in the mainline Linux kernel. OpenZFS works well as an out-of-tree module and distributions like Proxmox and Ubuntu package it cleanly, but a kernel update can occasionally outpace the module, and that is a category of problem Btrfs users simply never have.

• Historically rigid pool planning. For most of its life, a RAIDZ vdev could not be grown by adding a drive: you planned your vdev layout up front and lived with it. RAIDZ expansion did finally land in the OpenZFS 2.3 era, which softens this considerably, but it is a newer feature than the rest of the stack, and the culture of measure twice, buy all your drives once still fits ZFS best.

• Mixed drive sizes are a bad fit. A vdev is limited by its smallest member. If your drive pile is a 4 TB, a 6 TB, and two 8 TBs accumulated over the years, ZFS will waste a lot of that capacity.

• It wants dedicated hardware. ZFS is happiest as the whole point of a machine: direct access to the drives (HBA, not hardware RAID), a healthy RAM allowance for ARC, and ideally ECC memory. ECC is recommended rather than required — the scare stories are overstated, and non-ECC ZFS is still safer than non-ECC anything else — but the point stands that ZFS rewards purpose-built boxes and punishes afterthoughts.

Btrfs: strengths and weaknesses

Where Btrfs is genuinely strong:

• In the kernel, everywhere. Every mainline Linux kernel ships Btrfs. No modules, no DKMS, no license question, no risk that an update strands your pool. On any Linux box you will ever touch, mkfs.btrfs just works.

• Flexible device management. Add a single drive to a filesystem, remove one, replace one with a bigger one, convert between RAID profiles — all online, followed by a rebalance. Btrfs handles mixed drive sizes gracefully, which is exactly the situation most homelabs are actually in.

• Excellent on a single disk. This is underrated. Btrfs snapshots on a root filesystem, managed by snapper or Timeshift, mean every system update on openSUSE or Fedora is one rollback away from undone. ZFS can do this too, but Btrfs does it out of the box on ordinary distributions with ordinary kernels.

• Reflinks and subvolumes. Copy-on-write file copies (cp --reflink) are instant and space-free, and subvolumes give you snapshot boundaries without partitioning.

Where it is weak:

• RAID 5/6 is still not trustworthy. The write-hole problem and related repair edge cases have kept Btrfs parity RAID on the not-recommended list for years, including in the upstream documentation. Work continues, but for a NAS in 2026 the honest guidance is unchanged: use Btrfs RAID 1 or RAID 10, or do not use Btrfs for parity RAID at all. This single caveat is most of the reason ZFS keeps winning NAS builds.

• Fewer large-scale NAS deployments. Btrfs runs on millions of Synology boxes and Facebook has used it in production, but the deep bench of many-drive, many-year NAS war stories that ZFS has is thinner here. When things break, the recovery folklore is younger.

• Performance degradation at the edges. A Btrfs filesystem that is nearly full or heavily fragmented can degrade noticeably, and balance operations to fix it take time. Workloads that rewrite in place — databases, VM disk images — fragment badly under copy-on-write and typically need the nodatacow attribute, which also silently disables checksumming for those files. It works, but it is a sharp edge you have to know about.

• No native encryption. You stack Btrfs on LUKS. That is a proven combination, but it is one more layer, and you lose per-dataset encryption granularity.

When to choose ZFS

• You are building a dedicated NAS with a planned, stable set of drives — especially matched drives in a RAIDZ2 layout.

• Data integrity is the top requirement: irreplaceable photos, business records, long-term archives.

• You want proven parity RAID today, not eventually.

• You will use snapshot replication (send/receive) to a second box as part of a backup strategy.

• The machine has RAM to spare and ZFS gets the drives to itself.

• You are running TrueNAS or Proxmox anyway, where ZFS is the paved road.

When to choose Btrfs

• Your drives are mismatched sizes and ages, and you want to grow one disk at a time.

• You want checksums and snapshots on an ordinary Linux install — including on the root filesystem — with zero out-of-tree anything.

• Mirror or RAID 10 redundancy is enough, or the box is a single-disk machine where snapshots and bitrot detection are the win.

• The hardware is modest: an old desktop, a low-RAM mini PC, a machine that also does other jobs.

• You are on Synology, Fedora, or openSUSE, where Btrfs is the native choice.

The practical homelab decision: the platform picks for you

Here is the part most comparison posts skip: very few homelabbers choose a filesystem in the abstract. They choose a platform, and the platform has already chosen.

Run TrueNAS and you get ZFS — it is the entire identity of the product, and the web UI, alerting, snapshot scheduling, and replication are all ZFS-shaped. Run Proxmox and ZFS is a first-class, installer-supported option for both the boot pool and VM storage, with replication built into the cluster tooling. Run Unraid and the main array is its own parity system with individually-formatted data drives (XFS or Btrfs), with ZFS available for dedicated pools in recent versions — the appeal being exactly the mixed-drive, add-one-disk-at-a-time flexibility that classic ZFS lacked. Run Synology DSM and you get Btrfs layered on top of Linux md-RAID, which is a quietly clever design: md handles the parity RAID (sidestepping the Btrfs RAID 5/6 problem entirely) while Btrfs provides checksums and snapshots on top, and DSM wires the layers together for checksum-based repair.

So the realistic decision tree is short. Decide what you want to run — a storage appliance, a hypervisor, a flexible media box, an off-the-shelf NAS — and the filesystem mostly follows. Fighting the platform default (Btrfs on TrueNAS, or hand-rolled ZFS on a distro that makes it painful) buys you almost nothing and costs you the paved road. If you are still weighing the platforms themselves, that comparison matters more than the filesystem one.

Neither one replaces backups

The data-safety honesty section, because both communities occasionally oversell their filesystem. Snapshots are not backups. A snapshot lives on the same pool as the data; if the pool dies — controller failure, multiple drive failures, fire, theft, a destructive command — every snapshot dies with it. RAID is not a backup either. RAID keeps you online through drive failures; it does nothing against deletion, ransomware, or the enclosure itself failing. Checksums and scrubs protect you from the disks lying to you, and that is all they protect you from.

What both filesystems do give you is excellent raw material for real backups: schedule scrubs (monthly is a common cadence for a home NAS) so corruption is found while redundancy can still fix it, then use snapshot replication to get copies off the pool. The standard shape is the 3-2-1 rule: three copies of your data, on two different types of media or systems, with one copy off-site. A ZFS or Btrfs NAS replicating snapshots to a second box, plus an encrypted off-site copy through a dedicated backup tool, satisfies it. Nothing about either filesystem changes the rule.

FAQ

Is ZFS better than Btrfs?

For a dedicated multi-drive NAS, mostly yes: ZFS has mature parity RAID, a longer production track record, and stronger replication tooling. But better is workload-dependent. For a single-disk Linux machine, a root filesystem you want to snapshot, or a pool of mismatched drives you grow one disk at a time, Btrfs is the better fit — and it is the only one of the two in the mainline kernel. Both deliver the core promise of checksummed, self-healing, snapshot-capable storage.

Which file system is faster, ZFS or Btrfs?

It depends on the workload, and for home NAS duty both are fast enough that you will bottleneck on the network or the drives long before the filesystem. ZFS tends to win on repeated reads because its ARC cache is aggressive and effective when RAM is plentiful. Btrfs can struggle when nearly full or heavily fragmented, and copy-on-write hurts both of them on in-place rewrite workloads like databases and VM images without tuning. Neither filesystem is chosen for raw speed — if maximum throughput were the only goal, plain XFS would beat both. You choose these for integrity and snapshots.

Is ZFS the best filesystem?

It is the most battle-tested filesystem you can run for data integrity, and for its niche — a machine whose job is storing data safely — it is about as close to best as the word means anything. It is not the best everywhere: the out-of-tree licensing situation, the RAM appetite, and the historically rigid pool design make it a poor default for laptops, small single-disk boxes, and casual installs. Best filesystem is a workload question, and ZFS answers one workload extremely well.

Why not use Btrfs?

Three real reasons: you need parity RAID (RAID 5/6) and want it from the filesystem itself, in which case the long-standing write-hole caveats rule Btrfs out; you run heavy in-place-rewrite workloads and do not want to manage nodatacow exceptions; or you want native encryption and per-dataset administration, where ZFS is simply more complete. If none of those apply — and for a lot of home servers none do — the common objections to Btrfs are mostly aged folklore from its rough early years.

The bottom line

Both filesystems checksum your data, heal it when they can, and snapshot it for free — which already puts either of them far ahead of ext4 or XFS for storage you care about. Choose ZFS for the dedicated, planned, RAM-equipped NAS; choose Btrfs for flexibility, mixed hardware, and anything running a stock Linux kernel; and let your platform break the tie, because it usually already has.

If the platform question is the one you are actually stuck on, our TrueNAS vs Unraid comparison walks through exactly that decision. And since neither filesystem replaces real backups, the Kopia vs restic comparison covers the two best open-source tools for getting encrypted copies of your NAS off-site.

Last updated: August 2026.

Last updated: 2026-08-28