Master the Basics - How to Install and Use SnapRAID for a Resilient Home Media Server

Why You Need SnapRAID with MergerFS

You’ve spent years building the perfect media collection. Movies, TV shows, music, personal backups, all neatly spread across a stack of hard drives. Then one day you hear that clicking sound coming out of the server. Panic. Did you lose everything on that drive? Not if you planned ahead.

That’s where MergerFS and SnapRAID come in. MergerFS pools multiple drives into one logical storage location, and SnapRAID adds parity so you can recover from a drive failure. If you haven’t set up MergerFS yet, start with my Master the Basics - MergerFS post. Together they give you a cheap, flexible way to protect your data without the headaches of traditional RAID.

SnapRAID is a parity-based protection system. Unlike traditional RAID, it doesn’t constantly write to every disk. That makes it a good fit for media servers, where most of your data sits unchanged for months at a time.

I’ve been running this setup on my own Debian-based media server with a mix of mismatched drives, and it’s saved me from at least one dying disk. Here’s how to install and configure it.

What is SnapRAID Parity?

SnapRAID parity is the backbone of the whole thing. It works by creating a file containing mathematical parity data about the files on your data disks. If a drive dies, SnapRAID uses that parity file to reconstruct what was on it.

Think of parity as an insurance policy for your media collection. If one of your drives crashes, the parity file is the blueprint that lets SnapRAID rebuild the missing data using the remaining disks.

How SnapRAID Parity Works

Parity calculation: SnapRAID scans your data disks and calculates parity based on their contents. The result lives on a dedicated parity disk, separate from the data drives.
Parity updates: Parity does not refresh on its own. You run snapraid sync when you want it updated. I’ll cover automating that with cron later.
Drive recovery: When a data disk fails, SnapRAID uses the surviving data drives plus the parity disk to rebuild the lost files. More parity disks means more simultaneous failures you can survive.

Why SnapRAID Parity Matters

It protects against drive failures

The whole reason to run SnapRAID is data redundancy. Without parity, a dead drive means everything on that disk is gone. With parity, you can recover it.

It saves space compared to full backups

Parity stores difference-based data, not a full copy of every drive. One parity drive can protect several data drives. That’s a lot cheaper than mirroring everything.

It scales with your storage

You can mix and match different-sized disks. No need for identical drives like traditional RAID. Start with one parity drive and add more as your array grows.

You can run multiple parity drives

One parity drive recovers from one failed disk. Add more if you want more cushion:

1 parity drive → recovers from 1 failed disk
2 parity drives → recovers from 2 failed disks
3 parity drives → recovers from 3 failed disks

To add more parity drives, update /etc/snapraid.conf:

parity /mnt/disk4/snapraid.parity
parity /mnt/disk5/snapraid.parity2

Parity is the difference between losing a movie collection and shrugging off a dead drive. Set up at least one parity disk before you trust the array with anything you care about.

What Is SnapRAID Content?

The SnapRAID content file (snapraid.content) stores metadata about your files: checksums, timestamps, and the layout information needed for recovery. The parity file rebuilds the actual data. The content file tells SnapRAID what your data looked like at the last sync.

Every snapraid sync updates the content file with new metadata. That’s how SnapRAID detects changes, catches corruption, and rebuilds lost files when you need it to.

Why Keep `snapraid.content` on Multiple Drives?

One copy is a single point of failure

If your only copy of snapraid.content lives on disk1 and disk1 dies, recovery fails. SnapRAID no longer has a record of your data layout, so it can’t rebuild anything. Put a copy on disk2 and disk3 and SnapRAID still has what it needs.

The whole point of SnapRAID is resilience. Keeping one copy of the content file undercuts that. Multiple copies are cheap insurance.

How to Store `snapraid.content` on Multiple Drives

In /etc/snapraid.conf, define multiple content locations:

content /mnt/disk1/snapraid.content
content /mnt/disk2/snapraid.content
content /mnt/disk3/snapraid.content

Each entry creates a duplicate of the content file on a different disk. SnapRAID updates all of them on every sync, so they stay identical.

Spread the content file across two or more drives and you’ve removed a real failure mode. If disaster hits, you still have a path back.

NOTE: You can use the same drives for both content and data.

What Is SnapRAID Data?

In SnapRAID, “data” means the actual files on your media server: movies, TV shows, music, backups. Those files live on data drives, which are the physical disks SnapRAID protects with parity.

Unlike traditional RAID, SnapRAID does not mirror or stripe data across disks. Each file exists in one location, and SnapRAID tracks which files live on which drive.

Why Data Drives Have to Be Defined in `snapraid.conf`

SnapRAID Needs to Know Where Your Files Live

SnapRAID uses parity calculations to recover lost files. If you don’t tell it which drives hold data, it can’t protect them and can’t restore anything.

In /etc/snapraid.conf, you define each data drive explicitly:

data d1 /mnt/disk1
data d2 /mnt/disk2
data d3 /mnt/disk3

Each data entry tells SnapRAID:

Which disks hold your files
Which disks need to be included in parity calculations
Where to look when checking for data integrity

It Lets SnapRAID Detect Changes and Fight Corruption

SnapRAID doesn’t track file changes on its own. You run snapraid sync to update parity.

With your data drives listed in snapraid.conf, SnapRAID knows:

Which files were added, modified, or deleted
When to update parity data
How to detect bit rot (silent file corruption)

