ENGINEERING GUIDE · STORAGE

RAID Engineering Guide

Understand how common RAID levels trade usable capacity, redundancy, performance and rebuild behaviour — and how to choose a sensible layout for a real workload.

Storage engineeringRAID 0 · 1 · 5 · 6 · 10 · 50 · 60Design & operations
The important bit: RAID is an availability and performance mechanism, not a backup. A resilient array can still lose data through deletion, corruption, controller failure, ransomware, fire, theft or an operational mistake. Keep independent backups and test restores.

What RAID does

RAID combines physical drives into a logical storage set. Depending on the level, data is striped across drives, mirrored between drives, protected by parity, or a combination of these techniques. The goal is to provide a useful balance between capacity, performance and resilience.

RAID does not remove the need for monitoring, replacement procedures, capacity planning or backups. It also does not make every workload faster: parity writes, controller limits, queue depth, filesystem behaviour and the storage protocol all affect the result.

Capacity maths

The calculator on Ingenix uses equal-sized drives and reports capacity in the unit selected by the user. A simple first-order model is based on drive-equivalents rather than controller-specific overhead.

LevelUsable capacity modelMinimum drivesBasic failure tolerance
RAID 0N × C2None
RAID 1floor(N / 2) × C2One drive per mirror
RAID 5(N − 1) × C3One drive per RAID 5 group
RAID 6(N − 2) × C4Two drives per RAID 6 group
RAID 10floor(N / 2) × C4Depends on which drives fail
RAID 50Groups × (drives/group − 1) × C6One drive per RAID 5 group
RAID 60Groups × (drives/group − 2) × C8Two drives per RAID 6 group

For example, six 12 TB drives provide 72 TB raw. A six-drive RAID 5 layout provides 60 TB before filesystem and implementation overhead; RAID 6 provides 48 TB; RAID 10 provides 36 TB. These are planning figures, not a promise of the capacity displayed by a particular operating system.

Common RAID levels

RAID 0 — striping

RAID 0 spreads data across all members with no redundancy. It maximises usable capacity and can provide good sequential throughput, but any member failure destroys the array. Use only where the data is disposable or independently reproducible and the risk is explicitly accepted.

RAID 1 — mirroring

RAID 1 keeps copies of data on mirrored members. It is simple and resilient, and reads can often benefit from parallelism. Capacity efficiency is normally about 50% for a two-way mirror. Failure tolerance depends on the mirror design: losing one member of a pair is survivable; losing both members of the same mirror is not.

RAID 5 — single parity

RAID 5 uses distributed parity so one member per RAID 5 group can fail without data loss. It offers better capacity efficiency than RAID 6 or RAID 10, but a degraded array has no remaining single-drive protection. Small random writes can also incur parity read-modify-write work.

RAID 6 — dual parity

RAID 6 maintains two independent parity values and can tolerate two member failures in the same group. The additional protection costs one more drive-equivalent than RAID 5 and can add write overhead. It is often attractive for larger-capacity arrays where rebuild exposure deserves more attention.

RAID 10 — mirrored stripes

RAID 10 mirrors drives in pairs and stripes across those pairs. It provides strong random-write behaviour and predictable redundancy, but usable capacity is approximately half the raw capacity. It can survive multiple failures if they do not remove both members of the same mirror pair.

RAID 50 and RAID 60

RAID 50 stripes across multiple RAID 5 groups; RAID 60 stripes across multiple RAID 6 groups. Splitting a large set into smaller parity groups can improve parallelism and limits the scope of a single group failure, but the failure tolerance is per group. For example, RAID 60 can tolerate two failed drives in each group, while three failures concentrated in one group would exceed that group's protection.

Performance

RAID level is only one part of storage performance. Consider workload mix, read/write ratio, block size, queue depth, latency, controller or software implementation, cache policy, SSD/HDD characteristics and the interface connecting the storage to hosts.

