Your Media Library Doesn’t Need Real-Time RAID
Let’s be honest about what your Plex or Jellyfin server actually does. It sits there. Occasionally someone in your household watches something. Maybe once a week you rip a new Blu-ray or download a few episodes of whatever everyone’s talking about. Then it sits there again.
That’s it. That’s the workload.
And yet somehow people end up running mdadm RAID 6 on six identical drives, or spinning up TrueNAS with ZFS because “data integrity.” Both of those tools are excellent — for different jobs. Running RAID 6 on a cold media archive is like hiring a full-time security guard to watch a storage unit you visit twice a month. Technically correct. Wildly overkill.
Full example: Clone the working files at github.com/KingPin/sumguy-examples/linux/snapraid-parity
SnapRAID is the answer to a question most people don’t think to ask: what if parity protection didn’t have to be real-time?
What SnapRAID Actually Is
SnapRAID is not a filesystem. It’s not a block device. It doesn’t sit between your kernel and your drives pretending to be a single disk.
It’s a command-line tool that reads the files on your data drives, calculates parity information, and writes that parity to a dedicated parity drive. You run snapraid sync on a schedule — nightly, usually — and it updates the parity to reflect whatever changed since last time.
That’s it. Async, file-level, scheduled parity.
The payoff is that each of your data drives is completely normal. Formatted with ext4 or XFS, mounted normally, readable by any Linux machine with no special software. If you pull a data drive out of your array and plug it into another machine, you can read every single file on it directly. No array state to reconstruct. No pool to import. Just files on a drive.
This is the complete opposite of mdadm RAID 5, where the data is striped across drives and you need the whole array intact to read anything. (We covered how that works in RAID 0, 1, and 5: Pick One.)
The Mismatched-Drive-Size Advantage
Here’s where SnapRAID does something that makes ZFS and mdadm users uncomfortable: it doesn’t care about drive sizes.
You can have:
- 6 TB data drive
- 8 TB data drive
- 4 TB data drive
- 4 TB data drive
That’s 22 TB of raw storage across drives you probably accumulated over several years, buying whatever was on sale. In mdadm, this is a nightmare — RAID 5 treats every drive as if it’s the smallest one, so you’d get 4×4 TB = 16 TB, wasting 6 TB of perfectly good space. (We covered nested RAID trade-offs in RAID 50 vs 60: Nested RAID Explained and RAID-Z and dRAID Explained.)
In SnapRAID, drives contribute their full capacity. All 22 TB.
The one rule: your parity drive must be at least as large as your largest data drive. In the example above, that 8 TB data drive means you need at least an 8 TB parity drive. The parity drive doesn’t add to your usable pool — it’s purely overhead for recovery — but you only need one, and it just needs to be big enough to cover the largest data drive.
Data drives: 6 TB + 8 TB + 4 TB + 4 TB = 22 TB usableParity drive: 8 TB (must be ≥ largest data drive)Total disks: 5 drives, 22 TB usable, 1 drive failure toleranceIf you add a second parity drive, you can survive two simultaneous drive failures — same logic as RAID 6, without the matching-size requirement.
SnapRAID + MergerFS: The Unified Pool
Here’s the one thing SnapRAID doesn’t give you out of the box: a single mountpoint. Your data lives on /mnt/data1, /mnt/data2, /mnt/data3, and /mnt/data4. Plex doesn’t love that.
Enter MergerFS — a FUSE-based filesystem that unions multiple directories into a single mountpoint. Files still live on individual drives underneath. MergerFS just makes it look like one big drive.
The fstab entry looks something like this:
/mnt/data1:/mnt/data2:/mnt/data3:/mnt/data4 /mnt/storage fuse.mergerfs defaults,allow_other,use_ino,cache.files=off,dropcacheonclose=true,category.create=mfs,moveonenospc=true,minfreespace=4G,fsname=mergerfs 0 0category.create=mfs tells MergerFS to put new files on the drive with the most free space. moveonenospc=true handles the edge case where a drive fills up mid-write by moving the file to another drive automatically. The full example with comments is in the mergerfs-fstab.example file in the repo.
The result: Plex and Jellyfin see /mnt/storage and get a unified 22 TB library. SnapRAID protects the actual drives underneath. Each drive is still independently readable if you need to pull it out.
This combination — SnapRAID for parity, MergerFS for pooling — is what Unraid has been selling for years, just packaged as a paid OS. You’re doing the same thing on plain Debian or Ubuntu, for free.
What You Give Up
No hand-waving here: SnapRAID’s async nature is a real trade-off, and you should understand it.
Between sync runs, new or changed files are not protected by parity. If you sync at 2 AM nightly and a drive dies at 1:45 AM, files written since the last sync are gone. The parity only knows what existed as of the last snapraid sync.
For a home media archive, work out what that actually means: you add a few episodes on Sunday afternoon, and the nightly sync runs at 2 AM. Those files are unprotected for roughly 10 hours. If a drive dies in that window — which, statistically, is an unusual failure mode; drives don’t usually die mid-week after you specifically just added files — you lose those files.
That’s the exposure. For a media library of mostly-static content that changes a few times a week, this is a non-issue in practice. You re-download the episodes or re-rip the disc. Nobody cried.
If you’re the type who adds media constantly, or you want protection for actively-written files, run snapraid sync more frequently — every hour is fine. Or accept that SnapRAID isn’t the right tool.
When SnapRAID Beats mdadm and ZFS
SnapRAID wins when:
- Your collection is mostly static. You read more than you write. Media archives, photo libraries, finished project backups.
- Your drives are mismatched. You accumulated 4 TB and 8 TB and 6 TB drives over time and don’t want to waste capacity on lowest-common-denominator striping.
- You want each drive independently readable. Pull a drive out, plug it in anywhere, read the files. No array state required.
- You don’t want to transcode your storage layer. mdadm and ZFS have overhead. SnapRAID’s “overhead” is a nightly cron job.
- You’re running on plain Debian or Ubuntu and don’t want to adopt a whole NAS OS. (Though TrueNAS, OMV, and Unraid all have their merits — see the TrueNAS vs OMV vs Unraid comparison if you’re on the fence.)
When SnapRAID Loses
Don’t use SnapRAID for:
- Databases. Postgres, MySQL, anything with frequent random writes and no tolerance for recovery gaps. Use ZFS with proper RAID-Z for that. (ZFS RAID-Z and dRAID explained here.)
- VM disk images. A VM disk changes constantly. Async parity for something that writes 1,000 times a day is protecting a snapshot, not your live data.
- Anything latency-sensitive. SnapRAID adds no read or write latency — your drives are just mounted normally — but recovery from a drive failure requires a rebuild process, not automatic failover.
- Hot storage. If your drives are your primary working storage and files change frequently, the exposure window becomes meaningful.
For those workloads, check out ZFS vs Btrfs and decide which copy-on-write filesystem fits your threat model.
Setup Walkthrough
Install SnapRAID and MergerFS:
# Debian/Ubuntusudo apt install snapraid mergerfs
# Verifysnapraid --versionMount your drives. Each data drive gets its own mountpoint:
sudo mkdir -p /mnt/data{1,2,3,4} /mnt/parity /mnt/storageAdd them to /etc/fstab using UUIDs (get them with blkid), then create /etc/snapraid.conf:
# Parity drive — must be >= largest data driveparity /mnt/parity/snapraid.parity
# Content files — SnapRAID writes metadata here (one per data drive + one extra)content /var/snapraid/snapraid.contentcontent /mnt/data1/snapraid.contentcontent /mnt/data2/snapraid.content
# Data drives — label them however you wantdata d1 /mnt/data1data d2 /mnt/data2data d3 /mnt/data3data d4 /mnt/data4
# Exclude OS noiseexclude *.bakexclude *.tmpexclude /lost+found/exclude .Trash-*/First sync (this takes a while — it’s computing parity for your entire library):
sudo snapraid syncCheck status any time:
sudo snapraid statusFor periodic data integrity validation:
# Scrub 5% of data (good for weekly cron)sudo snapraid scrub -p 5The full snapraid.conf.example in the repo has all options with comments. The sync-cron.sh script does snapraid diff first to sanity-check the delta before committing a sync — so if 90% of your files appear to have changed (which would suggest something went wrong), it aborts instead of blindly overwriting your parity.
Schedule the sync script:
sudo crontab -e# Run nightly at 2 AM0 2 * * * /usr/local/bin/snapraid-sync.shReal Talk
The Unraid community has been quietly right about this pattern for years. A parity drive you update on a schedule, with all your data drives independently readable, is genuinely the right architecture for home media storage. It’s boring. It works. Drive dies, you run snapraid fix, you rebuild, you move on.
SnapRAID gives you the same model on plain Debian with no licensing fees and no lock-in. Pair it with MergerFS and you have a setup that looks like Unraid from the outside and stays completely transparent at the drive level.
Your 2 AM self — the one staring at a dead drive — will thank you for not having an entire ZFS pool to import or a RAID array to rebuild stripe by stripe. They’ll just mount the other drives, run the recovery, and go back to bed.
That’s the dream. SnapRAID gets you there.
