RAID 50/60: Nested Parity Done Right

You’ve Got 12 Drives. Now What?

The RAID 0, 1, and 5 article assumed you had three or four drives and needed to pick a lane. The RAID 6 vs RAID 10 article bumped that to four or six and added double-parity into the mix. But what happens when you’re staring at a chassis with 12, 16, or 24 drive bays and the standard RAID levels start looking a little shaky?

Here’s the thing: RAID 5 across 12 drives isn’t just a big RAID 5. It’s a liability. When a drive fails, the array has to rebuild across all 11 remaining drives — reading every sector on all of them. That’s a lot of read stress, a lot of time, and a lot of exposure to the URE math we covered in the rebuild article. At 12TB per drive, you’re looking at a rebuild window measured in days, not hours. Another drive coughs during that window and it’s game over.

RAID 50 and RAID 60 exist specifically to solve this. They don’t eliminate rebuild risk — nothing does — but they contain it to a fraction of your total drive population. That’s the whole idea.

Full example: Clone the working files at github.com/KingPin/sumguy-examples/linux/raid-50-vs-60-nested

What RAID 50 and RAID 60 Actually Are

These are nested RAID levels — RAID within RAID, like a matryoshka doll of redundancy and performance anxiety.

RAID 50 is a RAID 0 stripe laid on top of multiple RAID 5 sub-arrays. You split your drives into groups, build a RAID 5 in each group, then stripe those sub-arrays together with RAID 0. Minimum drive count: 6 (two 3-drive RAID 5s). You won’t see much practical benefit until you hit 9 or 12 drives — that’s where the rebuild domain math starts to matter.

RAID 60 is the same idea but uses RAID 6 sub-arrays instead. Each sub-array can survive two simultaneous drive failures. Minimum drive count: 8 (two 4-drive RAID 6s). Real-world sweet spots are 12, 16, or 24 drives.

A 12-drive RAID 50 might look like this: three groups of four drives, each running RAID 5, striped together. Or two groups of six drives each. How you split the groups affects rebuild speed vs. capacity — more on that shortly.

Neither of these is exotic enterprise-only technology. You can build both with mdadm on any Linux box. They’re just not commonly discussed because most home lab builders aren’t rocking 12-drive configurations. If you are, read on.

The Killer Feature: Rebuild Domains

This is the whole argument for nested RAID, so let’s make it concrete.

If you’ve read the rebuild math article, you know that the risk during a rebuild isn’t just “will another drive fail” — it’s a function of how much data has to be read during the rebuild. More drives in the array, more read pressure on each one, higher probability of hitting an Unrecoverable Read Error (URE) on a sector you need for reconstruction.

The rule of thumb: URE probability compounds with array size. A 12-drive RAID 5 rebuild reads roughly 11 drives worth of data. That’s a lot of sectors.

Now compare that to 12-drive RAID 50 configured as two 6-drive RAID 5 sub-arrays striped together. When a drive in sub-array A fails, only the other 5 drives in sub-array A participate in the rebuild. Sub-array B just keeps serving data like nothing happened.

You’ve cut your rebuild read load in half. Roughly. The URE math follows:

A standard 12-drive RAID 5 rebuild reads ~132TB (11 drives × 12TB each). A 6-drive RAID 5 sub-array rebuilding one drive reads ~60TB. Same drives, dramatically smaller blast radius. Split into four 3-drive sub-arrays and you’re down to ~24TB per rebuild. You’re trading capacity for resilience — nested RAID is a rebuild domain story, not a capacity story.

• 12-drive RAID 5 → drive fails → 11 drives under stress for 18–36 hours → high URE exposure
• 12-drive RAID 50 (2× 6-drive RAID 5) → drive fails → 5 drives under stress for 8–12 hours → sub-array B untouched

Your 2 AM phone isn’t silent either way — but one of those scenarios has a much narrower window where a second failure is catastrophic.

Capacity and Performance Math

Let’s get to numbers. Because “usable space” on nested RAID isn’t as obvious as RAID 5.

RAID 50 formula:

usable = (drives_per_group - 1) × num_groups × drive_size

RAID 60 formula:

usable = (drives_per_group - 2) × num_groups × drive_size

12 drives × 4TB each

At 24 drives × 8TB: RAID 50 (4×6) gives 160TB usable with 5-drive rebuild domains. RAID 60 (4×6) drops to 128TB but every sub-array survives two concurrent failures. The pattern holds — more groups means smaller rebuild domains and faster recoveries, at a cost in raw terabytes.