WorkloadEngineering consideration
Sequential readsStriping can aggregate throughput across members, subject to controller, bus and network limits.
Random readsMirrors can provide useful read parallelism; cache and queue depth matter.
Random writesParity RAID can introduce extra I/O and latency for small writes; RAID 10 is often simpler for write-heavy workloads.
Large sequential writesParity overhead may be less severe when writes align with full-stripe operations.

Never infer application performance from the usable-capacity formula alone. Benchmark the actual workload, ideally with representative data, queue depth and concurrency.

Failure and rebuilds

A degraded array has reduced redundancy and may have reduced performance while reconstruction is underway. Rebuild time is affected by drive size, media speed, array layout, controller policy, concurrent application I/O and how aggressively reconstruction is scheduled.

The important operational question is not simply “How many drives can fail?” It is “What happens after the first failure, and how much remaining risk exists while the array is degraded?” A layout with two-drive protection can be valuable when large drives would otherwise leave a long rebuild window.

Drive replacement also deserves engineering discipline. Confirm the failed member, verify the replacement capacity is acceptable, check that the correct slot is being replaced and monitor reconstruction. Do not assume a drive marked “failed” is physically dead without checking controller logs and the actual state.

Rebuild rule: plan the degraded state, not only the healthy state. Document who replaces a failed drive, which spare is used, what alerts fire and what evidence confirms the rebuild completed successfully.

Choosing a RAID level

If your priority is…Typical starting pointWhy
Maximum usable capacity and data is disposableRAID 0No redundancy; simple capacity aggregation.
Simple two-drive resilienceRAID 1Straightforward mirroring.
Capacity efficiency with single-drive protectionRAID 5One parity drive-equivalent.
Additional protection against concurrent failuresRAID 6Two parity drive-equivalents.
Write-heavy or latency-sensitive workloadRAID 10Mirrored stripes avoid parity-write calculations.
Large arrays needing multiple parity groupsRAID 50/60Combines multiple parity groups with striping.

These are starting points, not universal prescriptions. Database vendors, hypervisors, storage platforms and appliance manufacturers may publish specific recommendations. Follow platform guidance where it conflicts with generic RAID advice.

Operational considerations

Backups

Keep backups outside the failure domain of the array. A second array in the same chassis may help availability but is not an independent backup. Test restores regularly.

Monitoring

Monitor physical drive health, predictive failures, media errors, controller state, cache protection, degraded arrays and rebuild progress. An array that silently becomes degraded has already lost part of its intended protection.

Hot spares

A hot spare can reduce the time an array remains degraded by allowing automatic or rapid reconstruction. It does not add usable capacity and does not replace a backup. Ensure the spare is compatible and that the operational process actually uses it as intended.

Capacity and future expansion

Plan for replacement-drive availability and future growth. A replacement drive must normally be at least large enough for the member it replaces, subject to the controller's exact rules. Also consider whether the array can be expanded online and what the rebuild or restriping cost will be.

Deployment checklist

  1. Define the workload: capacity, IOPS, throughput and latency requirements.
  2. Decide how much data loss the storage design can tolerate.
  3. Choose a RAID level and calculate raw versus usable capacity.
  4. Check the storage platform's supported RAID levels, member counts and expansion rules.
  5. Consider degraded performance and rebuild exposure.
  6. Define drive-failure, spare and replacement procedures.
  7. Enable monitoring and alerts for drive, array and controller health.
  8. Provide independent backups and verify restore procedures.
  9. Benchmark the real workload before committing the design to production.
Engineer habit: document the array as an operational system: member count, drive model/capacity, RAID level, group layout, spare policy, controller/software version, backup destination and replacement procedure.

Key takeaways

RAID is a trade-off. RAID 5 and 6 exchange capacity for parity protection; RAID 10 exchanges capacity for mirrored redundancy and strong write behaviour; RAID 50 and 60 combine multiple parity groups. The right answer depends on workload, failure domain, rebuild exposure, platform support and the consequences of data loss.