RAID Levels for Dedicated Servers: 0, 1, 5, 10 and ZFS Explained

Answer first

For the impatient, the defaults that serve most workloads well:

• Two drives? RAID 1 (mirror). Half the raw capacity, survives a drive failure, simple to reason about. The right answer for almost every two-drive server.
• Four or more drives, running databases or VMs? RAID 10. Half the capacity, excellent random-write performance, fast low-drama rebuilds.
• Four or more drives, capacity-hungry and read-mostly (media, backups-of-backups, archives)? RAID 5 buys you the most usable space with one-drive protection — with caveats about rebuilds on large drives, covered honestly below.
• RAID 0 only for data you can afford to lose instantly: scratch space, caches, reproducible build artefacts.
• ZFS is less a fifth level than a different philosophy — checksums, self-healing, snapshots — worth choosing when you'll use those features and can feed its appetite for RAM.

And the sentence that should be tattooed on every storage decision: RAID is availability, not backup. It keeps the server running through a drive failure; it replicates deletions, ransomware, and corruption just as faithfully as your data.

What RAID actually does

RAID (Redundant Array of Independent Disks) combines physical drives into one logical volume, trading capacity, performance, and redundancy against each other. Three mechanisms underlie every level:

• Striping — data is split across drives so reads and writes engage several drives at once (more speed, no protection).
• Mirroring — every block is written to two drives (full protection, half capacity).
• Parity — one drive's worth of redundancy is computed across the stripe, so any single missing drive can be reconstructed (most capacity, cleverest failure mode — and the most fine print).

Every practical level is one of these or a combination:

(The usable-capacity column is exactly the arithmetic our configurator shows when you pick a RAID variant at order time: RAID 1 gives one drive's capacity, RAID 5 gives all-but-one, RAID 10 gives half.)

The levels, honestly

RAID 0: speed with no seatbelt

All striping, no redundancy: capacity and throughput of every drive combined, and the combined failure probability too — any single drive dying takes the entire volume with it. That's not a rare edge case; over a multi-year rental it's the expected event. Legitimate uses are exactly the ones where loss costs you a re-run rather than data: CI scratch, render intermediates, ephemeral caches. If the phrase "we'd restore from backup" makes anyone at your company wince, RAID 0 is not for that dataset.

RAID 1: the boring hero

Two drives, identical contents. You lose half your capacity and gain the simplest possible failure story: one drive dies, the server doesn't blink, you swap the drive, the mirror re-copies. Rebuilds are gentle (a linear copy from the healthy drive) and — an underrated virtue — a single surviving drive is a complete, readable copy of your data, not a puzzle piece. For OS drives and any two-drive server, this is the default for good reason.

RAID 5: maximum capacity, sharpest fine print

With N drives you keep (N−1)/N of the space and survive any single failure — on paper the best deal in the table. The fine print is what happens after a failure:

• Rebuilds read every byte of every surviving drive. On today's large drives that's a long window — many hours to days on big HDDs (much shorter on NVMe) — during which the array has zero redundancy and every remaining drive is under maximum sustained load. A second failure, or an unreadable sector discovered mid-rebuild on an aging drive, ends the story. This risk grows with drive size, which is why RAID 5's reputation has aged with the terabytes.
• Every small write pays a parity tax — read old data, read old parity, compute, write both — which is why random-write-heavy workloads (databases, busy VM stores) feel RAID 5 more than benchmarks of sequential throughput suggest.

Where it still earns its place: read-mostly, capacity-driven workloads on modest-size drives (or fast-rebuilding NVMe), with monitoring that actually alerts on the first failure and — as always — real backups. If you're tempted toward RAID 5 on very large drives, that's the moment to consider dual-parity (RAID 6 / ZFS raidz2, where available) or to reconsider RAID 10.

RAID 10: what the databases want

Mirrored pairs, striped together. You pay the mirror's 50% capacity tax and get the best operational profile of the group: strong random I/O (no parity math), failures degrade only one pair, and rebuilds copy a single mirror rather than thrashing the whole array. For databases, virtualisation hosts, and anything write-heavy where predictable performance during failures matters, RAID 10 is the professional default — four drives at half capacity is the price of never having an interesting rebuild.

ZFS: the same questions, different philosophy

ZFS bundles volume management and filesystem, and its analogues — mirrors (≈RAID 1/10) and raidz1/raidz2 (≈RAID 5/6) — add what conventional RAID fundamentally lacks: end-to-end checksums. Classic RAID trusts drives to report their own failures; ZFS verifies every block on read and, in a redundant layout, silently repairs corruption from the good copy ("self-healing"). On top: snapshots that make point-in-time rollback effectively free, zfs send/receive for efficient replication, and transparent compression that often pays for itself.

The costs, equally honestly: ZFS wants RAM (a few GB baseline plus more for caching; its ARC will happily use what you give it), adds conceptual load (pools, vdevs, datasets), and its parity variants share RAID 5/6's write characteristics. Rules of thumb: mirrors for VMs and databases, raidz2 for bulk capacity — and note this is exactly the storage layer Proxmox VE offers natively, which is why the choice comes up at hypervisor install time (see our Proxmox setup guide).

Hardware RAID, mdadm, or ZFS?

The level is one decision; what implements it is another, with real consequences at 3 a.m.:

• Hardware RAID controllers present the array to the OS as one opaque disk. Upside: OS-independent, boot-simple, write-back cache with battery/flash backup. Downside: the array's format is the controller's secret — recovery or migration typically wants compatible hardware — and monitoring depends on vendor tooling you must actually wire up.
• Linux mdadm (software RAID) is transparent and portable: any Linux box can assemble the array, cat /proc/mdstat tells the truth, and there's no proprietary layer between you and your data. Modern CPUs make the performance argument for hardware RAID mostly historical (parity math is a rounding error next to NVMe throughput).
• ZFS — as above, when its features earn their overhead.

The honest summary: on modern NVMe servers, software RAID (mdadm or ZFS) is the default recommendation for transparency and portability; hardware RAID remains sensible where OS support, boot constraints, or an existing operational practice favour it.

Choosing by workload

Two closing disciplines, whatever you pick. Monitor the array — RAID's failure mode is silent degradation: the first drive dies, nothing user-visible happens, and the array runs unprotected until someone notices (wire mdadm/SMART/controller alerts to a human). And back up — RAID answers "a drive died"; backups answer everything else, from rm -rf to ransomware to the array itself failing. Size the backup plan with the same seriousness as the array (our Proxmox backup strategies guide covers the virtualisation case).

Frequently asked questions

Is RAID a substitute for backups?

No, and it's worth being precise about why: RAID's job is availability — the server keeps running when a drive fails. Every other data-loss mode passes straight through it: deletions, application bugs, ransomware, and filesystem corruption are replicated to all drives within milliseconds, and controller failure or a second drive death can take the whole array. Backups are a copy elsewhere with history; RAID is redundancy in place. Production data wants both.

RAID 5 or RAID 10?

Decide on two axes: write pattern and rebuild tolerance. Random-write-heavy (databases, VM stores) or low appetite for long degraded windows → RAID 10. Read-mostly bulk capacity where the extra usable space matters and drives are modest-sized or fast-rebuilding NVMe → RAID 5 is defensible. If it's RAID 5 on very large drives, treat dual parity (RAID 6/raidz2) as the serious alternative — the single-parity rebuild window on big disks is the sharpest risk in this article.

Do fast NVMe drives still need RAID?

For redundancy, yes — NVMe changes performance, not mortality. Flash fails differently from spinning disks (firmware bugs, controller death, wear-out) but it does fail, and without redundancy a failure means restoring from backup with downtime to match. What NVMe does change is the trade-offs: rebuilds complete in hours rather than days (softening RAID 5's biggest caveat) and parity CPU cost is negligible, though mirrors remain the latency-predictable choice.

Can I change RAID level later?

Treat the answer as "no" for planning purposes. Some migrations are technically possible (mdadm can reshape between certain levels; ZFS added raidz expansion recently), but they're slow, riskful operations performed on live data — precisely what you don't want. The realistic path is the one that works everywhere: provision the new layout, restore from backup, cut over. Which is an argument for spending five minutes with the capacity math before ordering.

Deploying on Serverside

Our dedicated server configurator makes this decision concrete: pick a RAID variant at order time and it shows the usable capacity for your exact drive count — the same arithmetic as the table above — with the array delivered ready-built, so there's nothing to assemble on day one. NVMe options keep rebuild windows short, and if you're sizing drives and everything else around them, our server sizing guide pairs naturally with this one.

Related reading: Proxmox backup strategies for the "RAID is not a backup" half of the story, and the first-hour hardening checklist for everything after the storage decision.