RAID combines drives into an array with a chosen balance of capacity, performance and tolerance of drive failure. The useful question is not simply whether an array is “redundant.” It is which failures it can survive, what happens while a drive is being replaced, and where you will recover the files if the whole array becomes unavailable.
Start with the layout, then check the implementation
Striping distributes data across drives. Mirroring keeps duplicate copies. Parity stores information from which missing data can be reconstructed within a layout's failure limit. These are ways of arranging data; a RAID number is not a quality score. Linux's multiple-device driver documentation describes the common layouts and their different capacity and failure behavior.
Swipe the table sideways, or focus it and use the arrow keys.
| Level | Common minimum | Nominal capacity | Drive-failure tolerance |
|---|---|---|---|
| RAID 0 | 2 drives | N × D | None; one failed member makes the array's data unreliable or unavailable. |
| RAID 1 | 2 drives | D for a simple mirror | A two-drive mirror survives either one drive failing. |
| RAID 5 | 3 drives | (N − 1) × D | Any one member drive. |
| RAID 6 | 4 drives | (N − 2) × D | Any two member drives. |
| RAID 10 | 4 drives, even count for paired mirrors | (N ÷ 2) × D | Any one drive; additional failures depend on which mirror pairs they affect. |
Here N is the number of active member drives and D is their equal usable member size. These are conventional layouts, not a promise that a particular enclosure supports them. For example, Seagate's RAID Manager level guide specifies higher RAID 5 and RAID 6 minimums for its 8big Pro5 background-initialization implementation. Check the exact product, software version, supported disks and expansion rules before buying drives.
Performance also depends on the workload, controller or software, cache behavior, drive technology and number of members. A long sequential copy and many small synchronized writes are different tests. Parity updates introduce work, but “RAID 10 is always faster” is not a reliable application benchmark. Measure the operation you need, including performance during recovery.
Work through a capacity example
Download the verified capacity examples (CSV). They assume equal drives and the conventional layouts above. Mixed-size arrays commonly leave some space unused; flexible storage pools may behave differently. A hot spare waiting outside the active array does not contribute to these capacity figures. Do not include a spare twice when counting the disks you need.
Plan the data separately: current files, expected growth, retained versions and working space. An array with 16 TB nominal capacity is not automatically suitable for 16 TB of planned files. The NAS planning guide shows how to budget data and versions before choosing a storage layout.
RAID 10 illustrates why the failure pattern matters
Imagine four drives named A1, A2, B1 and B2. A1 and A2 form one mirror; B1 and B2 form the other. If A1 fails, A2 still holds that pair's data. If B1 then fails, both pairs still have a surviving member. If A2 instead fails before A1 has been successfully rebuilt, the first pair has lost both copies and the array cannot provide all its data.
Thus a four-drive RAID 10 can survive some two-drive failures, but not any two-drive failure. RAID 6's two-member tolerance is a different property. Neither statement covers every possible controller fault, unreadable sector, firmware defect, power event or administrative mistake. Treat the level's tolerance as a layout property under stated conditions, not a guarantee of recovery.
Prepare for replacement before a disk fails
- Record the array's configuration, drive serial numbers and slot mapping. Configure alerts and make sure someone receives them.
- Confirm the backup can be restored independently. If the array is already degraded and other members show errors, consider recovery advice before imposing an intensive rebuild.
- Use the documented identification procedure to confirm the failed member. A drive letter or a guessed bay number is not enough.
- Check the replacement's supported model, capacity and sector-format requirements. Follow the exact product procedure; hot-swap support is not universal.
- Monitor the rebuild, remaining drives and workload. Confirm completion, health status and a sample of restored access before closing the incident.
A hot spare can let a supported system start rebuilding sooner, but it does not restore redundancy at the moment the first disk fails. Rebuild duration depends on array size, device speed, workload and recovery settings. Avoid a fixed “hours per terabyte” promise. Keep a record of measured recovery behavior and revise your downtime plan accordingly.
Do not experiment with force-assembly or initialization commands on the only copy of important data. The Linux MD administration guide explains why a dirty, degraded parity array can contain undetectable corruption; getting a volume to mount is not proof that its contents are correct.
RAID, snapshots and backup solve different problems
A snapshot can help retrieve an earlier version, but a snapshot stored only in the same failed or compromised system may be inaccessible with it. RAID can preserve service through certain member failures, while accidental deletion or unwanted encryption can be written consistently across the array.
Maintain an independent backup with an appropriate isolation and retention plan, and test restoration. CISA's ransomware guidance recommends protected backups and regular recovery testing. The portable storage guide discusses a separate-copy workflow; the important result is a usable recovery path when the primary array and its usual administrator account are unavailable.