Storage

Hard drives fail. That is a statistical certainty, not a rare accident, and storage design starts from that assumption. In a classic server, several drives are combined into a RAID array so that the failure of one or two does not lose data. Larger platforms spread data across many machines, copying or encoding it so that any one machine can disappear without anyone noticing.

NVMe solid-state drives have changed what is possible. They are far faster than older SATA SSDs, particularly at handling many small random reads and writes at once, which is exactly the pattern of a database-heavy website. If a host advertises NVMe, the benefits are real, though CPU and memory limits will still cap the result.

Remember that redundancy is not backup. RAID protects against a drive dying; it does nothing for a deleted file, a corrupted database, ransomware or an administrator typing the wrong command. Those need separate, versioned copies.

Why drives fail, and when

A spinning disk is a stack of platters, a motor and moving heads hovering a hair above the surface. Bearings wear, heads crash, and firmware has bugs. An SSD has no moving parts but its flash cells wear with every write, and controllers fail without warning. Across a big fleet, a small percentage of drives die each year; in a rack of twenty-four, that means a replacement every so often rather than never.

Failures also cluster. Drives bought in one batch and run at the same temperature tend to age together, which is why the second failure during a rebuild is not as unlikely as the arithmetic suggests. A good design assumes that a failure will happen on a Friday afternoon.

RAID levels in plain terms

RAID combines several drives into one logical volume. The level decides the trade-off between capacity, speed and how many failures you survive.

RAID 10 is the usual choice for hosting because writes stay fast and a rebuild only copies one mirror partner. RAID 5 on very large disks is falling out of favour, since the long rebuild leaves a window in which a second failure destroys the array.

Spreading data across machines

Once a platform outgrows one server, drive-level protection is not enough, because the server itself can die. Distributed storage systems break data into chunks and keep several copies on different machines, or use erasure coding, which stores data plus calculated pieces so that any subset of enough pieces rebuilds the original. Copies are the simpler idea and cost three times the space; erasure coding is more economical but heavier on CPU and network when something breaks.

For a customer, this is what makes a VPS or cloud volume feel like it survives hardware failure. The price is added latency, since a write may not be acknowledged until several machines have it.

NVMe, SATA and the spinning disk

The interface matters. SATA was designed for hard drives and passes commands down a single queue. NVMe talks to the drive over PCIe and supports many queues in parallel, so a busy database with hundreds of concurrent small requests gets served far more efficiently. Spinning disks remain the cheapest per terabyte, which is why they still hold backups and archives.

A caveat: a fast disk does not rescue a slow site. If PHP workers are starved of CPU or the database lacks an index, NVMe merely lets the bottleneck arrive sooner.

Redundancy versus backup

This is the point most often misunderstood. A mirrored drive faithfully mirrors your mistakes: delete a folder and both copies lose it within milliseconds.

Good backups are versioned (several restore points), stored somewhere an attacker on the server cannot reach, and tested by restoring them. A backup you have never restored is a theory.