Capacity efficiency drops as you add more groups. More groups = smaller rebuild domains = faster rebuilds = lower URE exposure. You pay in raw terabytes.

On sequential read performance: RAID 50 stripes across all groups simultaneously — a 12-drive RAID 50 reads from all 12 drives at once. Sequential writes see a similar boost over flat RAID 5. Random I/O is workload-dependent; run fio benchmarks against your actual patterns before committing to a layout.

Building It with mdadm

Here’s where it gets fun. mdadm has no --level=50 or --level=60. There’s no magic flag. You build nested RAID by hand, step by step: create the sub-arrays first, then create a RAID 0 across them. This is actually fine — mdadm’s layering model handles it cleanly.

12-drive RAID 50: two 6-drive RAID 5 sub-arrays, striped

# Step 1: Create sub-array A (drives 1-6)
mdadm --create /dev/md0 \
  --level=5 \
  --raid-devices=6 \
  /dev/sdb /dev/sdc /dev/sdd \
  /dev/sde /dev/sdf /dev/sdg

# Step 2: Create sub-array B (drives 7-12)
mdadm --create /dev/md1 \
  --level=5 \
  --raid-devices=6 \
  /dev/sdh /dev/sdi /dev/sdj \
  /dev/sdk /dev/sdl /dev/sdm

# Step 3: Wait for both sub-arrays to finish initial sync
watch cat /proc/mdstat

# Step 4: Create the top-level RAID 0 stripe across both sub-arrays
mdadm --create /dev/md10 \
  --level=0 \
  --raid-devices=2 \
  /dev/md0 /dev/md1

The top-level device is /dev/md10 — format and mount that. The sub-array devices exist purely to serve the stripe.

What /proc/mdstat looks like for a nested setup

Personalities : [raid5] [raid0]
md10 : active raid0 md1[1] md0[0]
      40960000 blocks super 1.2 512k chunks

md1 : active raid5 sdm[5] sdl[4] sdk[3] sdj[2] sdi[1] sdh[0]
      20480000 blocks super 1.2 level 5, 512k chunk, algorithm 2 [6/6] [UUUUUU]

md0 : active raid5 sdg[5] sdf[4] sde[3] sdd[2] sdc[1] sdb[0]
      20480000 blocks super 1.2 level 5, 512k chunk, algorithm 2 [6/6] [UUUUUU]

unused devices: <none>

[UUUUUU] on each sub-array means all drives are up. If you see [UUUUU_] on either sub-array, you’ve lost a drive and the rebuild is underway on that domain only.

12-drive RAID 60: two 6-drive RAID 6 sub-arrays, striped

Same pattern, just --level=6:

# Sub-array A: RAID 6 across 6 drives
mdadm --create /dev/md0 \
  --level=6 \
  --raid-devices=6 \
  /dev/sdb /dev/sdc /dev/sdd \
  /dev/sde /dev/sdf /dev/sdg

# Sub-array B: RAID 6 across 6 drives
mdadm --create /dev/md1 \
  --level=6 \
  --raid-devices=6 \
  /dev/sdh /dev/sdi /dev/sdj \
  /dev/sdk /dev/sdl /dev/sdm

# Top-level stripe
mdadm --create /dev/md10 \
  --level=0 \
  --raid-devices=2 \
  /dev/md0 /dev/md1

Each sub-array survives two simultaneous drive failures independently. The top-level RAID 0 has no redundancy — lose all drives in any single sub-array and you’re done. RAID 60 is resilient, not indestructible.

Persisting the array with mdadm.conf

The gotcha with nested RAID: sub-arrays must assemble before the top-level stripe. mdadm handles this automatically if your config is right.

# Save all array configs
mdadm --detail --scan >> /etc/mdadm/mdadm.conf

# Update initramfs so it assembles on boot
update-initramfs -u

# Create filesystem on the top-level device
mkfs.ext4 /dev/md10

# Mount
mkdir -p /mnt/raid50
mount /dev/md10 /mnt/raid50
echo '/dev/md10 /mnt/raid50 ext4 defaults,nofail 0 2' >> /etc/fstab

On boot: mdadm sees the sub-array configs, assembles /dev/md0 and /dev/md1, then assembles /dev/md10 over them. The nofail mount option is load-bearing here — a degraded sub-array shouldn’t prevent your system from booting.

To check full detail on any sub-array:

mdadm --detail /dev/md0
mdadm --detail /dev/md1
mdadm --detail /dev/md10

