Building a Redundant Raspberry Pi NAS: ZFS, mergerfs, and Snapshots Beyond Simple Samba Sharing

Setting up a Raspberry Pi as a file server with Samba — covered elsewhere on this site — gets a shared network drive up in an afternoon, but it leaves a real gap: a single USB drive with no redundancy means a single drive failure is a total data loss event, not an inconvenience. This guide covers the storage architecture layer underneath the file-sharing protocol — how to combine multiple drives into a redundant, snapshot-capable pool using ZFS or mergerfs, so the thing actually protecting your data is the storage layer itself, not just a good habit of copying files elsewhere occasionally.

Two Different Philosophies, Not Competing Products

ZFSmergerfs + SnapRAID Redundancy modelTrue RAID (mirroring or RAIDZ) — data and parity are actively managed togetherPooled storage (mergerfs) with periodic parity snapshots (SnapRAID) computed separately RAM requirementsMeaningfully higher — ZFS wants RAM for its ARC cache and checksumming; on a Pi this is a real constraint, not a suggestionMinimal — this is precisely why it's popular on low-power hardware Drive flexibilityDrives in a vdev should generally match in size — mismatched drives waste capacityMismatched drive sizes pool cleanly with no waste — a 2TB and a 4TB drive both contribute their full capacity Protection windowContinuous — any write is protected immediatelyOnly as current as your last SnapRAID sync — files added since the last sync aren't parity-protected yet Best fit on a PiRaspberry Pi 4/5 with 8GB RAM and USB 3.0 SSDs, when you want continuous protection and don't mind matched drivesAny Pi, especially with a mixed bag of drives you already own, when scheduled parity checks are an acceptable trade for lower resource use

Why This Isn't Just "Add RAID to the Samba Guide"

A Samba share is a network protocol sitting on top of whatever filesystem is underneath it — it has no opinion about redundancy at all. You can point Samba at a single unprotected USB drive or at a fully redundant ZFS pool and it will serve files identically either way; the protection (or lack of it) lives entirely in the storage layer below. This guide is specifically about building that layer correctly before Samba (or NFS, or Syncthing, or any other sharing method already covered on this site) ever gets involved.

Setting Up ZFS on Raspberry Pi OS

Use a Raspberry Pi 4 or 5 with at least 4GB RAM (8GB strongly preferred) — ZFS on a 2GB Pi Zero-class board is not a realistic combination.
Install the OpenZFS packages for Raspberry Pi OS (available via the zfs-dkms package on Debian-based Pi OS, though it requires building against your specific kernel — this is the most fragile step and worth doing on a fresh install before other services are running).
Identify your drives with lsblk and create a mirrored pool for two-drive redundancy: zpool create nasdata mirror /dev/sda /dev/sdb. For three or more drives with better space efficiency than mirroring, use RAIDZ1: zpool create nasdata raidz1 /dev/sda /dev/sdb /dev/sdc.
Set a conservative ARC cache limit so ZFS doesn't compete with everything else running on the Pi for memory — echo "options zfs zfs_arc_max=1073741824" | sudo tee /etc/modprobe.d/zfs.conf caps it at 1GB, a reasonable ceiling on an 8GB Pi running other services too.
Enable compression (zfs set compression=lz4 nasdata) — lz4 is fast enough that it's essentially free on a Pi's ARM cores and reduces both storage use and, often, actual disk I/O for compressible data.
Schedule scrubs (zpool scrub nasdata) monthly via cron — this is what actually catches silent data corruption (bit rot) before it becomes a real problem, and is one of ZFS's core advantages over a plain filesystem.

Setting Up mergerfs + SnapRAID Instead

Install mergerfs and SnapRAID from the standard repositories or their respective GitHub releases (both are lightweight enough to build or install directly on Pi OS without issue).
Mount your individual drives normally (ext4 is fine — this is the point of the mergerfs approach, no special filesystem required) and pool them: mergerfs /mnt/disk1:/mnt/disk2:/mnt/disk3 /mnt/nas -o defaults,allow_other,category.create=mfs, where category.create=mfs tells mergerfs to write new files to whichever drive has the most free space.
Dedicate one drive (sized at least as large as your largest data drive) purely to SnapRAID parity — this drive holds no files of its own, only parity data.
Configure snapraid.conf to list your data drives and parity drive, then run snapraid sync to build the initial parity data.
Schedule snapraid sync via cron (nightly is typical) so parity stays reasonably current — remember this is the tradeoff versus ZFS: anything written between syncs isn't parity-protected yet.
Run snapraid scrub periodically as well, which checks existing parity against stored checksums to catch corruption on data that hasn't changed recently.

Recovering From a Drive Failure

This is the entire point of the setup, and it's worth knowing the recovery procedure before you need it rather than during an outage:

ZFS mirror/RAIDZ: Replace the failed physical drive, then run zpool replace nasdata /dev/sda /dev/sdc (old device, new device) — ZFS resilvers (rebuilds) the replacement drive from parity or mirror data automatically while the pool stays online and usable.
mergerfs + SnapRAID: Replace the failed drive, then run snapraid fix -d disk2 (naming the failed drive) to reconstruct its contents from parity onto the replacement — this only recovers data current as of the last successful sync, which is the practical cost of the lighter-weight approach.

Snapshots: Protection Against Yourself, Not Just Drive Failure

RAID and parity protect against hardware failure. They do nothing against accidentally deleting a file, a ransomware event, or a bad rm -rf — the corrupted or deleted state gets faithfully protected right along with everything else. ZFS snapshots close this gap cleanly: zfs snapshot nasdata@daily-$(date +%F) taken on a cron schedule creates near-instant, near-zero-cost point-in-time checkpoints you can roll back to or browse via the pool's hidden .zfs/snapshot directory. mergerfs has no native snapshot equivalent — if snapshots matter and you've chosen the mergerfs/SnapRAID path for its lower resource use, pair it with a separate tool like rsnapshot or Restic (already covered on this site for backing up self-hosted services) to get comparable protection against accidental deletion.

Which One to Actually Choose

If you're running a Pi 4 or 5 with 8GB RAM, buying matched drives specifically for this project, and want continuous protection with minimal ongoing attention, ZFS is the more complete answer. If you're repurposing drives you already own in mismatched sizes, running on more constrained hardware, or want to understand exactly what's protected and when rather than trusting a black box, mergerfs plus SnapRAID with disciplined scheduled syncs is a legitimate, lighter-weight alternative that plenty of long-running home NAS setups use successfully. Either one turns "a folder shared over Samba" into an actual storage system — the file-sharing layer on top stays exactly the same either way.

Related Guides

Loading_