SnapRAID + MergerFS: Flexible Bulk Storage for Media Hoarders

I have a drawer. In it live disks of every capacity I have ever bought: a couple of 4 TB drives, a 6, a pair of 8s, a 12 that was on offer one Black Friday, and an ageing 3 TB I keep meaning to retire. Every media hoarder has this drawer. The problem it creates is well known: traditional RAID wants matched disks, punishes you for mixing sizes by sizing every member to the smallest one, and rebuilds by hammering every drive in the array at once. For a pile of films, TV, music and ISO images that mostly sit there being read occasionally, that is the wrong tool.

The right tool, for this specific job, is the combination of MergerFS and SnapRAID. MergerFS glues my drawer of mismatched disks into one enormous folder that applications see as a single mount. SnapRAID lays parity across them so a dead disk is recoverable and silent bit-rot gets caught. Each disk keeps its own ordinary filesystem, spins up only when touched, and can be pulled and read in any other machine. This post is how I run it, why the design fits bulk media so well, and where it will bite you if you use it for the wrong thing.

Why not just use RAID?

I want to be fair to RAID here, because for the right workload it is excellent and I use it elsewhere. The mismatch is specific to bulk media. Classic parity RAID and ZFS RAIDZ give you real-time redundancy, striping for throughput, and a single logical volume — all genuinely valuable when you are serving databases or VMs. They also impose costs that are pure downside for a pile of static films.

RAID stripes data across all members, so every disk must be identical in practice, and a rebuild reads every remaining disk in full under sustained load — which, as I found out the hard way in rethinking RAID when mirrors beat parity in a homelab, is precisely when a second, identically-aged disk tends to die and take the whole array with it. Every disk spins constantly because the data is striped across all of them, so a NAS serving one film keeps eight drives awake. And if you ever exceed your parity — two failures on a single-parity array — you do not lose the two dead disks’ worth of data, you lose everything, because the survivors are stripe fragments with no standalone meaning.

For static media that is read occasionally and where losing a few files is annoying rather than catastrophic, none of those trade-offs earn their keep. That is the gap SnapRAID plus MergerFS fills.

The mental model: two independent tools doing two jobs

The design that trips people up at first is that these are two separate tools solving two separate problems, and neither knows about the other.

MergerFS is a union filesystem. It takes several existing mounted disks and presents them as one combined directory tree. If disk 1 holds /Films/A-M and disk 2 holds /Films/N-Z, the merged mount shows all of /Films as though it were one volume. Each underlying file lives whole on exactly one disk — nothing is striped or split — so any disk can be unmounted, carried to another computer, and read on its own with a normal filesystem. MergerFS is the thing your media server, your file shares and your download client actually point at.

SnapRAID is parity protection computed on a schedule. It reads across your data disks and writes parity to one or more dedicated parity disks, plus content files holding a checksum of every block. When a data disk dies, SnapRAID reconstructs its contents from the parity and the surviving disks. When a scrub finds a checksum mismatch, it has caught bit-rot before it silently propagated into your only copy. Crucially, SnapRAID’s parity is a point-in-time computation, refreshed when you run snapraid sync, so it protects data that does not change between syncs. That single fact is the whole reason this pairing suits films and hurts databases.

The two combine cleanly: MergerFS pools the data disks for daily use, SnapRAID protects those same data disks using the parity disks that MergerFS deliberately excludes. The parity disk must be at least as large as your biggest data disk, which is the one sizing rule you cannot escape.

Setting it up

Assume five data disks mounted at /mnt/disk1 through /mnt/disk5, and one parity disk at /mnt/parity1. First, pool the data disks with MergerFS. On Debian or Ubuntu, apt install mergerfs, then add a line to /etc/fstab:

1

/mnt/disk*  /mnt/storage  fuse.mergerfs  defaults,allow_other,use_ino,cache.files=partial,category.create=mfs,minfreespace=50G  0  0

The options worth understanding: category.create=mfs places each new file on the disk with the most free space, which fills the pool evenly and keeps whole files intact on single disks; minfreespace=50G stops MergerFS from packing a disk completely full; use_ino makes inode numbers consistent across the pool, which some applications care about. Mount it with mount /mnt/storage and point your media server at /mnt/storage. Applications now see one big volume; each file quietly lives on one physical disk.

Next, install SnapRAID and describe your disks in /etc/snapraid.conf:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

# Parity — at least as big as the largest data disk
parity /mnt/parity1/snapraid.parity

# Content files (keep several copies, on different disks)
content /var/snapraid/snapraid.content
content /mnt/disk1/snapraid.content
content /mnt/disk2/snapraid.content

# Data disks (the ones MergerFS pools)
data d1 /mnt/disk1
data d2 /mnt/disk2
data d3 /mnt/disk3
data d4 /mnt/disk4
data d5 /mnt/disk5

