SnapRAID is a free, open-source backup program for disk arrays that stores parity data on dedicated drives so you can rebuild the full contents of failed disks, guard against bit rot, and even undelete files.
If you have ever wondered what is SnapRAID and why so many home lab builders swear by it, the short version is this: it gives you RAID-style recovery without the rigidity of a real RAID array. Your disks stay independent, readable, and mismatched in size if that is what your budget looks like.
That combination is why it has become a staple for people archiving large datasets, public domain archives, Linux distributions, and lossless media libraries that rarely change after they land on disk.
It is not a live redundancy system. Parity is calculated when you tell it to, usually on a nightly schedule, which is exactly what makes it a poor fit for busy databases and an excellent fit for a growing archive.
SnapRAID at a Glance
SnapRAID is licensed under GPLv3, runs on Windows, Linux, and BSD, and can protect against up to six simultaneous disk failures depending on how many parity disks you assign. It was built with home media centers and large archive arrays in mind, not transactional workloads.
What Is SnapRAID Best Suited For?
The sweet spot is any collection of large media files and archival data that gets added to often but edited rarely. Think image backups, research datasets, family photo archives, and software repositories.
In our experience running it on a mixed array, the best results come when writes are additive. New folders arrive, old ones sit untouched, and each nightly parity update stays quick.
It is a poor choice for virtual machine images, active databases, or anything writing thousands of small changes per hour. Those files churn between snapshots, and parity for them is stale almost immediately.
Snapshot-Based Protection Rather Than Live Redundancy
Traditional arrays write redundancy at the same instant you write data. SnapRAID instead scans your data disks on demand, calculates parity for what it finds, and stores that result on a separate parity disk.
The practical effect is a point-in-time safety net. Everything present at the last sync is recoverable; anything added since is not yet covered.
That tradeoff buys you something valuable: only one disk needs to spin to read a file, which cuts noise, power draw, and wear compared to systems that engage every drive on every read. For a large archive that mostly sits idle, that energy efficiency adds up over the years.
How Snapshot Parity Protects Data
Parity is math, not a copy. SnapRAID reads across your data disks, computes parity information, writes it to a parity file, and records file hashes in a content file so it can verify integrity later.
Parity Data and the Largest-Disk Rule
The single hard rule: each parity drive must be at least as large as your biggest data drive. Parity is calculated block by block across disks, so it has to be able to represent the largest one.
That rule cuts both ways. If you pair a 6TB parity disk with three 2TB data disks, most of the parity disk sits unused.
| Setup | Parity disks | Failures survivable |
|---|---|---|
| 4 data drives, 1 parity | 1 | 1 |
| 6 data drives, 2 parity | 2 | 2 |
| 10 data drives, 3 parity | 3 | 3 |
A useful habit we follow: buy the largest drive first and dedicate it to parity, then feed smaller or older disks into the data side as they become available.
Checksums, Silent Corruption, and Data Integrity
Every file gets hashed during a sync, and those checksums live in the content file. That checksumming is what separates SnapRAID from a simple parity script.
Bit rot rarely announces itself. A file opens fine for years, then one day a chunk of it is garbage and no drive reported an error.
Because SnapRAID knows the expected hash of every file, a scrub can flag silent corruption and repair the damaged blocks from parity information. On our array, that has caught more real problems than outright drive failures have.
How It Compares With Traditional RAID
The core difference is architectural. Traditional RAID binds disks into one logical volume; SnapRAID leaves each disk standing alone with a parity layer bolted on top.
Independent Disks Versus Striped Storage
In RAID 5, data is striped across every member disk. Pull a disk out and plug it into another machine and you get nothing readable.
With SnapRAID, each data disk holds complete files in a normal filesystem. Mount one anywhere and the files are simply there, even with SnapRAID uninstalled.
That means no reformatting to get started, no lock-in when you stop, and no all-or-nothing failure mode. If failures exceed your parity count, loss is confined to the affected disks and the rest of the array stays intact.
When RAID 5, ZFS, or SnapRAID Fits Better
Each tool solves a different problem, and picking wrong is the most common mistake we see.
- RAID 5 suits workloads needing continuous uptime and real-time redundancy, with identical disks and a rebuild window you can tolerate.
- ZFS is the strongest choice for live data integrity, snapshots, and self-healing, but expects planned vdevs and matched capacities.
- SnapRAID wins for large, mostly static archives built from mismatched drives you add over time.
Growth flexibility is the deciding factor for most data hoarders. Adding a single odd-sized disk to a ZFS pool is awkward; adding one to a SnapRAID config takes two lines in a text file and one sync.
Energy efficiency tips the same direction. A 12-disk archive that spins one drive per read behaves very differently from one that wakes the whole shelf.
Planning a Flexible Archive Array
A working stack usually has two halves: SnapRAID for parity and MergerFS for presenting all those separate disks as one folder tree. Getting the layout right up front saves painful migrations later.
Combining MergerFS Pooling With SnapRAID Parity
MergerFS unifies your data drives into a single mount point, so applications see one large path instead of a dozen. SnapRAID then protects the underlying disks individually.
Never include a parity drive in the MergerFS pool. If you do, files get written to it as ordinary data and your parity protection quietly disappears.
We keep data disks mounted under paths like /mnt/disk1 through /mnt/disk8, pool those into /mnt/storage, and mount parity separately at /mnt/parity1. On Debian and Ubuntu, both packages install cleanly from the repositories, and the whole setup lives in fstab plus one config file.
Choosing Data Drives, Parity Drives, and Content File Locations
Your snapraid.conf lists parity paths first, then content file locations, then each data disk. Order and labels matter, since renaming a disk later confuses the array.
Guidelines that have served us well:
- Dedicate the largest drive to parity, always.
- Keep at least two or three copies of
snapraid.content, spread across different disks. - Store one content copy on the system drive, outside the array.
- Exclude temp folders, cache directories, and anything that changes constantly.
- Use stable mount points, ideally by UUID, not by device letter.
Losing every content file at once means losing your integrity database, so redundancy there is cheap insurance.
Maintaining Parity and Detecting Problems
SnapRAID rewards routine. Two commands do most of the work: snapraid sync to bring parity up to date and snapraid scrub to verify what is already stored.
Sync Schedules and the Window of Unprotected Changes
Parity updates only happen when you run them, so everything added since the last sync sits unprotected. A nightly cron job at a quiet hour keeps that window to roughly 24 hours.
For heavy ingest periods, we run a sync manually after large batches land. It costs a few minutes and removes the risk of losing a day of work.
A word of caution: never sync blindly after deleting large amounts of data. Most maintenance scripts include thresholds that abort the run when too many files have changed, which preserves your ability to undelete.
Scrubs, Health Monitoring, and the SnapRAID Daemon
Scrubs read back a percentage of your array and compare it against stored checksums. Scrubbing 8 to 15 percent weekly rotates through the whole array over a few months without hammering the disks.
Newer releases add the SnapRAID Daemon, which moves this from cron scripts to an always-on service. It handles background scrubbing and health monitoring, exposes a Web UI dashboard, and offers a REST API for integration with other home lab tooling.
If you expose that interface beyond localhost, put it behind SSL and authentication. The same privacy discipline we write about elsewhere on datahoarder.io applies to your storage dashboards, not just your network traffic.
Recovery Boundaries and a Complete Protection Plan
Parity is not a backup, and that distinction matters when something goes wrong. SnapRAID handles disk failure and corruption well; it does not handle fire, theft, ransomware, or a mistaken delete followed by an automatic sync.
Rebuilding After Disk Failure With SnapRAID Fix
When a drive dies, you install a replacement, mount it at the same path, and run snapraid fix targeting that disk. Parity information plus the surviving data disks rebuild the lost contents file by file.
Recovery is bounded by your parity count. One parity disk survives one failure; six parity disks survive six simultaneous disk failures.
Rebuilds on large drives take hours, sometimes over a day. It reads every other disk in the array, which is precisely when a second marginal drive tends to give up, so replace disks at the first sign of trouble rather than the last.
Why Off-Array Backups and Recovery Tests Still Matter
Everything sitting in one chassis shares one fate. Keep genuinely irreplaceable digital assets, personal documents, photos, and original work, on a second copy somewhere else.
Test that copy. Restoring a handful of random files once a quarter has caught more broken backup jobs in our setups than any monitoring alert ever did.
Re-acquirable material is different. For public domain archives, Linux distributions, and other published archival data, a premium Usenet provider with deep retention and fast completion, such as Newshosting or Easynews, is often the most practical way to rebuild a collection after a loss, which frees your backup budget for the files that truly cannot be replaced.
More DIY NAS guides
- DIY NAS build guide (start here)
- SnapRAID + MergerFS build
- SnapRAID vs Unraid
- ZFS vs BTRFS
- Best NAS cases
- Shucking hard drives
- IronWolf vs WD Red
- 4-bay vs 8-bay NAS