Backups are an important part of a network setup, but the storage holding those backups can also suffer a drive failure. RAID groups drives to provide performance, redundancy or a combination of both. It can make storage more resilient, depending on the layout, but it does not replace a separate backup or guarantee that a server will remain available.
The choice between hardware and software RAID concerns who manages the array. A dedicated controller can manage it below the operating system, while software can manage the disks through the host. Our view is that hardware RAID remains worth considering in supported server installations, and software RAID can be an appealing, economical option for personal and small-business systems. The right decision depends on the storage software, workload and recovery plan.
RAID Levels Come Before the Implementation
A RAID level describes how data and redundancy are arranged. It is separate from whether a controller or host software performs the work. RAID 0 is a useful example: it stripes data, but provides no disk-failure redundancy. Calling an array RAID therefore does not establish that it can survive a failed drive. See our full RAID article for the broader explanation.
The table below assumes equal-capacity drives and conventional layouts. Let N be the number of member drives and C the usable capacity of one member before filesystem overhead. Actual formatted space is lower, and a smaller member can limit the space used on larger drives.
| Layout | Approximate capacity | Disk-failure tolerance |
|---|---|---|
| RAID 0 | N × C | None |
| Two-drive RAID 1 | C | One member |
| RAID 5 | (N − 1) × C | One member |
| RAID 6 | (N − 2) × C | Two members |
| RAID 10 with two-way mirrors | (N ÷ 2) × C | Depends on which mirror members fail; losing both members of a mirror can make the array unavailable and cause data loss |
Capacity formulas are not speed formulas. Sequential reads, small random writes, synchronous database writes and rebuild activity stress an array differently. Cache policy and controller or host resources also affect the result. Avoid sizing a system by multiplying a single drive's benchmark by the number of drives and assuming that figure will apply to every task.
How Hardware RAID Works
A hardware RAID controller presents virtual disks to the operating system and manages the underlying member drives. A dedicated processor may perform parity work, and some models include cache protected by a battery or a flash-backed power-loss mechanism. The host still needs a compatible driver and suitable management tools. A motherboard's advertised RAID option should not automatically be assumed to have a dedicated processor and protected cache.
This arrangement can suit a server whose supported configuration, monitoring and replacement procedures are built around the controller. It also adds a component to the recovery plan. Check drive compatibility, supported RAID levels, firmware, boot support and availability of a compatible replacement controller. Some controllers expose individual drives in an HBA or passthrough mode as well; that is a different arrangement from using their RAID facility.
How Software RAID Works
With software RAID, the host manages the array using its CPU and memory. In Linux, the MD subsystem performs the block-device RAID work, while mdadm is a user-space management tool. A filesystem such as ext4 or XFS can sit above the resulting block device. The filesystem and RAID layer have separate responsibilities.
OpenZFS combines storage management and a filesystem, with mirrors or RAIDZ as possible redundant layouts. It should not be treated as simply another name for MD RAID. Its checksumming, snapshots and recovery behavior are part of a different design. Other software storage systems also have their own supported configurations, so choose documentation for the exact implementation rather than assuming all software RAID behaves alike.
Software RAID can avoid buying a dedicated RAID card if enough suitable drive connections already exist. More drives may still require an HBA, cables, bays or a different chassis. Host CPU use is a trade-off to measure, not proof that software RAID is always slower or that its overhead is always negligible.
Power Loss and Cache Protection
Write-back caching can acknowledge a write before it reaches the member drives. That can improve some workloads, but the acknowledged data needs a safe path to persistent storage if power disappears. Dell's controller documentation specifically warns about forced write-back without a battery. Check the cache protection's condition and the documented fallback policy rather than enabling a faster setting solely because it is available.
The RAID write hole concerns inconsistent data and parity after an interrupted multi-disk update. Protection depends on the implementation. Linux MD supports a journal for RAID 4/5/6 and a Partial Parity Log option for RAID 5; these are not automatically enabled just because the array is software RAID. The Linux documentation also distinguishes journal write-through from write-back, including the data-loss risk if a write-back journal device fails.
OpenZFS documents that RAIDZ avoids the classic RAID 5/6 write hole. This does not promise immunity to every outage or storage failure. Correct persistence behavior still matters, and applications need an appropriate durability policy. A UPS can help a system shut down cleanly, but it is another part of the plan rather than a substitute for backups and sound cache configuration.
Integrity Checks and Maintenance
Parity consistency and file integrity are different checks. A conventional RAID consistency check can find a disagreement between stored data and redundancy, but without additional integrity information it may not establish which content is the correct original. Do not equate a clean parity check with proof that every file is intact.
OpenZFS checksums data and metadata with checksumming enabled. Its default data checksum currently uses Fletcher4, so describing every checksum as cryptographic is inaccurate. If a block is damaged and a valid redundant copy is available, ZFS can repair it. Without usable redundancy, detection cannot manufacture a good copy. A scrub examines stored data proactively, including blocks normal day-to-day reads may not touch.
For either approach, enable actionable monitoring and review its results. Record which serial number belongs to each bay, verify replacement-drive procedures and investigate failed or degraded states promptly. Rebuilds and ZFS resilvers restore redundancy and consume resources; performance and risk during that period deserve consideration when planning the array.
Controller Replacement and Portability
Hardware RAID recovery can require a compatible controller and the correct import procedure. Dell documents supported virtual-disk migration and foreign-configuration recovery, with compatibility restrictions between controller generations. Keep configuration information and any required encryption keys outside the failed system. An identical replacement is not universally required, but an arbitrary unrelated controller is not a safe assumption either.
Software-managed arrays can be less tied to one RAID controller, but portability still has conditions. The replacement environment must understand the metadata, filesystem and enabled features. OpenZFS documents that active unsupported pool features can prevent import. Disk availability and encryption keys also matter. Moving the drives to any computer is therefore not a guaranteed recovery within seconds.
In a failure, preserve the existing array metadata and establish the state before making changes. Creating a new array, initializing disks, clearing configuration or forcing an import can be destructive in the wrong situation. Follow the exact system's recovery documentation or get qualified help if the state is unclear.
Controllers for TrueNAS and ZFS
TrueNAS recommends letting ZFS see the drives through suitable direct connections or an HBA arrangement. Its hardware guide warns that hardware RAID can mask serial numbers and health information and introduce cache-related risks. Prefer a documented supported passthrough configuration over placing a ZFS pool above a controller-managed array.
IT-mode firmware is an option on particular compatible controllers, not a universal conversion recipe for every used RAID card. Confirm the exact board and supported firmware before buying or changing it. This is especially relevant to a homelab purchase: a low card price is less useful if the required mode, cables, cooling or driver support are unsuitable.
Backups and the Final Choice
Redundancy does not recover an accidentally deleted file, undo ransomware encryption or protect against losing the whole site. The 3-2-1 backup guideline calls for three copies, two media types and one offsite copy. Include version retention, appropriate separation and actual restore checks. Snapshots on the same storage are useful for some recovery tasks, but do not provide an independent copy if that storage is lost.
Our recommendation remains to match the design to the system and budget. Hardware RAID can make sense where its support and operational procedures are valuable. Software RAID can be cost-effective and flexible, and ZFS is a strong option where its integrity features and disk-management model fit. Compare recovery effort and ongoing maintenance alongside normal-operation performance before choosing.
