Once hard drives pass the 20TB mark, the arithmetic behind data protection changes. A RAID rebuild can take hours, and every one of those hours is a window in which a second failure means data loss. That is why scale-out file and object platforms have largely moved away from classic RAID towards erasure coding — a technique that, in one Computer Weekly worked example, is described as up to 10,000× more resilient than RAID 6 while tolerating the loss of two or more storage elements at once. This explainer sets out, with every caveat intact, how RAID and erasure coding actually work, where each still wins in 2026, and what UK buyers pricing large HDD or object-storage estates should compare beyond headline £/TB.
Why the protection model matters more once drives get bigger
RAID rebuild time is governed by how fast data can be written back to a replacement drive. Rack2Cloud's illustrative scenario puts a RAID write path at around 2GB/s, giving a rebuild time of roughly 5.5 hours for that example array. As drive capacities climb past 20TB, that rebuild window stretches, and the array spends longer running in a degraded state — the period when a second failure turns an inconvenience into permanent data loss.
Traditional RAID and erasure coding both exist to survive drive failure, but Xinnor's guidance frames the difference as one of scale: RAID is typically optimised for smaller, local disk arrays, while erasure coding is built for distributed systems that can tolerate the loss of many fragments or nodes, depending on how the scheme is configured. That distinction — one array versus many nodes — is the thread running through everything below.
RAID reimagined: what a rebuild actually involves
Classic RAID 5 and RAID 6 protect data with parity calculated across the drives in a single array, sitting behind one controller. Computer Weekly notes that RAID remains the better fit for small-block data patterns — the kind of transactional, latency-sensitive I/O typical of local block storage. When a drive fails, the controller reconstructs the missing data from the surviving drives and parity, but that reconstruction is bounded by the write speed of the replacement drive — hence Rack2Cloud's ~5.5-hour illustrative figure at a ~2GB/s write path.
Software-defined and ZFS-style implementations have modernised how RAID is delivered without changing this fundamental constraint: the protection domain is still one array. Readers sizing arrays and modelling parity overhead against usable capacity can use our RAID calculator, and for a deeper look at how modern software RAID stacks compare with hardware controllers, it's worth reading a dedicated comparison to delve into ZFS RAID-Z versus hardware RAID.
Erasure coding explained: fragments, not just parity
SNIA describes erasure coding as a parity-based protection technique that breaks data into fragments, stores them across different locations, and can allow failure of two or more elements of a storage system. MinIO's implementation makes this concrete: it uses configurable parity between 2 and 8 blocks, letting an operator choose how many simultaneous losses — drive or node — the system tolerates. Because fragments are spread across nodes rather than confined to one enclosure, MinIO notes that objects can be reconstructed without downtime.
VMware's December 2025 guidance frames the space-efficiency case plainly: erasure codes provide much more space efficiency than traditional mirroring, spreading a unit of data across multiple failure domains such as disks or hosts rather than duplicating it wholesale. An ACM survey adds the formal version of this trade-off — erasure coding delivers higher reliability than replication at the same storage overhead, or achieves the same reliability with significantly less overhead than replication.
How reconstruction actually works, step by step
In RAID 5/6, reconstruction is arithmetic performed within the array: the controller reads the surviving drives, recomputes the missing block from data and parity, and writes it to the replacement drive — a process gated by that single drive's write speed, which is why the rebuild window scales directly with drive capacity.
In an erasure-coded system, a data object is split into fragments and protected by additional parity fragments distributed across separate nodes or racks (SNIA's model). Reconstruction only needs enough surviving fragments to reach the scheme's minimum threshold — it does not depend on one drive's write speed, and because fragments live on different nodes, several can often be rebuilt in parallel across the cluster rather than serialised through a single controller.
Fault tolerance and efficiency, with the numbers that exist
Computer Weekly's worked example describes an erasure-coded configuration as up to 10,000× more resilient than RAID 6 while tolerating loss of two or more storage elements — a figure scoped to that specific feature's example, not a universal multiplier. TechTarget confirms the general direction: erasure coding can exceed RAID 6 in the number of failed drives it tolerates, increasing fault tolerance. Supermicro similarly positions erasure coding as extensively used in distributed storage for massive volumes, with higher fault tolerance than traditional RAID.
At larger scale, an IEICE study modelling a 1,000-drive system found that a distributed-stripe, erasure-coding-style rebuild approach reduced data-loss probability by two orders of magnitude compared with normal RAID — a result explicitly framed at 1,000-drive scale, relevant to modern scale-out clusters rather than small RAID shelves. StoneFly summarises the practical split: RAID for protecting against one or a few disk failures, erasure coding when multiple simultaneous failures must be tolerated at lower overhead than full replication.
The trade-off is compute, not just capacity. SNIA's guidance is direct: erasure coding is CPU-intensive and can increase latency for production writes and rebuilds. The brief does not quantify this in IOPS or milliseconds for specific hardware, but the operational implication is real — any deployment plan should include vendor-specific latency testing under representative write loads before committing, rather than assuming CPU headroom is free. On scheme choice, MinIO's 2-to-8 configurable parity range illustrates the general principle: wider parity buys more fault tolerance at the cost of more computation per write and more capacity spent on parity fragments, so the right setting depends on how many simultaneous failures the deployment must survive.
View the data behind this chart
| Layer | Detail |
|---|---|
| Headline disk price | £/TB raw capacity quoted by the vendor |
| Rebuild risk exposure | Longer degraded windows on 20TB+ drives |
| Spare-drive policy | Hot/cold spares provisioned per array |
| Usable capacity overhead | RAID parity vs erasure-code k+m ratio |
| Failure-domain design | Single array vs distributed multi-node |
UK buyer context: what actually changes at scale
Block-storage RAID remains common in local arrays across UK infrastructure, but scale-out NAS and object platforms increasingly default to erasure coding for better usable capacity and failure-domain isolation. That shift matters most when quoting large-capacity HDD estates, multi-site object storage, or cloud-native backup targets, because longer RAID rebuilds on 20TB-plus drives increase operational risk and can make controller-based designs harder to justify on resilience grounds alone.
Neither protection model is a substitute for backup — RAID and erasure coding both defend against hardware failure, not against accidental deletion, ransomware or application-level corruption, so it's worth revisiting why RAID is not a backup before treating either as a recovery strategy on its own. Where recovery time objectives are tight, the rebuild or reconstruction mechanism itself becomes part of RTO: a RAID array stuck in a multi-hour degraded rebuild is a live risk to recovery point integrity if a second fault occurs during that window, which is precisely the exposure erasure coding's distributed reconstruction is designed to reduce.
The cost equation: comparing total cost of resilience, not just £/TB
Vendors price storage per usable TB or per node, and headline disk price is only one layer of the real comparison. UK procurement should weigh rebuild exposure — how long an array or cluster runs degraded after a failure — alongside spare-drive policy, the usable-capacity ratio a given RAID level or erasure-coding scheme actually delivers, and whether the failure-domain design is a single array or a distributed set of nodes. Where vendors price per usable TB, erasure coding can improve the economics, but the comparison that matters is total cost of resilience across the estate's lifetime, not the sticker price on a drive shelf.
Making the call: a practical decision framework
Traditional RAID remains the unequivocally better choice in 2026 wherever the workload is small-block and latency-sensitive, the deployment is a single local array rather than a distributed cluster, management simplicity matters more than maximum fault tolerance, and CPU headroom for parity computation is limited — precisely the scenario Computer Weekly and SNIA describe RAID as best suited to. Erasure coding earns its complexity once the estate is genuinely distributed: object storage, large-capacity HDD fleets, multi-node or multi-site clusters, and any environment where tolerating two or more simultaneous failures matters more than shaving compute overhead.
Xinnor's broader framing is useful here: RAID is, mathematically, a form of erasure coding, and modern software-defined storage increasingly blurs the line — VMware's vSAN guidance from December 2025 explicitly distinguishes its erasure-code option from mirroring within an otherwise conventional enterprise storage array. For multi-site or hybrid deployments, MinIO's node-distributed model is the relevant architecture: fragments spread across separate failure domains so an object can be reconstructed without downtime even if an entire site is unreachable. Buyers unsure which model fits their workload can work through a storage solution finder before committing to either architecture.
Sources
Every figure in this article traces to the sources below.
- •Xinnor — RAID vs erasure coding terminology and scale framing
- •Computer Weekly — resilience and failure-tolerance example vs RAID 6
- •Computer Weekly — erasure coding for large/object data vs RAID for small-block data
- •VMware — erasure codes vs mirroring space efficiency and failure domains
- •MinIO — erasure coding for object storage and configurable parity range
- •SNIA — erasure coding mechanics, CPU intensity and latency trade-offs
- •ACM — erasure coding reliability vs overhead compared with replication
- •IEICE Transactions on Information and Systems — 1,000-drive reliability study
- •TechTarget — erasure coding fault-tolerance definition
- •Supermicro — erasure coding in distributed storage systems