“RAID is not a backup” gets repeated so often it’s lost meaning. Here’s the version that actually helps you pick a redundancy level instead of just feeling vaguely guilty about your array.

What redundancy actually protects against

Redundancy (RAID-Z1, RAID-Z2, mirrors, whatever flavor) protects against drive failure, full stop. It does not protect against:

  • Accidental deletion (redundancy dutifully replicates your mistake)
  • Ransomware or file corruption that writes bad data (same problem)
  • Fire, theft, flooding, or anything that takes out the whole box at once
  • Controller or power supply failure that kills multiple drives simultaneously

That’s what backups are for, and it’s a separate problem from redundancy. This post is specifically about the “how many drives can I lose without losing data” question.

The real risk: rebuild time

The reason “just run RAID-Z1 with one parity drive” advice has gotten worse over time isn’t the math — it’s drive size. Rebuilding a failed 4TB drive from parity used to take hours. Rebuilding a failed 20TB drive can take a day or more, and during that entire window, your array has zero redundancy left. If a second drive fails — and rebuild stress is exactly when a second aging drive tends to fail — you lose the pool.

This is why RAID-Z1 (single parity) has fallen out of favor for anything beyond small arrays of smaller drives, and why RAID-Z2 (dual parity) has become the practical default for larger pools.

A sizing framework, not a rule of thumb

Instead of “always run Z2,” work through this:

  1. How many drives are in the vdev? More drives means more chances for a second failure during a rebuild. A 4-drive vdev is a different risk profile than a 12-drive vdev.
  2. How big are the drives? Bigger drives mean longer rebuilds mean longer exposure windows. Scale your parity up as your drive size goes up.
  3. How replaceable is this data? A media library you could re-rip is a different risk tolerance than family photos or financial records that exist in exactly one place.
  4. Do you actually have a backup for the important subset? If yes, you can run leaner redundancy on the pool since a rebuild failure isn’t catastrophic — it’s an inconvenience you recover from with the backup.

Practical starting points

  • Small pool (4-6 drives, ≤8TB each), backed-up critical data: RAID-Z1 is defensible. Watch your drive ages and replace proactively.
  • Larger pool (8+ drives) or drives above 12TB: RAID-Z2. The rebuild window is long enough that single parity is gambling.
  • Anything truly irreplaceable: mirrors (RAID-10 equivalent) or RAID-Z2 and an off-site backup. Redundancy buys you uptime during a drive failure; it does not buy you disaster recovery.
  • Very large pools (16+ drives): consider RAID-Z3 (triple parity) or splitting into multiple smaller vdevs rather than one giant one — a single huge vdev means a single huge rebuild.

The one habit that matters more than any RAID level

Monitor drive health (SMART data, zpool status, scrub schedules) and replace drives showing early warning signs before they fail outright, not after. A proactive swap on a healthy array is a non-event. A failure during a rebuild is how pools actually get lost. Redundancy buys you a safety margin — monitoring is what tells you when you’re about to need it.