STORAGE PERFORMANCE
RAID, Storage Performance and Resilience Playbook
Usable capacity, failure tolerance, rebuild risk, IOPS, latency, cache and why RAID is not backup.
RAID solves a different problem from backup
RAID can keep a storage set available after certain drive failures. It does not protect against accidental deletion, ransomware, corruption copied across the array, fire, theft or a failed storage controller that destroys data. A backup should be independently recoverable.
Capacity formulas using equal-size drives
| Layout | Usable capacity | Basic failure tolerance | Notes |
|---|---|---|---|
| RAID 0 | N x S | None | Any member failure loses the array. |
| RAID 1, two drives | S | One drive | Mirrored pair. |
| RAID 5 | (N - 1) x S | One drive | Distributed parity. |
| RAID 6 | (N - 2) x S | Two drives | Dual parity. |
| RAID 10 | (N / 2) x S | Depends which members fail | Striped mirrored pairs, even drive count. |
N is the drive count and S is the capacity of the smallest member drive. Controller metadata, filesystem overhead, decimal/binary units and spare drives reduce usable capacity further.
Why RAID 5 and RAID 6 writes can cost more
Parity RAID must maintain parity information when data changes. Depending on controller, workload and write size, this can involve reading existing data/parity and writing updated data/parity, or reconstructing full-stripe parity. The practical result is that small random writes can behave very differently from sequential reads.
RAID 10
RAID 10 avoids parity calculations and provides mirrored redundancy with striping across mirror sets. It uses about half the raw equal-drive capacity. It can survive more than one failed drive only when the failed drives are in different mirror pairs. It is not correct to say RAID 10 always tolerates any two drive failures.
Rebuilds
A degraded array runs with reduced redundancy and may have lower performance. Rebuild time depends on drive size, drive speed, controller behaviour, workload and rebuild priority. Large-capacity drives can take substantial time to rebuild under production load. Monitor the array until it returns to a protected state.
Hot spare
A hot spare lets the controller begin rebuilding without waiting for a technician to install a replacement, if the controller and policy support that behaviour. It does not add active usable capacity while idle, and it does not replace a backup.
Performance terms
- IOPS: operations completed per second.
- Latency: time taken to complete an I/O request.
- Throughput: amount of data transferred per second.
- Queue depth: number of outstanding I/O requests presented to a device or path.
High IOPS with poor latency can still produce a bad application experience. Large sequential transfers and small random database I/O are different workloads and should not be compared using one benchmark number.
Cache
Controller write-back cache can improve perceived write latency because data is acknowledged before it reaches the slower media. Safe write-back operation depends on protected cache and the controller/storage design. Do not enable unsafe write-back caching simply to make a benchmark look better.
Storage commissioning
- Confirm physical drives and firmware are recognised.
- Confirm intended RAID layout and hot-spare policy.
- Verify logical volume size.
- Run a consistency/background initialisation process if required by the controller.
- Measure workload-relevant performance, not only sequential throughput.
- Test alerting for failed/degraded drive state.
- Verify backup and restore separately from RAID health.
Storage Architecture Playbook | RAID Capacity Calculator | Server Hard Drives | Server SSD Drives