A server stores its database on one 8 TB drive. If that drive fails, the server loses access to all 8 TB until an administrator restores the data elsewhere.

Adding more drives creates an opportunity. The operating system or a storage controller can combine them into one logical block device and place data across the drives according to a chosen layout. Some layouts improve performance, some preserve data when a drive fails, and some do both.

This technique is called RAID, originally “Redundant Array of Inexpensive Disks” and now commonly expanded as “Redundant Array of Independent Disks.”

RAID does not make storage failure-proof. It changes which failures the system can tolerate and how much capacity and performance it gives up to do so. Understanding a RAID level therefore requires more than remembering its number.

A RAID implementation sits between its member devices and the code using the storage:

The filesystem usually sees one device, such as /dev/md0, rather than four independent drives. When it submits a block request, the RAID layer determines which members must participate.

For a read, the layer may select one copy, read several members in parallel, or reconstruct missing data. For a write, it may split the data across members, update multiple copies, or calculate parity.

The layout determines:

RAID can be implemented in software by the operating system, in a dedicated storage controller, or inside an external storage system. The basic layouts are the same, but management, caching, failure reporting, and performance can differ.

Most common RAID levels combine three ideas: striping, mirroring, and parity.

Striping

Striping divides the logical address space into fixed-size chunks and distributes consecutive chunks across member devices.

With a two-drive stripe:

If each chunk is 64 KiB, logical bytes 0 through 65,535 might be stored on Drive 0, and the next 64 KiB on Drive 1.

Striping can let multiple drives serve different parts of a large request in parallel. It also distributes independent requests across the members. By itself, however, striping provides no redundancy.

Mirroring

Mirroring stores identical copies of data on multiple members:

A read can use either copy. A write must update every required copy before the RAID layer can safely report the mirrored write as complete.

Mirroring sacrifices capacity but makes reconstruction straightforward: copy the surviving member to a replacement.

Parity

Parity stores enough derived information to reconstruct missing data without keeping a complete second copy.

For a simple single-parity stripe containing three data chunks:

If B is unavailable:

This works because XORing a value with itself cancels it. The same calculation is applied bit by bit across the chunks.

Parity is not a compressed copy of one member. It describes a relationship among all the chunks in a stripe. Changing one data chunk also requires updating the corresponding parity.

RAID 6 keeps two independent forms of redundancy. Its second calculation is more sophisticated than simply storing the same XOR parity twice, allowing any two missing member chunks in a stripe to be recovered.

A member is one drive or block device participating in the array. A physical drive, partition, logical volume, or remote block device can technically be a member, though useful fault tolerance requires members with appropriately independent failure risks.

A chunk is the amount of consecutive data placed on one member before striping moves to another.

A stripe is the set of chunks at one position across the members. Depending on the RAID level, a stripe can contain data chunks, parity chunks, or mirrored copies.

For a four-member RAID 5 array with a 64 KiB chunk size, each stripe contains three data chunks and one parity chunk. Its full-stripe data width is:

A degraded array has lost one or more active members but is still operating from remaining data and redundancy.

A spare is an available member that is not currently carrying the array's normal data. It can be activated when another member fails.

A rebuild or recovery reconstructs the missing contents onto a replacement or spare. A resync verifies or regenerates redundancy across members, often after an unclean shutdown or array change.

These terms describe different states and operations. A degraded array is serving live I/O with reduced protection; a rebuild is the work intended to restore that protection. A spare can shorten the delay before rebuilding starts, but it does not restore redundancy merely by being present. Protection returns only as reconstruction progresses and completes.

RAID 0 distributes data across two or more members without storing mirrors or parity.

For four drives:

If all members have usable size S, an N-member array provides approximately:

The array can use the combined bandwidth and capacity of all members. Large sequential operations can be divided across drives, and independent requests can run in parallel.

The cost is complete dependence on every member. If any one drive fails, every stripe containing a chunk from that drive becomes incomplete. Because logical files normally span many stripes, the entire array should be treated as lost.

