Two questions bring people to this page: should my next array be RAID 10 or RAID 5? and my RAID 10 just lost a drive — how scared should I be? Same technology, same answer underneath: it all comes down to how RAID 10 arranges its copies, and the arithmetic of what fails next.
RAID 10 groups drives into mirrored pairs — each pair holding identical copies — then spreads your data across the pairs for speed. Fast because the pairs share the work; safe because every pair is twins.
RAID 5 spreads data plus a calculated safety net (parity) across all drives: you buy N drives and keep N−1 of capacity, and any single drive can die without loss. RAID 10 skips the mathematics and just keeps two of everything: you keep half the capacity, writes fly because nothing is being calculated, and a dead drive is replaced by straight copying from its twin — a rebuild measured in hours, putting gentle load on one survivor, instead of a parity rebuild that hammers every remaining drive for a day or more. That rebuild difference is quietly the decisive one on big modern drives, where the long, punishing RAID 5 rebuild window is precisely when tired second drives fail. The honest buying rule: capacity on a budget → 5 (or 6, its two-failure sibling); databases, virtual machines and anything write-hungry where downtime is expensive → 10 and don’t look back.
RAID 10’s famous claim — ‘can survive multiple drive failures’ — carries a location clause. Failures in different pairs are shrugged off; a second failure inside an already-wounded pair takes that pair’s slice of every file with it, because the twins were the only two copies. And the real world stacks the deck against you: a pair’s two drives are usually the same model from the same production batch, installed the same day, worn by identical work — so when one dies, the survivor isn’t a random drive, it’s the next most likely drive in the building to die, now working harder than ever. Add the human hazards of a degraded-array panic — the wrong drive pulled from the enclosure, a hot spare kicking off an automatic rebuild against a faltering twin — and you have the standard biography of the RAID 10s that reach our bench.
The protocol that keeps a wounded array recoverable fits on a sticky note: power it down, photograph and label every drive with its slot, change nothing, force nothing. Professionally, each member is then imaged read-only and the array is reassembled from the images — the rebuild happens to copies, never to your last originals. That discipline is the backbone of our RAID recovery work, whether the ‘array’ is a rack server or the RAID 10 inside a four-bay NAS under a desk.
No — and this misunderstanding fills recovery benches. RAID 10 protects against one specific event: a drive dying. Deletion, ransomware, corruption, controller failure, fire and theft all replicate instantly and faithfully to both copies. An array keeps you running; only a separate, disconnected copy keeps you safe. You need both, for different reasons.
The safety argument survives; the speed argument shrinks. SSDs are so fast that striping matters less than it did with spinning disks, and many builds get equal protection more simply from a RAID 1 mirror. Where SSD RAID 10 still earns its keep is sustained heavy-write workloads — busy databases, virtualisation — where both the throughput and the fast, low-stress rebuilds still pay.
You can, and it’s how a lot of two-drive disasters start. A degraded array runs with zero remaining protection on that mirror, while the dead drive’s partner — same model, same age, same wear — carries the load alone. If the data matters, treat degraded as an event, not a status: back up now, replace now, and if anything about the rebuild feels uncertain, image first.
Free 48-hour diagnostic on multi-disk arrays at the Bristol lab — every member imaged read-only, rebuilds run against copies, written quote before any work.