Flexible HomeLab Storage: Deploying SnapRAID and MergerFS on Ubuntu Server

HomeLab tutorial - IT technology blog
HomeLab tutorial - IT technology blog

The Frustration of Mixed-Size Hard Drives

Most HomeLab enthusiasts start the same way: a drawer full of old hard drives. You might have a 2TB drive from an old desktop, a 4TB drive you bought on sale, and maybe a 10TB drive you recently splurged on.

When you decide to build a central storage server, you hit a massive wall. Traditional RAID levels like RAID 5 or RAID 6 require all drives to be the same size. If you put a 2TB, 4TB, and 10TB drive into a standard RAID 5 array, every drive is treated as a 2TB drive, wasting a staggering amount of space.

I faced this exact scenario when building my first media server. I had a collection of drives with varying ages and capacities. I wanted data redundancy, but I didn’t want to buy five identical 10TB drives just to get started. I needed a system that could grow as I found deals on hardware, without forcing me to wipe my data every time I added a new disk.

Root Cause: Why Traditional RAID Fails the HomeLabber

The core issue lies in block-level striping. Systems like ZFS or hardware RAID controllers split data into chunks and spread them across all disks. This is excellent for high-performance enterprise environments where speed is king. However, it creates three major problems for a home environment:

  • Rigidity: You cannot easily add a single drive to an existing ZFS vdev or a RAID 5 array without significant complexity or risk.
  • Disk Spin-up: In a RAID array, every single disk must spin up to read even a tiny text file. This increases power consumption, heat, and wear on the drives.
  • All-or-Nothing Failure: If you lose more drives than your parity allows (e.g., two drives in a RAID 5), the entire array is lost. The data on the remaining healthy drives becomes unrecoverable garbage because it only contains fragments of files.

Comparing the Solutions

Before settling on my current setup, I looked at several alternatives. UnRAID is a popular choice because it handles mixed drives beautifully, but it is proprietary and requires a paid license. TrueNAS (ZFS) is incredibly stable and feature-rich, but its hardware requirements and rigid expansion rules make it a poor fit for a budget-conscious hobbyist with mismatched disks.

This led me to the combination of MergerFS and SnapRAID. MergerFS handles the “pooling” (making multiple drives look like one big drive), while SnapRAID handles the “parity” (protecting your data against drive failure). I have applied this approach in production and the results have been consistently stable, providing the perfect balance between flexibility and safety.

The Best Approach: A Two-Layered Storage Stack

We are going to build a system where your data lives on standard Linux filesystems (like Ext4 or XFS). This means even if the OS fails, you can plug any drive into another computer and read the data directly. We will use MergerFS to create a unified mount point and SnapRAID to calculate parity on a schedule.

Step 1: Preparing the Drives

For this tutorial, assume you have three data drives and one parity drive. Important: Your parity drive must be equal to or larger than your largest data drive.

Identify your drives using lsblk. Let’s assume they are formatted and mounted at:

  • /mnt/disk1 (4TB Data)
  • /mnt/disk2 (4TB Data)
  • /mnt/disk3 (8TB Data)
  • /mnt/parity1 (8TB Parity)

Step 2: Installing and Configuring MergerFS

MergerFS is a FUSE-based union filesystem. It doesn’t change your data; it just creates a virtual view of it. Install it on Ubuntu:

sudo apt update
sudo apt install mergerfs

Now, we edit /etc/fstab to create the pool. We want to combine all disks starting with “disk” into a single folder called /mnt/storage.

# /etc/fstab entry for MergerFS
/mnt/disk* /mnt/storage fuse.mergerfs defaults,nonempty,allow_other,use_ino,cache.files=off,moveonenospc=true,dropcacheonclose=true,category.create=mfs 0 0

The category.create=mfs option (Most Free Space) tells MergerFS to write new files to the disk with the most available space. This keeps your drive usage balanced automatically.

Mount the pool:

sudo mkdir /mnt/storage
sudo mount -a

Step 3: Installing and Configuring SnapRAID

SnapRAID is not a real-time RAID. It calculates parity information based on your files and stores it on the parity drive. This is perfect for media libraries where files don’t change every second.

Install SnapRAID:

sudo apt install snapraid

Now, configure SnapRAID by editing /etc/snapraid.conf. You need to define where the parity file goes, where the content files (database) go, and where your data disks are.

# Parity location
parity /mnt/parity1/snapraid.parity

# Content file locations (Keep multiple copies on different drives!)
content /var/snapraid/snapraid.content
content /mnt/disk1/.snapraid.content
content /mnt/disk2/.snapraid.content

# Data drives
data d1 /mnt/disk1/
data d2 /mnt/disk2/
data d3 /mnt/disk3/

# Exclude temporary files and trash
exclude /lost+found/
exclude /tmp/
exclude .AppleDB
exclude .Thumbs.db

Step 4: Running the Initial Sync

Once configured, you need to generate the parity. This will take time depending on how much data you already have on the disks.

snapraid sync

If a drive fails in the future, you simply replace it and run snapraid fix. Because SnapRAID works at the file level, if you lose more drives than you have parity for, you only lose the files on the failed drives. Everything else remains perfectly intact.

Automating the Maintenance

The only downside to SnapRAID is that it isn’t automatic. If you add files to /mnt/storage, they aren’t protected until you run snapraid sync again. I recommend setting up a cron job or a systemd timer to run the sync daily.

Create a simple script at /usr/local/bin/snapraid-maintenance.sh:

#!/bin/bash
# Sync the array
snapraid sync
# Scrub the data to check for silent bit rot (checks 8% of the array)
snapraid scrub -p 8 -o 10

Make it executable and add it to your crontab:

sudo chmod +x /usr/local/bin/snapraid-maintenance.sh
(crontab -l ; echo "0 3 * * * /usr/local/bin/snapraid-maintenance.sh") | crontab -

This setup will run every night at 3:00 AM, ensuring your data is protected and checking for “bit rot”—a phenomenon where data degrades over time on the physical platter.

Summary of the Workflow

My experience with this setup has been incredibly smooth. When I ran out of space last year, I simply bought a new 12TB drive, formatted it, mounted it as /mnt/disk4, and updated my snapraid.conf. MergerFS automatically picked it up because of the wildcard (/mnt/disk*) in fstab. No rebuilding arrays, no stress, and no downtime. This is, in my opinion, the ultimate storage solution for any HomeLab that values flexibility over raw enterprise performance.

Share: