What RAID Is, How It Works, and Why It Is Not a Backup

If your array is degraded right now

If a disk shows as Failed or Degraded on your server or NAS, the first few decisions set the limits on everything that follows. A degraded array runs with no safety margin: any further mistake lands on live data that has no second copy inside the system.

Then it can be inspected. The right move at this moment is not a quick fix; it is holding the state as it is until the array structure can be read correctly.

• Stop the writes. Shut down services and access to the shared folders instead of leaving the system running.
• Do not start a rebuild, and do not accept an Initialize prompt or an offer to create a new array.
• Do not pull any disk before labelling it with the slot it came out of, and do not reorder the disks.
• Do not replace more than one disk, and do not re-insert a disk that already dropped out of the array.
• Photograph the error messages and the controller log, and note the RAID level, the disk count and their capacity.

What is RAID and how does it work?

RAID is a way of combining several physical disks into one storage unit that the system sees as a single disk. The goal is one of three things, or a mix of them: more speed, more capacity, or the ability to keep running when a disk fails.

Almost every level is built from three ideas. Striping splits the data across several disks so it can be read and written in parallel. Mirroring writes the same copy to two disks. Parity stores a value calculated from the other disks, which allows the contents of a missing disk to be reconstructed.

Each RAID level is a different mix of those three ideas, and every mix has a price: capacity spent, slower writes, or a narrower safety margin.

RAID 0, 1, 5, 6 and 10 in business terms

The practical difference between the common levels comes down to one question: how many disks can fail before the data stops existing.

The number is not a quality rating. It describes how much margin you bought. RAID 5 built on large, ageing disks is a narrower position than it looks, because its margin is exactly one disk.

• RAID 0: striping with no protection. Full capacity and higher performance, but one failed disk means the whole volume is gone.
• RAID 1: a mirror across two disks. You lose half the capacity, and work continues as long as one disk is healthy.
• RAID 5: striping with distributed parity. It survives one failed disk only, and spends the capacity of one disk.
• RAID 6: double parity. It survives two failed disks, spends the capacity of two, and writes more slowly.
• RAID 10: striped mirrors. It survives one disk per mirrored pair, spends half the capacity, and rebuilds with far less stress on the remaining disks.

RAID is redundancy, not a backup

This is the single most important idea here. RAID protects you from a disk failing. It protects you from nothing else.

An accidental deletion is written to every disk at the same moment. Ransomware encryption passes through the array like any ordinary write. File-system corruption, a bad update, fire, theft of the unit, even failure of the controller itself: all of these hit the array as a whole. In those cases the only copy that helps is the one living outside the server.

The working rule: RAID protects uptime, a backup protects data, and neither replaces the other. A backup belongs on separate media, ideally with a copy off site, and a restore should actually be tested from time to time.

What happens when a disk fails, and why a rebuild can destroy the data

When a disk drops out of an array that can tolerate the loss, the array enters a degraded state. The data is still reachable, but it is now being calculated from the remaining disks instead of read directly. Performance drops, and on RAID 5 the safety margin is now zero.

A rebuild is not a light operation. To reconstruct the missing disk, nearly every sector on every remaining disk has to be read, and the replacement disk written continuously for hours or days. Those disks are usually the same age and often the same batch. Under that load, an unreadable sector that had been sitting there unnoticed can surface, or a second disk can genuinely fail. The rebuild stops there, and the situation is worse than where it started.

There is a blunter risk as well: a rebuild writes. If the original fault was logical rather than physical, if the rebuild is started onto the wrong disk, or if a prompt to create a new array is accepted instead of importing the existing configuration, new data can be written over the very structure needed to read the array. Inspecting before writing is the difference between a case that can still be assessed and a case that has changed.

Why disk order matters

An array is not just a set of disks; it is a specific arrangement. Reading the data requires knowing the disk sequence, the stripe size, the starting offset on each disk, and the direction in which parity rotates. That information lives in small metadata areas on the disks and in the controller configuration.

If the disks are pulled and returned to different slots, if two arrays get mixed, or if the metadata is wiped by a re-initialisation, the arrangement becomes unknown and has to be inferred from the disk contents themselves. That is possible in many cases, but it is slower, harder and less certain than reading an order that was never lost.

So the rule is simple: before pulling any disk, label it with the slot it came out of. One paper label can save an entire stage of work later.