RAID level determines how data is distributed, how much redundancy exists, and how hard reconstruction becomes when an array fails. The tables below summarise the layouts we encounter in the laboratory and what each one implies for recovery.
Standard RAID levels
Standard RAID levels
Level
Layout
Minimum drives
Usable capacity (n drives)
Drive failures tolerated
Recovery difficulty
RAID 0
Striping, no redundancy
2
100%
0
High — every member is required
RAID 1
Mirroring
2
50%
n − 1
Low — a single member is a full copy
RAID 5
Striping with distributed single parity
3
(n − 1)/n
1
Moderate — order, stripe size and parity rotation must be solved
RAID 6
Striping with dual distributed parity
4
(n − 2)/n
2
Moderate to high — two parity syndromes to resolve
RAID 10
Mirrored pairs, then striped
4
50%
1 per mirrored pair
Moderate — pair mapping must be identified
RAID 50
RAID 5 groups, then striped
6
Varies by group count
1 per group
High — group boundaries plus per-group parity
RAID 60
RAID 6 groups, then striped
8
Varies by group count
2 per group
High
JBOD / spanned
Sequential concatenation, no redundancy
2
100%
0
Moderate — member order determines file continuity
Parameters required to reconstruct an array
Parameters required to reconstruct an array
Parameter
What it is
Why it matters
Member order
The sequence of physical drives in the set
Wrong order produces structurally valid but corrupt files
Stripe / block size
Bytes written per member before rotating
Wrong size misaligns every stripe boundary
Parity rotation
Left/right, synchronous or asynchronous
Determines which member holds parity for each stripe
Start offset
Where array data begins on each member
Controller metadata regions differ by vendor
Drop-out order
Which member failed first, and when
A stale member carries out-of-date data that must be excluded
Block ordering
Forward or backward parity delay
Affects reconstruction in some vendor implementations
Common RAID failure scenarios
Common RAID failure scenarios
Scenario
What typically happened
Recommended handling
Single member failed, array degraded
Normal drive failure
Label positions, image every member, then reconstruct
Two members failed on RAID 5
Second failure surfaced during rebuild stress
Do not rebuild; image all members including the failed ones
Rebuild started onto a marginal drive
Automatic hot-spare rebuild
Stop the rebuild; the pre-rebuild state may still be reconstructable
Array reinitialised or reconfigured
Administrative error
Power down before further writes; metadata may be rebuildable
Controller failure
Hardware fault on the RAID controller
Member data is usually intact; do not import as a new array
Ransomware on a healthy array
Encryption at the file system layer
RAID provides no protection; restore from backup or snapshots
Notes
Rebuild stress is a real risk: a rebuild reads every sector of every surviving member, which is exactly the workload that exposes latent bad sectors on drives of a similar age.
Labelling the physical order of the members before removing anything saves substantial reconstruction time and reduces the chance of an incorrect result.
RAID is redundancy against drive loss. It replicates deletion, corruption, and encryption events to every member.
