ZFS vs Btrfs vs Stratis: Best Homelab NAS Filesystem?

Your homelab has grown beyond a single disk. You need a proper NAS, a backup target, or just a resilient place to store VM images. Sticking with ext4 on mdraid feels archaic. You need snapshots, you need data integrity, and you don’t want to lose your data to bit rot.

The three main contenders in the modern Linux storage space are ZFS, Btrfs, and Stratis. Each promises a better way to manage disks, but they get there through very different philosophies. Choosing the right one depends entirely on what you’re trying to achieve, what hardware you have, and how much you trust the code.

The Contenders: A Quick Intro

• ZFS: The battle-hardened veteran from Sun Microsystems, now maintained by OpenZFS. It’s a combined logical volume manager and filesystem. Its reputation for data integrity is legendary. It’s the default choice for systems like TrueNAS and is a first-class citizen in Proxmox. It’s powerful, but it has its own way of doing things.
• Btrfs: The “better filesystem” that’s been in the Linux kernel for years. It’s also a combined volume manager and filesystem, offering features like ZFS but with more flexibility. Its history is a bit rocky, especially regarding its RAID5/6 implementation, which still spooks many admins (myself included).
• Stratis: The new kid on the block, primarily from Red Hat. Stratis isn’t a filesystem: it’s a storage manager that builds pools from block devices using device-mapper (thin provisioning underneath) and puts XFS filesystems on top. It aims for ZFS-like management simplicity using mature kernel components.

Feature Showdown: Integrity, RAID, and Snapshots

Let’s cut to the chase. These are the features that matter for a homelab NAS.

Data Integrity: The Whole Point

This is the number one reason to ditch ext4. Silent data corruption (bit rot) is a real phenomenon where bits on your storage media flip spontaneously over time. Without checksums, you’ll never know your family photos are corrupted until you try to open them.

• ZFS: Copies-on-write (CoW) and checksums everything: user data and metadata. If you have a redundant array (like a mirror or RAID-Z), ZFS will detect a corrupt block during a read, find the good copy on another disk, serve it to you, and fix the bad block in the background. This is called self-healing, and it is the gold standard.
• Btrfs: Also uses CoW and checksums everything. It provides the same self-healing capability as ZFS on redundant arrays. On the integrity front, it’s a direct competitor and works extremely well.
• Stratis: XFS doesn’t checksum user data. Recent Stratis versions can add block-level integrity metadata (dm-integrity) to a pool’s devices at creation (stratis pool create --integrity ...), which detects corruption. But without redundancy in the pool, it can’t repair it the way ZFS or Btrfs can from a mirror.

RAID Implementation: Flexibility vs. Rigidity

Building a redundant array is fundamental for a NAS. The approaches here could not be more different.

• ZFS: RAID is built-in. You create virtual devices (vdevs), such as a mirror (RAID1), raidz1 (RAID5-like) or raidz2 (RAID6-like), and add them to a storage pool. It’s very robust and traditionally rigid: for years you couldn’t add a single disk to a RAID-Z vdev. OpenZFS 2.3 added RAIDZ expansion, so you can now grow a RAID-Z vdev one disk at a time (existing data keeps its old parity ratio until rewritten). Mirrors and adding whole vdevs remain the simplest ways to grow a pool.
• Btrfs: RAID is also built-in but is far more flexible. You can create a RAID1 array with two disks, then add a third disk later and rebalance the array to include it. You can even mix disk sizes, though it complicates capacity calculations. This flexibility is a huge win for homelabbers who often expand with whatever drives are on sale. The massive caveat is the RAID5/6 implementation. The infamous “write hole” bug and data loss horror stories have destroyed its reputation. While it’s supposedly much better now, the official Btrfs wiki still says “Unstable”. Stick to RAID1 or RAID10.
• Stratis: Does not have its own RAID. It’s a volume manager, not a RAID engine. The expectation is that you’ll use Linux’s proven mdraid for redundancy. You create your md array first, then create a Stratis pool on top of that /dev/mdX device. This is a modular approach: use the best tool for each job. It’s reliable but adds another layer to manage.