Set up SMART monitoring — mdadm tells you when a drive has failed, but SMART tells you when it’s about to fail. In a large array, that’s the difference between a planned swap and a rebuild-under-pressure situation.

The ZFS / dRAID Question

If you’re building at this scale — 12, 16, 24 drives — you’ve probably encountered ZFS in your research. It’s worth addressing directly.

ZFS achieves the same “rebuild domain” goal differently. Instead of mdadm nested RAID, you build a ZFS pool with multiple RAID-Z2 vdevs. Each vdev is its own redundancy domain — a drive failure in vdev A triggers a resilver only within vdev A, vdev B keeps going. Structurally identical to RAID 60, but with checksumming, scrubbing, snapshots, and compression baked in. The newer answer at 24+ drives is dRAID (OpenZFS 2.1+), which distributes spare capacity across the full pool width so rebuilds use all available bandwidth instead of being bottlenecked to one vdev.

For the full ZFS story — when to use it over mdadm, which storage OS handles it best — the ZFS vs Btrfs article and TrueNAS vs OpenMediaVault vs Unraid cover the landscape. The deep-dive on large-scale ZFS pool design is coming next in this series.

When NOT to Bother

Let’s save you some time. Nested RAID is overkill in a bunch of common scenarios.

4–6 drive home arrays: Go read the RAID 0, 1, 5 article and the RAID 6 vs RAID 10 article. RAID 5, 6, or 10 will serve you fine. RAID 50 with two 3-drive sub-arrays costs 4 drives to parity overhead and gives you less usable space than a flat RAID 5 at the same count. The math doesn’t work in your favor.

When your drives are under 6TB: Rebuild times on smaller drives are manageable with flat RAID 6. The URE math gets scary past 100+ TB of reads. At 4TB per drive in an 8-drive array, a flat RAID 6 rebuild is fine. Nested is optional, not mandatory.

Hardware controller limitations: Some HBAs and RAID cards don’t expose sub-array devices to the OS for layering. If you’re on a hardware RAID controller, check whether it supports RAID 50/60 natively as a combined level. If not, software RAID via mdadm is the answer.

When you’d rather have ZFS: If you’re on TrueNAS or a ZFS-capable platform, just build RAID-Z2 vdevs. Same result, full ZFS feature set for free. Using mdadm nested RAID alongside ZFS is an unusual choice — don’t reach for it without a specific reason.

Decision Cheatsheet

Three concrete scenarios:

12-drive home NAS (media, backups): RAID 50 with two 6-drive sub-arrays. Sequential reads are fast, a single drive failure only stresses half the array, and rebuild times are roughly half what flat RAID 5 would take across 12 drives.

12-drive small business file server with continuous writes: RAID 60 with two 6-drive sub-arrays. Write penalty is real — RAID 6 always is — but two-fault tolerance per group justifies it for anything running all day.

24-drive dedicated storage server: Evaluate ZFS seriously. TrueNAS Scale with four 6-drive RAID-Z2 vdevs is functionally equivalent to RAID 60 plus checksumming, scrubbing, and snapshots. mdadm nested RAID is valid, but ZFS earns its keep at this drive count.

Real Talk

You’ve now read four articles in this series and the answer is the same every time: RAID is not a backup.

RAID 50 gives you a narrower rebuild window. RAID 60 gives you double-parity containment. Both protect you against drive failure. Neither protects you against the intern who ran rm -rf on the mount point, the ransomware that encrypted everything in place, or the power strip that took out two sub-arrays at once. Backups do. The two are not the same thing.

Nested RAID is a precision tool for a specific problem: large drive counts where flat parity creates rebuild windows that are just too dangerous. If you’re at that scale, it’s the right call. If you’re at 6 drives because it sounds impressive, you’re hiring a forklift to move a couch. Your neighbors — and your rebuild times — will have questions.

The full series, if you’re reading these in order:

• RAID 0, 1, and 5: Pick One — where to start, the trade-offs, the basics
• RAID 6 vs RAID 10: Two Dead Disks — when you need more fault tolerance and how to choose
• RAID Is Not Backup: Rebuild Math — the URE math, monitoring, and why rebuild time is the real enemy

Build smart. Monitor constantly. Back up everything. Your 2 AM self will appreciate having all three in place before something actually goes wrong.

Related Reading

• RAID 0, 1, and 5: Pick One
• RAID 6 vs RAID 10: Two Dead Disks
• SnapRAID: Parity Without Real-Time RAID
• Borg vs Duplicacy: Dedup Backup Wars
• Btrfs RAID 5/6: Still Don’t