What Is RAID? A Practical Introduction
RAID turns a handful of ordinary, individually-unreliable disks into one array that's faster, larger, or more fault-tolerant than any single drive — at a real cost in either money or usable capacity.
The core idea
RAID — Redundant Array of Independent Disks — combines multiple physical drives into a single logical storage unit. Individually, hard drives are relatively slow and fail often enough that betting critical data on a single one is a bad idea. RAID spreads data across several drives using one of a handful of standard layouts (the "RAID levels"), each trading off capacity, speed, and fault tolerance differently. There's no free lunch here: more speed and more redundancy each cost either extra drives or extra money on controller hardware — see the RAID levels reference for exactly how each level spends that budget.
Hardware RAID vs. software RAID
Hardware RAID uses a dedicated controller (built into the motherboard, a PCIe card, or an enterprise storage controller) to handle the RAID logic independently of the OS. Entry-level hardware RAID (onboard chipset RAID, cheap add-in cards) performs similarly to software RAID — its main advantage is letting operating systems that lack native RAID support use fault-tolerant arrays, or letting a system boot directly from a RAID volume. Enterprise-grade hardware controllers add features software RAID generally can't match: battery-backed write caching, hot-swap support without OS involvement, and the ability to build RAID 50/60 arrays that most software RAID implementations don't support at all.
Software RAID, implemented by the OS itself (Linux mdadm/LVM, Windows Storage Spaces/Dynamic Disks, ZFS's built-in RAID-Z), is free and flexible, but has real limitations: you typically can't boot directly from a software RAID 0 or RAID 5 volume without a separate boot partition, and there's no true hot-swap without hardware support underneath it — pulling a live drive without the controller's cooperation risks the whole array.
Do the drives need to be identical?
Using identical drives — ideally from the same batch — keeps firmware and performance characteristics consistent across the array, which is good for predictable performance and avoids one drive becoming a bottleneck. The counter-argument some engineers make is that identical drives from the same batch are more likely to fail around the same time (correlated failure), so deliberately mixing drive models/ages reduces that risk. In practice, this argument mostly highlights that RAID is not a backup either way — if you don't have a real backup, a correlated failure (or a controller failure, or simple accidental deletion) can still take out your only copy of the data regardless of which drives you chose. Get the backup right first; drive diversity is a secondary optimization.
Where practical, drives explicitly built for RAID use (enterprise/NAS-rated drives) include features consumer desktop drives often lack — most notably TLER (Time-Limited Error Recovery, called similar names by other vendors): a desktop drive that hits a bad sector may retry for a long time trying to recover it, which some RAID controllers interpret as a drive timeout and kick the drive out of the array entirely. RAID/NAS-rated drives report the error quickly instead, letting the array's own parity/redundancy handle the recovery without a false-positive drive ejection.
The one thing to remember
RAID protects against a physical disk failing. It does nothing for accidental deletion, ransomware, filesystem corruption, or a controller frying itself and taking the whole array's metadata with it. Pair any RAID array with an actual backup strategy — see the 3-2-1 backup rule guide — and size your array's usable capacity with the RAID Calculator.