Snapshots & Replication: The Backup Killer Feature

Point-in-time snapshots are crucial for recovering from “oops” moments or ransomware. The ability to efficiently send those snapshots to another server is what elevates a filesystem to a true backup solution.

• ZFS: Atomic, instant, and cheap snapshots are a core feature. The killer app is zfs send and zfs recv, which allows you to send an incremental (or full) copy of a snapshot to another ZFS pool, even over SSH. Tools like sanoid and syncoid automate this beautifully, creating a perfect push/pull backup system.
• Btrfs: Also has excellent, cheap, and instant snapshot capabilities. It has its own btrfs send and btrfs receive commands that function almost identically to their ZFS counterparts. For snapshots and replication, it’s on par with ZFS.
• Stratis: Supports filesystem snapshots, built on device-mapper thin provisioning. They work for local point-in-time recovery, but there’s no send/receive replication, so replicating to another machine means rsync or similar. That’s a dealbreaker for using Stratis as a primary backup target.

A Practical Example: Creating a Mirrored Pool

Assume you want a simple two-disk mirror with /dev/sda and /dev/sdb.

# ZFS: pool with a mirror vdev; datasets are mounted automatically
zpool create tank mirror /dev/sda /dev/sdb
zfs create tank/data            # mounted at /tank/data

# Btrfs: RAID1 for data and metadata; you mount it yourself
mkfs.btrfs -d raid1 -m raid1 /dev/sda /dev/sdb
mkdir -p /mnt/btrfs
mount /dev/sda /mnt/btrfs       # either device works

# Stratis: no mirroring of its own. Build the mirror with mdraid first...
mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sda /dev/sdb
# ...then put the Stratis pool on the md device
stratis pool create mypool /dev/md0
stratis filesystem create mypool myfs
mkdir -p /mnt/myfs
mount /dev/stratis/mypool/myfs /mnt/myfs

Warning: stratis pool create mypool /dev/sda /dev/sdb without mdraid does not mirror anything: it pools the two disks’ capacity, and losing either disk loses the pool.

The Verdict: Which One Should You Choose?

There’s no single “best” option. It’s about tradeoffs.

• Choose ZFS if: You want the most reliable, battle-tested solution for a NAS or hypervisor storage. You are building a system and don’t plan to change the disk layout frequently. The rock-solid data integrity, self-healing, and amazing send/recv feature make it the top choice for critical data. This is what you should use with Proxmox or for your primary backup server. Just make sure you have enough RAM (1GB per TB of storage is a decent rule of thumb, but it can run on less).

• Choose Btrfs if: You value flexibility above all. You want to easily add and remove drives of different sizes from your array. Your use case is a Linux desktop, a single-drive server needing snapshots, or a multi-drive array using RAID1 or RAID10. The performance can be spiky for database or VM workloads, but for general file storage, it’s great. Stay away from its RAID5/6.

• Choose Stratis if: You are heavily invested in the Red Hat ecosystem (Fedora, RHEL, CentOS) and want a simpler way to manage storage volumes with data integrity. You trust XFS and mdraid and just want a better user interface on top. It’s a good LVM replacement, but its lack of integrated RAID and replication makes it a poor choice for a multi-drive NAS or a dedicated backup server compared to ZFS.

A common homelab split: ZFS for the Proxmox host and the primary NAS. The reliability is worth the initial learning curve. Btrfs on a laptop, for snapshots on a single drive. Stratis is the niche choice: it makes most sense on RHEL-family systems where it’s the supported option.

What’s Next

Once you’ve settled on a filesystem, you’ll need to think about the rest of your storage and backup strategy.

• Stratis on Linux: ZFS-Like Storage, Less Complexity
• Proxmox VE Homelab Setup: Install and Configure (2026)
• AWS S3 + Restic: Homelab Backups Under €2/Month