# Don't try to protect junk
exclude *.unrecoverable
exclude /tmp/
exclude *.!sync

Run the first parity computation:

1

snapraid sync

That reads every data disk and writes full parity — slow the first time, incremental after. Then verify integrity periodically:

1

snapraid scrub -p 25 -o 10

That scrubs 25% of the array, skipping blocks checked in the last 10 days, so a monthly cron rolls through everything without hammering the disks in one go. When a disk dies, you replace it, mount the blank in the same place, and run snapraid fix -d d3 to rebuild only that disk from parity.

Automate the sync, and mind the window

The one operational discipline SnapRAID demands: parity is only as fresh as your last snapraid sync. Anything added since the last sync has no parity yet, so a disk failure loses those unsynced files. Automate a nightly sync so the exposure window is at most a day. The community snapraid-runner script wraps sync and scrub with sensible safety checks — notably, it aborts if too many files have disappeared since the last run, which catches the case where a disk silently unmounted and MergerFS started returning an empty tree that a naive sync would otherwise happily bake into parity as “all those files were deleted.”

A minimal nightly cron entry:

1

0 3 * * * /usr/bin/snapraid sync && /usr/bin/snapraid scrub -p 8 -o 10

Use the runner script in anything but the simplest setup, because its deleted-files threshold is exactly the guard that stops one bad night from corrupting your parity.

The critical caveat: this is not for changing data

Because parity is a point-in-time snapshot refreshed on sync, SnapRAID protects data that sits still between syncs. Films, TV, music, photos, archives, ISOs — write-once, read-many data — are the perfect fit, and losing at most one day of newly added files to an ill-timed failure is an acceptable risk for that content. Databases, virtual-machine images, active documents, anything rewritten continuously — those change faster than the parity can track, so at any given moment their parity is stale and a disk loss takes the current version with it. Keep that data on ZFS or a proper RAID with real-time redundancy, and reserve SnapRAID plus MergerFS for the bulk media it was designed for.

And to be completely clear about scope, because I have watched people make this exact mistake: none of this is a backup. SnapRAID recovers from disk failure; it does not save you from rm -rf on the merged mount, which deletes the real file and, after the next sync, updates parity to agree the file is gone. This is the same trap I laid out in snapshots are not backups — redundancy on the same machine is not an independent copy. Your irreplaceable data still needs a real off-machine backup on top of this.

Troubleshooting

snapraid sync reports a huge number of deleted files. Almost always a data disk failed to mount, so its directory looks empty. Do not proceed. Check mount and /etc/fstab, remount the disk, and only then sync. This is the failure the runner script’s threshold exists to catch.

MergerFS shows the pool but new files all land on one disk. Check category.create — the default may not be mfs, and a policy like epmfs (existing path, most free space) only writes to disks that already contain that directory. For even filling, mfs is usually what you want.

A file reads fine through a data disk but errors through the MergerFS mount. Usually a permissions or allow_other issue. Confirm allow_other is set and that user_allow_other is enabled in /etc/fuse.conf, or non-root processes cannot traverse the pool.

Scrub finds silent errors on an old disk. That is SnapRAID doing its job — it caught bit-rot. If the block is recoverable from parity, snapraid fix repairs it. Repeated errors on one disk mean that drive is dying; check smartctl -a /dev/sdX and replace it before it fails outright.

Parity disk is smaller than a new, larger data disk you just added. SnapRAID refuses, because parity must cover the largest member. Upgrade the parity disk first; it is the one drive whose size sets a floor for the whole array.

Verdict: is it worth it, and for whom?

If you are hoarding bulk media on a pile of mismatched disks and you keep hesitating over RAID because you do not want to buy matched drives or rebuild the whole array to add capacity, this is the setup I would hand you. You get one giant folder, the freedom to add any-size disk whenever a good deal appears, real parity protection against drive failure and bit-rot, disks that spin down when idle, and the reassurance that any single disk can be pulled and read in any machine. When a drive dies you rebuild only that one disk while the rest of the array keeps serving, and even a catastrophic multi-disk loss only costs you the data on the disks beyond your parity, because the survivors are still whole, readable filesystems.

It is the wrong tool for anything that changes constantly, where the snapshot-based parity leaves a stale window, and it is emphatically not a backup. If your workload is databases and VMs, or if you value real-time redundancy and pooled throughput over flexibility, look at ZFS or a full NAS OS instead — I compared the two mainstream options in TrueNAS Scale vs Unraid, and Unraid in particular ships a very similar flexible-disk philosophy in a polished package if you would rather pay for the GUI than assemble this yourself. For the specific job of a media drawer, though, SnapRAID and MergerFS have quietly run mine for years, and the drawer of mismatched disks finally stopped being a problem and became a feature.