SnapRAID and mergerfs are the answer the DIY side of the data hoarding community reaches for instead. They’re two separate, unrelated tools that happen to solve complementary halves of the same problem, and understanding that they’re separate is the first thing to get straight before touching either one.

Two different jobs, not one tool

mergerfs is a union filesystem. It takes several separate drives, each with their own independent filesystem (ext4, XFS, whatever), and presents them to the rest of the system as one merged mount point. Copy a file into /mnt/pool/movies/, and mergerfs decides which underlying drive actually gets the write based on a policy you configure (most free space, least used, and so on). Nothing is striped or split. Every file lives whole on exactly one physical drive. That last part matters a lot for the recovery story later.

SnapRAID is a parity tool. It doesn’t pool anything and doesn’t know or care that mergerfs exists. Point it at a set of data drives and one or more dedicated parity drives, and on a schedule you control, it computes parity data across the pool and writes it to the parity drive(s). If a data drive dies, SnapRAID uses the parity data plus whatever’s left on the surviving drives to reconstruct the dead drive’s contents onto a replacement.

Run them together and you get what looks, from the outside, like a single large redundant volume: one mount point (from mergerfs) that survives a drive failure (thanks to SnapRAID), built entirely out of mismatched drives you bought at different times for different prices. That’s the whole appeal, and it’s a real one for exactly the audience this site is written for.

Why this isn’t RAID, and the tradeoff that follows from it

Real RAID (and ZFS) computes and writes parity synchronously, on every write, in real time. The moment data hits disk, it’s protected. SnapRAID computes parity on a schedule, usually a nightly cron job (snapraid sync), which means there’s a window between “I wrote a new file” and “that file is actually covered by parity.” Anything written since the last sync and lost before the next one, an accidental deletion, a drive dying mid-session, isn’t recoverable from parity. It’s the difference between a smoke detector that’s always listening and one you have to manually arm once a day.

This is a deliberate, acceptable tradeoff for the workload SnapRAID is built for: large, mostly-static files that get written once and then sit there. Media libraries are the canonical case (this pairs naturally with the folder conventions in the media library structure guide and feeds straight into the *arr stack if that’s how content lands on the pool). It is a bad fit for anything with constant small writes: databases, VM disk images, a Nextcloud data directory syncing every few minutes, an actively-recording security camera NVR. Point SnapRAID at that kind of workload and you’ll either sync constantly (defeating the point, since sync itself is I/O-heavy and reads every changed block) or accept a rolling window of genuinely unprotected data. If most of what you’re storing changes constantly, this isn’t the setup for you, look at ZFS or a real RAID array instead.

Mismatched drives, but not unlimited mismatch

SnapRAID’s one hard requirement: every parity drive must be at least as large as the single largest data drive in the array. Data drives themselves can be any size, any mix of manufacturers, any mix of ages, that’s the entire point. But if your biggest data drive is 16TB, your parity drive needs to be 16TB or larger, because parity data for the largest possible file set has to fit on it. People who add a new, bigger drive to the array every year or two eventually hit the point where their old parity drive is now smaller than the newest data drive, and have to upgrade parity storage to keep pace. Plan for that when you buy your first parity drive: buying one a size class above your current largest data drive buys headroom before you’re forced into an unplanned parity upgrade.

You can run more than one parity drive (SnapRAID supports up to six), which buys protection against multiple simultaneous drive failures, the same idea as RAID 6’s dual parity, at the cost of a second (or third) drive doing nothing but holding parity data. Most home setups run single parity and accept the risk of a second drive dying during a rebuild window, the same bet most RAID 5 users make.

What sync and scrub actually do

Day to day, this setup runs on two commands, both meant to be cron jobs, not something you run by hand each time:

snapraid sync compares the current state of the data drives against SnapRAID’s last-known state, recomputes parity for anything that changed, and writes the updated parity plus a content file (a manifest of what’s where, stored redundantly across drives so losing one drive doesn’t lose the map). This is the step that closes the “just wrote a file” protection gap, run it nightly at minimum, more often if you can tolerate the I/O.

snapraid scrub is the corruption-detection half, conceptually similar to the ZFS scrub covered in the bit rot guide, except SnapRAID does it by re-reading a percentage of the array each run and checking data against stored hashes, rather than continuously like ZFS’s checksumming does on every read. Run it on a rolling schedule (SnapRAID’s own defaults scrub roughly the oldest 10% of data each run) so the whole array gets checked periodically without one giant read pass hammering every drive at once.

Neither command touches mergerfs. The pooling layer and the parity layer are genuinely independent, which is also why recovery is straightforward to reason about: because every file lives whole on one physical drive (mergerfs never splits or stripes a file across drives), losing one drive only ever costs you the files that were on that specific drive, and SnapRAID reconstructs exactly those files onto a replacement. You’re never staring at a fully unreadable pool the way a failed RAID 0 or a badly degraded RAID 5 can leave you.

Setting it up, the practical shape of it

The full step-by-step is beyond one article, but the shape of a working setup looks like this:

1. Format each data drive and the parity drive(s) independently, normal filesystems (most people use XFS or ext4), no special RAID-aware formatting needed since none of these drives are actually in a RAID.
2. Mount each drive somewhere predictable (/mnt/disk1, /mnt/disk2, /mnt/parity, that convention).
3. Configure snapraid.conf pointing at each data disk and parity disk, plus exclusion patterns for things you don’t want covered (temp files, thumbnail caches, anything mergerfs itself might generate).
4. Run an initial snapraid sync to build the first full parity set, expect this to take hours on a large existing library since it has to hash and parity-compute everything, not just new files.
5. Configure mergerfs to pool the same data disks (not the parity disk, parity is never part of the pooled mount) at a single mount point, with a branch policy that suits how you write data, most people run mfs (most free space) or epmfs (existing path, most free space) so new files land on whichever drive has room rather than always hammering one disk.
6. Point your applications (Plex, Jellyfin, the *arr stack, whatever’s writing to the pool) at the mergerfs mount, not at the individual drives directly.
7. Cron both snapraid sync and snapraid scrub on a schedule and actually check the logs, a parity setup nobody monitors is a parity setup that silently stops protecting anything the day a cron job starts failing.

Where TrueNAS or Unraid still make more sense

The TrueNAS vs Unraid vs bare Linux guide on this site already covers the OS-level decision, but it’s worth being direct about where SnapRAID plus mergerfs specifically fits versus those platforms. Unraid’s built-in array does something conceptually similar (mismatched drives, per-file storage, parity protection) with a polished UI and none of the manual config file editing, at the cost of its license fee. TrueNAS with ZFS gives up the mismatched-drive flexibility entirely in exchange for real-time protection, continuous checksumming on every read, and no sync-window gap at all. SnapRAID and mergerfs sit in between: free, genuinely flexible on drive sizes, and honest about trading real-time protection for that flexibility. If you’re the kind of hoarder who buys whatever drive is cheapest per TB this month rather than planning a matched pool in advance, and your data is mostly write-once media rather than constantly-mutating working files, this is the setup built for exactly that habit.