01
Write the recovery requirement first
Define the failure model in plain language: one device, two devices, a controller, accidental deletion or the whole server. RAID addresses only some device failures. Set a recovery-time objective for service restoration and a recovery-point objective for data loss, then identify which requirement the local array can satisfy and which requires replication or backup elsewhere.
Also record whether the system must continue accepting writes while degraded. A read-mostly archive, a write-heavy database and disposable scratch space may all use the same number of drives but need different layouts. Capacity efficiency is therefore one constraint, not the verdict.
02
Match the layout to the workload and device count
Mirrors are straightforward for a two-device boot or data set and can suit random I/O where independent mirrored groups are useful. Parity layouts trade write work and reconstruction complexity for more capacity. Double parity can preserve an additional failure margin in a wide HDD set, while RAID 10 trades half of raw capacity for mirrored pairs. These are design tendencies, not performance guarantees; controller, filesystem, queue depth, record size and application pattern all matter.
Use the actual catalogue topology. The 12-drive and 24-drive storage servers allow choices unavailable on a two-NVMe compute server. Do not join the separate NVMe boot pair to the data-array calculation, and do not assume one very wide group is preferable to several groups without modelling fault domains and I/O behaviour.
Match the layout to the workload and device count| Workload question | Layout to evaluate | Reason to validate |
|---|
| Two local devices and continuity required | Mirror | One-device capacity and a simple degraded state |
|---|
| Wide HDD pool with two-failure requirement | RAID 6 or RAIDZ2 | Parity width, rebuild load and filesystem guidance |
|---|
| Random writes and multiple even drive pairs | RAID 10 or mirrored vdevs | Capacity trade-off and real workload latency |
|---|
| Disposable data with a reproducible source | RAID 0 may be considered | Any member loss loses the array |
|---|
03
Choose one layer to own redundancy
Decide whether a hardware controller, Linux MD or a filesystem such as ZFS owns the layout. Avoid stacking independent RAID layers without a documented reason because health and replacement state can become ambiguous. ZFS redundancy is expressed through mirrors or RAIDZ vdevs and relies on checksums; a lost top-level vdev can lose the pool, so adding a lone non-redundant device to an otherwise redundant pool changes the failure model.
Confirm drive identity, replacement procedure, boot behaviour and what the operating system can observe before creating the array. Changing topology later may be constrained or disruptive, particularly for parity layouts.
04
Plan the degraded and reconstruction window
Monitoring must distinguish healthy, degraded, reconstruction and consistency-check states. Linux MD exposes actions such as resync, recover, check and repair; collect progress and mismatches rather than reporting only that the volume is mounted. A dirty and degraded RAID 5 or 6 can present a corruption risk, which is why forced assembly must never be a routine recovery shortcut.
Document alert routing, spare acquisition, replacement identification, workload throttling and the point at which a restore is safer than continuing. Never promise a rebuild duration without measuring the delivered devices, array load and controller.
05
Record the choice and its limits
The completed design should name the layout, equal-drive assumptions, usable-capacity estimate, tolerated failures, monitoring source and restore location. Keep versioned data in another failure domain and test a restore. The expected result is not a claim that RAID prevents loss; it is an array whose failure behaviour and recovery responsibility are understood before production data arrives.
Direct answers
Questions about this guide
Is RAID 6 always the best choice for a large HDD server?
No. It offers two-parity tolerance, but workload I/O, vdev or array width, controller or filesystem guidance, rebuild operations and the recovery objective still determine the layout.
Can a hot spare replace an external backup?
No. A spare can shorten the time before reconstruction begins, but it remains in the same server and does not protect against deletion, compromise, corruption propagated through the stack or site loss.