RAID 0 is appropriate only when data loss is acceptable or when another independent layer already provides the required redundancy. Examples include reproducible scratch data and temporary processing space. Despite its name, RAID 0 is not redundant.

RAID 1 writes the same data to two or more members.

With N equal-sized members in an N-way mirror:

A common two-drive mirror uses half of the raw capacity. A three-way mirror uses one third.

RAID 1 can survive the loss of all but one mirror member, as long as the remaining copy is readable and consistent. This is a useful example of why “number of failed drives” is not the whole story: the layout and location of the remaining copies matter.

Read requests can be balanced across members. This can improve read concurrency, and a controller may choose the member that can respond sooner. Each logical write must reach every active mirror copy, so mirroring does not multiply write throughput in the same way as RAID 0.

Rebuilding a mirror usually reads the surviving copy and writes it to the replacement. The operation is conceptually simple, but it still scans a large amount of data and competes with application I/O.

RAID 1 works well for small arrays where simple failure recovery and predictable behavior are more valuable than capacity efficiency.

RAID 5 combines data striping with one parity chunk per stripe. It requires at least three members.

Parity is distributed rather than assigned permanently to one drive:

P0 protects A, B, and C; P1 protects D, E, and F; and so on. Rotating parity avoids making one member the parity target for every stripe.

For N equal-sized members:

The capacity of one member is consumed by parity across the whole array, although no single drive contains all of it.

Reading after a failure

If one member fails, RAID 5 remains available in degraded mode. When an application requests a missing chunk, the RAID layer reads the other data chunks and parity from that stripe and reconstructs the result.

For example, if the drive containing B fails:

Every reconstructed read requires extra member activity. Degraded performance can therefore be substantially worse than normal performance, especially under a busy random-read workload.

RAID 5 cannot tolerate a second member failure before redundancy is restored.

The small-write penalty

A full-stripe write supplies every new data chunk in the stripe. The RAID layer can calculate new parity directly from those chunks:

A small write changes only part of a stripe. One common update method is read-modify-write:

One logical write can therefore produce two reads and two writes on the member devices. This is the classic RAID 5 small-write penalty.

The exact implementation can choose other strategies, such as reconstructing parity from the unchanged data chunks. Which strategy wins depends on how much of the stripe is being updated and the current workload.

RAID 5 offers good capacity efficiency and strong sequential-read performance, but parity updates, degraded reads, and the single-failure limit are important constraints.

RAID 6 extends the distributed-parity design with two independent redundancy chunks per stripe. It normally requires at least four members.

For N equal-sized members:

The array can tolerate any two member failures. This is particularly valuable during a long rebuild: after one member fails, one additional member can fail without immediately losing the array.

The extra protection has costs. Two members' worth of capacity is consumed, and writes must update two forms of parity. Small random writes therefore require more work than in RAID 5. Degraded operation and rebuilds also involve additional calculations and member I/O.

RAID 6 is often chosen for larger, capacity-oriented arrays where surviving a second failure during recovery matters more than minimizing write latency. It does not remove rebuild risk; it gives the system a larger fault-tolerance margin while the rebuild is in progress.

RAID 10 combines mirroring and striping. In the common four-drive layout, the drives form two mirror pairs, and data is striped across those pairs:

With two copies and an even number of equal-sized members:

RAID 10 can service reads from either member of each pair and perform work across multiple mirror pairs in parallel. Writes do not require parity calculations or read-modify-write cycles, though every write must reach both members of its pair.

Failure tolerance depends on which members fail. In the four-drive example:

It is therefore misleading to describe RAID 10 as simply tolerating a fixed number of arbitrary failures. It can survive at least one member failure, and potentially several, provided no mirror group loses every copy.

Rebuilding reads the surviving member of the affected mirror rather than reading every surviving member to reconstruct parity. This generally gives RAID 10 faster, more localized rebuild behavior than a comparable parity array.

