RAID is often described as a backup solution. It is not. RAID is a storage architecture that can provide redundancy and, depending on the level, different performance and capacity characteristics.
Practical example: choosing RAID for a file server
RAID availability and backup recovery solve different problems.
Scenario: A business file server needs usable capacity, reasonable write performance and tolerance for a drive failure.
RAID 0 would provide no redundancy, so it is unsuitable for this requirement. RAID 1 is simple but uses half of the raw capacity for mirroring. RAID 5 and RAID 6 introduce parity and different failure-tolerance and write-performance trade-offs. RAID 10 combines mirroring and striping but also has a significant capacity overhead.
Decision: Choose the RAID level from the workload, number of drives, rebuild risk, usable-capacity requirement and controller support. Then create a separate backup because RAID does not protect against deletion, corruption, malware or loss of the entire server.
Common mistakes and selection checklist
Common mistakes
- Selecting RAID only from the amount of usable capacity it provides.
- Ignoring rebuild time, drive count, write workload and the consequences of another drive problem during recovery.
- Treating RAID as a backup.
What happens if you get it wrong?
The array may have the wrong performance or resilience characteristics for the workload. A controller, corruption, deletion, malware event or complete system loss can still make the data unavailable even when the RAID level itself is working as designed.
Selection checklist
- Define the usable-capacity target and workload before selecting a RAID level.
- Check the minimum and practical drive count for the chosen layout.
- Consider write behaviour, rebuild exposure and failure tolerance.
- Verify controller, drive and server-platform support.
- Maintain a separate tested backup and recovery process.
A resilient array keeps services available during some drive failures. Separate backups provide recovery from deletion, corruption, malware and site loss.
Why use RAID?
One reason is to reduce the impact of a drive failure. With an appropriate redundant RAID configuration, a failed drive can be replaced while the remaining data remains available, subject to the design and condition of the array.
RAID levels are different
| RAID level | General characteristic |
|---|---|
| RAID 0 | Striping without redundancy. A drive failure can result in loss of the array. |
| RAID 1 | Mirroring. Data is duplicated across drives, reducing usable capacity. |
| RAID 5 | Striping with distributed parity, providing redundancy with less capacity overhead than mirroring. |
| RAID 6 | Striping with additional parity, providing protection against multiple drive failures within the design limits. |
| RAID 10 | Combines mirroring and striping, trading drive capacity for redundancy and performance characteristics. |
Usable capacity is not raw capacity
If several drives are installed, the total raw drive capacity does not necessarily equal the usable capacity presented to the operating system. The RAID level and configuration determine how capacity is used.
RAID does not replace backups
RAID is designed around drive availability and storage resilience. It does not protect against accidental deletion, corruption, malware, theft, fire or other events that can affect the entire system.
Rebuilds are part of the design
When a drive fails in a redundant array, the array may need to rebuild. The impact of a rebuild depends on the RAID level, drive configuration, workload and controller or storage system.
Choose RAID around the workload
The correct RAID level depends on capacity requirements, performance, redundancy requirements, drive count, workload and the consequences of failure.
- How much usable capacity is required?
- How many drives are available?
- What level of redundancy is required?
- What performance is required?
- How will failed drives be replaced?
- What is the separate backup strategy?
A resilient storage design still needs a separate backup strategy appropriate to the data and business.
Confirm the exact product specification, supported configuration and compatibility before ordering. Platform generation, firmware, licences and optional components can change what a product supports.