Skip these entries and SnapRAID has no idea what files exist. It can’t protect what it doesn’t know about.

It Makes Recovery Actually Work

If a drive dies, SnapRAID uses parity to reconstruct the lost files. That only works when:

The missing drive was listed in snapraid.conf
A valid parity file exists
The remaining data disks are intact

Forget to list a drive in snapraid.conf and SnapRAID won’t protect it. If the drive fails, those files are gone for good because they were never included in parity calculations.

It Keeps Storage Expansion Painless

One of SnapRAID’s strengths is drive flexibility. Add a new data disk of any size at any time. Mount the new drive and add it to snapraid.conf:

data d4 /mnt/disk4

Run snapraid sync and the new disk is now under parity protection. No rebuild. No reformat. Just add the drive.

Defining data drives in snapraid.conf is non-negotiable. Without these entries, SnapRAID doesn’t know what to protect, can’t detect changes, and can’t restore lost files.

If you care about keeping your media safe, list every data drive in snapraid.conf and run snapraid sync on a schedule.

Installing SnapRAID

On Debian or Ubuntu, installation is one command. SnapRAID lives in the official package repository:

sudo apt update && sudo apt install snapraid -y

To verify SnapRAID is installed, run:

snapraid status

You’ll see:

Self test...
No configuration file found at '/etc/snapraid.conf'

That’s expected. You haven’t written the config yet.

Configuring SnapRAID

Planning Your SnapRAID Setup

Before you touch the config, plan it out:

How many data disks? SnapRAID stores parity on a separate drive, so you need at least one data disk and one parity disk.
How much parity? One parity disk protects against one drive failure. Two parity disks protect against two. Pick based on how much pain a multi-drive failure would cause you.
Which drives hold parity and content? The parity disk needs to be at least as big as your largest data drive. Spread content files across several data drives so you don’t lose the recovery layout if one disk dies.

Creating the SnapRAID Configuration File

The main configuration file for SnapRAID is /etc/snapraid.conf. Open it in a text editor:

sudo nano /etc/snapraid.conf

A basic configuration for three data disks and one parity disk looks like this:

# Parity file - stored on the largest disk or a dedicated parity drive
parity /mnt/disk3/snapraid.parity  

# Content files - store metadata; should be on multiple drives for redundancy
content /mnt/disk1/snapraid.content  
content /mnt/disk2/snapraid.content  

# Data drives - these contain actual files
data d1 /mnt/disk1  
data d2 /mnt/disk2  
data d3 /mnt/disk3

NOTE: Disk 1 and disk 2 are used for both content and data. That’s fine.

Key Points to Consider

Parity drive: Has to be as large as your biggest data drive, or larger.
Content files: Belong on multiple drives for redundancy.
Data drives: List every drive that holds files you want protected.

Additional SnapRAID Options

For better protection and logging, add:

# Define the block size used for parity calculations (default is 256K)
block_size 256  

# Auto-save changes to the content file before syncing
autosave 300  

# Enable scrub (data integrity check) with a limit on recovered errors
scrub_percent 10  
scrub_recover 5

Save and exit the file (CTRL + X, then Y, then Enter).

Running SnapRAID for the First Time

Step 1: Perform an Initial Sync

The first time you run SnapRAID, it has to build the initial parity. Run:

sudo snapraid sync

This takes a long time. Hours on a small array, days on a big one. When it finishes, SnapRAID has recorded parity and you can actually recover from a failure.

Step 2: Verify Data Integrity

SnapRAID doesn’t detect changes on its own, so check it periodically:

sudo snapraid check

This compares stored parity against the actual files to catch corruption.

Step 3: Scrubbing for Bit Rot

Files can rot quietly over time. SnapRAID can scrub a slice of your data to catch and fix errors before they spread:

sudo snapraid scrub -p 10

-p 10 limits scrubbing to 10% of files, which keeps disk wear reasonable.
Run scrubs on a schedule so issues get caught early.

Step 4: Recovering a Lost Drive

If a drive fails, don’t panic. SnapRAID can rebuild it. Replace the dead drive with a new one and mount it in the same location. Then run:

sudo snapraid fix

SnapRAID reconstructs the missing data using the parity drive.

Automating SnapRAID Maintenance

Schedule syncs and scrubs so you don’t have to remember. Open the crontab:

crontab -e

Add:

0 3 * * * /usr/bin/snapraid sync
0 4 * * * /usr/bin/snapraid scrub -p 10

Sync runs daily at 3 AM to update parity.
Scrub runs at 4 AM to look for silent corruption.

Save and exit (CTRL + X, then Y, then Enter).

Why MergerFS and SnapRAID Make the Perfect Combo

Run MergerFS and SnapRAID together and you get:

Simple storage management. All your drives show up as one mount point.
Flexible disk usage. Mix and match drives of different sizes without rebuilding anything.
Data redundancy. SnapRAID protects against disk failures.
Low resource usage. No constant mirroring like traditional RAID.

This setup is built for media servers, where most data is read-heavy and rarely changes. When a drive fails, you replace it and run snapraid fix instead of restoring from a full backup.

Final Thoughts

Set up SnapRAID with MergerFS once and the next dead drive becomes a chore instead of a crisis. Your files stay organized, accessible, and protected, and you don’t have to buy matching drives to keep the array honest.

Now build the config, run that first sync, and stop relying on luck.