blog posts

Every server build eventually reaches the same fork in the road. You have a handful of drives, a controller, and a decision to make about how those drives should work together. Get it right, and your server shrugs off a dead disk on a Sunday night without anyone noticing. Get it wrong, and you either throw away half your storage budget or spend a very bad week restoring from whatever backup you happen to have.

RAID (Redundant Array of Independent Disks) combines several physical drives into one logical volume. Depending on the level you pick, that array gives you more speed, more fault tolerance, more usable capacity, or some compromise between the three. What it never gives you is a backup, and that single misunderstanding costs companies real money every year.

Here is how to make the decision properly, without guessing.

First, understand what RAID is actually doing

Every RAID level is built from three simple mechanics, mixed in different proportions.

Striping splits data into chunks and spreads them across all drives in the array. Several drives read and write at once, so throughput goes up. Striping adds no protection at all on its own.

Mirroring writes the same data to two drives simultaneously. You lose half your raw capacity and gain a complete second copy that is ready the moment the first drive dies.

Parity stores mathematical information that lets the array rebuild missing data from what remains. It is far more space-efficient than mirroring, but calculating and updating parity slows writes down, and rebuilding from parity is a slow, stressful process for the surviving drives.

Once you see the levels as recipes made from these three ingredients, the differences stop feeling arbitrary.

The RAID levels worth your attention

RAID 0 — striping with no safety net

Two or more drives, 100% of the raw capacity, and the fastest reads and writes you will get from a given set of disks. The catch is severe: lose any single drive and the entire array is gone. Worse, risk climbs as you add drives, because you now have more components that can each take the whole array down. RAID 0 belongs in exactly one place, which is scratch space for data you can regenerate on demand, like video transcoding output, render caches, or temporary processing volumes.

RAID 1 — mirroring

Two drives, half the raw capacity, and a simple promise: if one dies, the other keeps serving. Reads can be quick because either drive can answer, writes run at roughly the speed of a single disk, and rebuilds are a straight copy from the survivor rather than a heavy recalculation. For boot volumes, small application servers, and entry-level nodes, RAID 1 is boring in the best possible way.

RAID 5 — striping with single parity

Three drives minimum. You sacrifice the capacity of one drive to parity, so a four-drive array gives you three drives of usable space. Reads are fast, capacity efficiency is good, and you survive one drive failure.

The problem shows up during rebuilds. When a drive fails in a modern array of 12TB or 16TB spinning disks, the rebuild can run for a day or more, during which every remaining drive is hammered with sustained reads while the array carries zero redundancy. That is precisely when a second, already-aging drive tends to give up. RAID 5 still makes sense on SSDs and on smaller-capacity arrays, but on large mechanical disks it has quietly fallen out of favor.

RAID 6 — striping with double parity

Four drives minimum, two drives’ worth of capacity given up, and tolerance for two simultaneous failures. Writes carry a heavier penalty because two parity calculations happen on every operation, but you can lose a drive during a rebuild and still walk away intact. For large-capacity archive, backup, and file servers, RAID 6 has become the sensible default.

RAID 10 — mirrored pairs, then striped

Four or more drives in even numbers, half the raw capacity, and the best balance available for demanding workloads. Because there is no parity to calculate, random write performance is excellent, which is exactly what databases and virtualization hosts need. Rebuilds are also far gentler, since the array copies from one mirror partner rather than reading every drive in the set. You always survive one failure and often survive more, as long as you do not lose both halves of the same mirror.

RAID 50 and 60

These stripe several RAID 5 or RAID 6 groups together. They exist for large arrays where you want parity efficiency without the rebuild characteristics of one enormous group. Unless you are building with a dozen drives or more, you can safely skip them.

Hardware RAID, software RAID, or ZFS

The level is only half the decision. How you implement it matters just as much.

A hardware RAID controller with onboard cache and battery or flash-backed protection handles parity in silicon and presents the array to the operating system as a single disk. It performs consistently and works with almost anything, but the card itself becomes a component you depend on. If it fails, you generally need a compatible replacement before your data comes back.

Software RAID such as Linux mdadm or Windows Storage Spaces uses the host CPU. Modern processors handle parity without breaking a sweat, and the array travels with the disks rather than the controller, which makes recovery far more flexible.

ZFS goes further by checksumming every block, detecting silent corruption and repairing it from redundancy. It wants direct access to the drives through an HBA in pass-through mode, so pairing it with a hardware RAID card defeats the purpose. Budget generous RAM and plan the pool layout carefully before you create it.

One modern caveat: with NVMe drives, a hardware controller is often the bottleneck rather than the accelerator. On NVMe builds, software RAID or ZFS usually gives better results.

Four questions that settle the decision

What is the workload actually doing? Random writes are the deciding factor. Databases, mail servers, and virtualization hosts generate a lot of them and suffer badly under parity, which points to RAID 10. Read-heavy work such as web serving, static file delivery, and archives runs comfortably on RAID 5 or 6.

How much usable capacity do you need? Redundancy is not free. Six 4TB drives give you 24TB raw, which becomes 12TB in RAID 10, 16TB in RAID 6, and 20TB in RAID 5. Work backward from the space you need rather than the drives you happen to have.

How long can you tolerate a rebuild? Larger drives mean longer rebuild windows and a longer period of degraded performance and elevated risk. The bigger your disks, the stronger the case for double parity or mirroring.

What happens if the whole array is lost? RAID protects against drive failure. It does nothing about accidental deletion, ransomware, a corrupt controller, fire or theft. Every RAID plan needs a backup plan sitting behind it.

Mistakes worth avoiding

Treating RAID as backup is the big one, but a few others come up constantly. Mixing drive capacities forces the array down to the smallest disk. Skipping the cache battery on a hardware controller puts in-flight writes at the mercy of a power cut. Running without monitoring means a server can sit in a degraded state for months until the second drive fails and someone finally notices. And on remote or colocated hardware, having no hot spare turns a five-minute automatic rebuild into a scheduled data center visit.

FAQ