RAID 10 is a common choice for write-heavy databases and latency-sensitive storage where predictable writes and rebuilds justify using half the raw capacity.

Assume N equal-sized members and let S be the usable size of the smallest member.

Real usable capacity is slightly lower because array metadata, alignment, and other storage layers consume space. When members have different sizes, common layouts can generally use only as much of each member as the smallest one provides.

The table describes failure tolerance, not data safety in every situation. Controller failure, software bugs, undetected corruption, and simultaneous loss of an entire fault domain can exceed these guarantees.

Consider four 2 TB drives.

RAID 0 uses all four drives for data:

RAID 1 as a four-way mirror stores the same data four times:

RAID 5 consumes one drive-equivalent for parity:

RAID 6 consumes two drive-equivalents for dual parity:

RAID 10 creates two mirrored pairs:

RAID 6 and RAID 10 provide the same usable capacity in this example, but they do not provide the same behavior. RAID 6 survives any two drive failures, while RAID 10's survival depends on which drives fail. RAID 10 avoids parity updates and can rebuild from one mirror partner.

Capacity alone cannot select the layout.

The trade-off becomes clearer with six 2 TB drives.

A six-drive RAID 5 provides approximately:

A six-drive RAID 10 with three mirrored pairs provides:

RAID 5 wins decisively on usable capacity. It can also provide excellent sequential throughput when requests span whole stripes. The price is single-failure tolerance, parity work, and expensive small writes.

RAID 10 uses four additional terabytes of raw capacity for copies in this example. In return, it avoids the parity read-modify-write path, distributes I/O across mirror pairs, and rebuilds an affected pair from its surviving copy.

For a read-heavy archive with independent backups and a moderate write rate, parity RAID may make capacity-efficient sense. For a write-heavy database with strict latency goals, RAID 10 is often the more predictable design.

That is a workload-based choice, not a universal ranking. Storage devices, queue depth, request size, controller behavior, recovery targets, and budget all affect the result.

Redundancy matters most after a member fails. At that moment, however, the array enters its most vulnerable and often slowest operating state.

Serving I/O while degraded

A mirrored array reads missing data from another copy. A parity array reconstructs missing data from the remaining chunks in each stripe.

Application I/O and reconstruction work compete for the same drives. Latency can rise even before a rebuild begins, and a busy application can slow the rebuild.

The array is also operating with less redundancy:

RAID 10's remaining margin depends on which mirror groups are degraded.

What a rebuild does

When a replacement or hot spare becomes available, the RAID layer reconstructs the missing member:

The process may need to read many terabytes. An idealized rebuild of 12 TB at an effective 150 MB/s takes:

Real rebuilds often take longer because the rate varies, application traffic shares the devices, and slow or unreadable regions require extra work.

During that interval, another device failure can exceed the array's remaining tolerance. A previously unnoticed unreadable sector on a surviving member can also become important precisely when the rebuild needs to read it.

Fast failure detection, available replacement capacity, monitoring, and tested recovery procedures are therefore part of the RAID design. Merely choosing a redundant level is not enough.

A parity update changes at least two pieces of persistent state: data and parity. A crash or power failure between those writes can leave them inconsistent.

The array is briefly inconsistent during every parity update. A power loss inside that window leaves stripes that no longer verify.

This problem is known as the RAID write hole. After restart, the array may not know whether the data or parity represents the intended state. If a member later fails, reconstruction using incorrect parity can return corrupted data.

Implementations use several techniques to protect parity consistency:

A write-intent bitmap records which regions may need resynchronization and can greatly reduce the amount of work after interruption. A bitmap by itself should not be confused with end-to-end data checksumming or a universal solution to every partial-stripe consistency problem.

The exact protection depends on the RAID implementation and its configuration. Systems that require strong crash behavior must verify that the complete path, including controller caches, has appropriate power-loss and consistency guarantees.

