Your Data Is Fine. Until It Isn’t.
You’ve got three drives sitting in a server. You need to decide what to do with them. Someone on Reddit told you to use RAID. Someone else told you RAID is useless. Both of them are half right.
RAID — Redundant Array of Independent Disks — is one of those acronyms that aged poorly. “Redundant” is doing a lot of heavy lifting in that name, because one of the most popular RAID levels has zero redundancy. Zero. We’ll get to that.
The good news: there are really only three levels you need to understand for a home lab. RAID 0, RAID 1, and RAID 5. Each one makes a specific trade-off between speed, storage capacity, and fault tolerance. Get the trade-off right, and your data lives. Get it wrong, and you’ll be staring at a degraded array at 2 AM wondering what you did to deserve this.
Let’s do it right.
RAID 0: Speed at Any Cost
RAID 0 stripes data across multiple drives. When you write a file, half goes to disk A and half goes to disk B — simultaneously. Reads work the same way. The result is roughly double the sequential throughput of a single drive. It’s genuinely fast, and the storage efficiency is perfect: two 4TB drives give you 8TB of usable space.
Here’s the catch. There’s no redundancy. None. If either drive dies, you lose everything on the array. Not “you might lose some things.” Everything. Gone. RAID 0 with two drives doubles your failure surface — you now have two drives that can kill your data instead of one.
The name still says “Redundant.” Marketing was involved.
When RAID 0 Actually Makes Sense
This isn’t a “never use RAID 0” article. RAID 0 has legitimate use cases — they just have to fit this rule: if this data disappeared right now, would you care?
- Scratch space for video rendering or build artifacts
- A cache drive for Plex transcoding
- Temp storage for a CI pipeline
- Anything you can regenerate from source
If you’re considering RAID 0 for your photo library, your VMs, or anything you’d be upset to lose — don’t. Just don’t.
# Create RAID 0 across /dev/sdb and /dev/sdcmdadm --create /dev/md0 --level=0 --raid-devices=2 /dev/sdb /dev/sdc
# Check itcat /proc/mdstatPersonalities : [raid0]md0 : active raid0 sdb[0] sdc[1] 8388608 blocks super 1.2 512k chunksTwo drives, one logical volume, all the speed, none of the safety net.
RAID 1: Boring Is Beautiful
RAID 1 mirrors your data. Every write goes to both drives simultaneously. Both drives contain identical copies of everything. If one dies, the other keeps running like nothing happened. You swap the dead drive, the array rebuilds, and your 2 AM just got a lot more manageable.
The trade-off: storage efficiency is 50%. Two 4TB drives give you 4TB usable. You’re paying double for your storage capacity. Reads can be faster (the controller can read from either drive), but writes are limited by the slowest drive in the pair since both writes must complete.
This is the right level for: OS/boot drives, small databases, anything where you’d rather be safe than sorry and don’t need massive capacity.
The Write Penalty Is Real but Manageable
Some people get worked up about RAID 1 write performance. Honestly, for a home lab on spinning drives, the bottleneck is almost never the RAID overhead — it’s the drives themselves. On SSDs, you’ll notice even less. Don’t let write penalty concerns talk you out of RAID 1 where it belongs.
# Mirror /dev/sdb and /dev/sdcmdadm --create /dev/md1 --level=1 --raid-devices=2 /dev/sdb /dev/sdc
# Check detail (includes rebuild status if one drive was added later)mdadm --detail /dev/md1/dev/md1: Version : 1.2 Creation Time : Tue Apr 29 12:00:00 2026 Raid Level : raid1 Array Size : 4194304 (4.00 GiB 4.29 GB) Used Dev Size : 4194304 (4.00 GiB 4.29 GB) Raid Devices : 2 Total Devices : 2 Active Devices : 2 State : cleanIf a drive fails, State becomes degraded. You add a new drive, the array rebuilds, you get a clean state back. No data loss. That’s the whole deal, and it’s worth the 50% storage hit for anything important.
RAID 5: The Sweet Spot
RAID 5 stripes data across three or more drives and adds a parity block to the rotation. If any single drive fails, the parity data on the remaining drives can reconstruct what was lost. Storage efficiency is (N-1)/N — three 4TB drives give you 8TB usable (2/3 efficiency), four give you 12TB (3/4 efficiency), and so on.
This is why RAID 5 is the default choice for NAS builds and bulk storage. You get redundancy against a single drive failure, and you’re not throwing away half your capacity like RAID 1 does.
The Write Hole Problem (And Why You Probably Don’t Care)
RAID 5 has a known issue called the write hole: during a power failure mid-write, parity data can become inconsistent with the actual data, leaving the array in a state where a subsequent drive failure could cause data corruption even before the dead drive is replaced.
In practice: if you have a UPS (and your home server probably should have one), this risk is minimal. If you’re running RAID 5 on spinning drives with a battery-backed controller, it’s not a concern at all. And if you’re running RAID 5 as cold storage for your Blu-ray rips, you’re fine. This matters a lot more in write-heavy enterprise workloads than in a home lab.
RAID 5 Is Not Great for Large Drives + Write-Heavy Workloads
There’s a rebuild risk problem with RAID 5 on large drives — when a drive fails and you’re rebuilding across 8TB or 12TB drives, that rebuild takes hours, sometimes a full day. During that window, the array is running degraded. If another drive fails mid-rebuild, you’ve lost everything.
Modern drives are large. The odds of a second failure during a long rebuild aren’t zero. This is why RAID 6 exists (and why we cover it in the next article). For home lab use with 4-bay NAS boxes, 4TB drives, and cold/warm data: RAID 5 is still a reasonable choice. For a 12-drive array of 16TB drives with constant writes: you want RAID 6.
# Create RAID 5 across 3 drives (minimum)mdadm --create /dev/md5 --level=5 --raid-devices=3 /dev/sdb /dev/sdc /dev/sdd
# Check rebuild progress after adding/replacing a drivewatch cat /proc/mdstatmd5 : active raid5 sdd[2] sdc[1] sdb[0] 8388608 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU][UUU] = all devices up and healthy. If you see [UU_], you’re degraded and it’s time to act.
Making the Array Permanent
Once you’ve created any RAID array, save the config and make sure it auto-assembles on boot:
# Save mdadm configmdadm --detail --scan >> /etc/mdadm/mdadm.conf
# Create filesystem on the arraymkfs.ext4 /dev/md5
# Mount itmkdir -p /mnt/raid5mount /dev/md5 /mnt/raid5
# Add to /etc/fstab for persistent mountingecho '/dev/md5 /mnt/raid5 ext4 defaults,nofail 0 2' >> /etc/fstabThe nofail mount option is important — without it, a degraded array can prevent your system from booting.
The Decision Guide
| RAID 0 | RAID 1 | RAID 5 | |
|---|---|---|---|
| Min drives | 2 | 2 | 3 |
| Fault tolerance | None | 1 drive | 1 drive |
| Storage efficiency | 100% | 50% | (N-1)/N |
| Read speed | Fast | Normal/fast | Fast |
| Write speed | Fast | Slight penalty | Noticeable penalty |
| Best for | Scratch/temp | OS, boot, critical data | NAS, bulk cold storage |
| Worst for | Anything you care about | Big capacity needs | High-write workloads + large drives |
A few concrete picks for common home lab scenarios:
Proxmox boot drive on two SSDs → RAID 1. You want that hypervisor to survive a drive death without drama.
Plex transcoding cache → RAID 0. Speed matters, the data is regeneratable, use the capacity.
4-bay NAS for photos, backups, media → RAID 5. Reasonable efficiency, single-drive protection, manageable rebuild times on 4TB drives.
VM datastore on SSDs → RAID 1 or RAID 10 (if you have four drives — covered in the RAID 6 vs RAID 10 article).
Real Talk
If you want RAID baked directly into your filesystem — checksums, scrubbing, snapshots, and RAID all in one place — that’s a different rabbit hole. Check out the ZFS vs Btrfs article for that approach. mdadm RAID is the classic Linux way: raw, reliable, and not particularly opinionated about your filesystem choices.
One more thing before you commit: RAID is not a backup. It protects against drive failure. It does nothing for accidental deletion, ransomware, or the smoke detector going off in your server room. Run RAID for uptime. Run backups for peace of mind. Your 2 AM self will appreciate the distinction.
The follow-up articles in this series cover RAID 6 vs RAID 10 for when you’ve got four drives and can’t decide, and RAID reliability and recovery for the rebuild math and monitoring setup that makes this all survivable long-term.