Every dedicated server provider offers RAID. Most advertise it as a feature, sometimes as a selling point, occasionally as a substitute for backups. It's none of those things. RAID is a performance and availability technology that keeps a server running when a drive fails. It doesn't protect your data from the most common causes of data loss, and the moment you rely on it as a backup strategy, you have already lost.
What RAID actually does
RAID, redundant array of independent disks, distributes data across multiple drives according to a scheme that can survive the failure of one or more of them. RAID 1 mirrors data across two drives, so if one dies the other has an identical copy. RAID 5 stripes data across three or more drives with parity, so any single drive can fail and the array rebuilds the missing data from the parity on the surviving drives. RAID 6 does the same with double parity, surviving two simultaneous failures. RAID 10 combines mirroring and striping.
The common thread: RAID protects against drive failure. It doesn't protect against file corruption, accidental deletion, software bugs that overwrite good data, ransomware, malicious deletion, or operator error. When a user deletes a file on a RAID array, the deletion is mirrored or parity-striped across all drives instantly. The file is gone from every drive in the array. RAID reproduced the deletion perfectly, because that's what RAID does: it reproduces writes across drives.
This is the fundamental misunderstanding. RAID keeps the server online when hardware fails. Backups let you recover data when something else goes wrong. They're different technologies solving different problems, and you need both.
What happens during a rebuild
When a drive fails in a RAID 5 array, the array runs in degraded mode. It's still operational, but every read requires the controller to reconstruct the missing data from parity, and every write requires recalculating and writing parity. Performance drops, often dramatically. The array is now one failure away from data loss, because a second drive failing means the parity can no longer reconstruct the missing data.
The rebuild process reads every block on every surviving drive to reconstruct the missing drive's contents. For a 4TB drive in a 4-drive RAID 5 array, the rebuild reads 12TB of data from the three surviving drives and writes 4TB to the replacement. At typical rebuild rates of 50 to 150 MB per second, that takes 8 to 24 hours. During that entire window, the array is under stress and vulnerable.
Rebuild failures happen for three reasons. First, unreadable sectors on surviving drives. Drives of the same age, from the same batch, running in the same environment, tend to fail at similar times. A drive that has been running for 4 years alongside the one that just failed is statistically likely to have developed bad sectors of its own. During normal operation, the RAID controller rarely reads every sector on every drive. During a rebuild, it reads every sector. If it hits an unreadable sector on a surviving drive, the rebuild stalls or fails, because the parity can't reconstruct the missing block. This is why RAID 5 arrays that survive the first drive failure sometimes fail during rebuild: the second drive was already failing, but nobody knew until the rebuild forced a full read.
Second, controller failures. The RAID controller is a single point of failure in hardware RAID. If the controller dies, the array metadata may be lost, and the drives become unreadable without a compatible replacement controller. This is less common with modern controllers, but it still happens, and when it does, recovery requires finding an identical controller, which may be years out of production.
Third, operator error during replacement. Pulling the wrong drive, inserting a drive that's smaller than the failed one by even one sector, or accidentally marking the wrong drive as failed in the controller utility are all errors that have destroyed production arrays. The stress of a failed drive at 3am doesn't improve judgment.
Why RAID 5 is dangerous in 2026
The rebuild failure problem gets worse as drive sizes increase. A 4TB drive rebuild reads 12TB from surviving drives. An 8TB drive rebuild reads 24TB. A 16TB drive rebuild reads 48TB. The probability of hitting an unreadable sector during a rebuild is proportional to the amount of data read. At modern drive sizes, the probability of a RAID 5 rebuild failure is high enough that RAID 5 is no longer a safe choice for primary storage.
Drive manufacturers publish unrecoverable read error rates, typically 1 in 10 to the 14 bits for consumer SATA drives. That means one unreadable sector per approximately 12TB read. A 4-drive RAID 5 array with 4TB drives reads 12TB during a rebuild, which means you have a roughly 50 percent chance of hitting an unrecoverable read error. With 8TB drives, the rebuild reads 24TB, and the probability approaches certainty. Enterprise drives with 1 in 10 to the 15 error rates are better but not immune, and the rebuild window still leaves the array vulnerable to a second failure.
RAID 6, with double parity, survives two failures and is the minimum sensible configuration for arrays with drives larger than 4TB. RAID 10, which mirrors rather than parity-protects, rebuilds faster because it copies a single surviving drive rather than reconstructing from parity across all survivors. For production dedicated servers in 2026, RAID 10 or RAID 6 should be the floor, and RAID 5 should be treated as a liability.
What actually protects data
The technologies that protect data from causes beyond drive failure are snapshots and backups, and they're different things.
Snapshots are point-in-time copies taken by the filesystem or volume manager. ZFS, Btrfs, and LVM all support snapshots. A snapshot captures the filesystem state at a moment, typically in seconds, and subsequent writes go to new blocks while the snapshot preserves the old ones. Snapshots let you recover a file deleted 4 hours ago by rolling back to the snapshot before the deletion. They're fast, local, and cheap. They don't protect against storage failure, because the snapshot lives on the same pool as the live data. If the pool dies, the snapshots die with it.
Backups are copies stored on different hardware, ideally in a different location. A real backup is air-gapped or at least on a separate system that isn't reachable from the production server. If ransomware encrypts the production server, the backup on a separate system is the only recovery path. If the datacentre burns, the backup in a different datacentre is the only recovery path.
The practical stack for a production dedicated server is: RAID 10 or RAID 6 for availability, ZFS or Btrfs snapshots for quick local recovery of accidental deletions, and off-site backups for disaster recovery. Each layer covers a different failure mode. Removing any layer leaves a gap that will eventually be exploited by reality.
A note on RAID and SSDs
NVMe SSDs have changed the RAID calculus. SSDs don't have moving parts, so the mechanical failure modes that dominate hard drive reliability don't apply. But SSDs have their own failure characteristics: write endurance limits, firmware bugs that can brick drives, and controller failures that can make a drive disappear from the bus instantly. SSD RAID arrays still need the same redundancy as HDD arrays, and the rebuild window, while faster, still exists. The assumption that SSDs are more reliable and so need less redundancy is wrong. They fail differently, not less often, and a RAID array of SSDs needs the same backup discipline as one of spinning disks.