Redundancy helps recover unavailable blocks, but it does not automatically detect every incorrect block.

Suppose two mirror copies disagree. Without an independent checksum, the RAID layer may know that the copies differ but not which one contains the correct application data. A parity mismatch has a similar ambiguity: data may be wrong, parity may be wrong, or more than one component may be involved.

A scrub reads the array and checks mirrors or parity while all expected members are present. This can discover latent read errors and redundancy mismatches before a rebuild depends on those regions.

Regular scrubbing reduces surprises, but RAID parity is not an end-to-end checksum of application data. Strong integrity designs use checksums with enough context to identify the expected contents, plus a redundant copy from which verified data can be repaired.

RAID also faithfully stores bad writes. If software writes incorrect bytes, the array mirrors them or updates parity to match them.

RAID improves availability for specific member failures. A backup preserves an independent recoverable copy of data.

If an administrator deletes a directory, RAID mirrors the deletion. If ransomware overwrites a database, every member receives the changed blocks. Filesystem corruption, application bugs, stolen equipment, fire, and a failed controller can affect the entire array.

A backup should therefore be separated from the live array according to the failures it must survive. That can require a different system, credentials, location, or retention history.

The distinction is concise:

RAID helps the service continue through a storage-device failure. A backup helps recover data after the live system is damaged or lost.

Both may be necessary, but one does not replace the other.

With software RAID, the operating system maps logical requests to member devices. Linux's Multiple Device driver, commonly called MD, can expose an array as a block device such as /dev/md0. Array metadata stored on the members describes the level, member roles, and state so the operating system can assemble the array after reboot.

Software RAID uses host CPU and memory, but modern systems can perform common mirroring and parity calculations efficiently. It also gives the operating system direct visibility into member health and scheduling.

With hardware RAID, a dedicated controller presents one or more logical drives to the operating system. The controller performs layout calculations and manages members behind that interface. A power-protected controller cache can absorb writes safely and help protect parity updates, provided its hardware and configuration guarantees are sound.

The abstraction can also hide detail. Operating-system tools may see one healthy logical disk while a physical member has failed unless controller-specific monitoring reports it.

Neither implementation is automatically superior. The important questions are:

Creating several RAID members as partitions on the same physical drive does not protect against that drive failing. Redundancy is meaningful only when copies or parity span the failure domains the system intends to tolerate.

Start with the failure requirement rather than the desired RAID number.

If losing any member must not interrupt access, RAID 0 is immediately excluded. If the system must tolerate any two concurrent member failures, ordinary RAID 1 with enough copies or RAID 6 can satisfy that condition; common RAID 10 cannot promise survival of every arbitrary two-drive combination.

Then consider the workload. Large sequential reads can benefit from most striped layouts. Small random writes expose parity-update costs. Latency-sensitive, write-heavy storage often favors mirrors, while capacity-heavy, read-dominant storage may justify dual parity.

Rebuild behavior matters too. Estimate how long reconstruction will take at a realistic rate while production traffic is running. During that interval, identify which additional failures the degraded layout can survive.

Finally, plan for failures outside the RAID model. Monitoring should make a degraded state visible quickly, replacement procedures should be rehearsed, integrity should be checked, and independent backups should be restorable.

A good RAID choice is a statement about the whole operating environment:

No RAID level optimizes all of these at once.

RAID combines multiple storage members into one logical block device. Striping distributes work, mirroring stores complete copies, and parity stores derived information that can reconstruct missing data.

RAID 0 offers capacity and parallelism without redundancy. RAID 1 provides simple mirroring, RAID 5 tolerates one failure with distributed parity, RAID 6 tolerates any two failures with dual parity, and RAID 10 stripes across mirrors for predictable writes and localized rebuilds.

Capacity and healthy-state performance are only part of the design. Degraded operation, rebuild duration, parity consistency, failure domains, monitoring, and data integrity determine how the array behaves when it is needed most. RAID can improve availability after device failure, but it is not a backup.