Lesson 3: RAID Is Not Backup

RAID can keep a storage system operating after some drive failures.

That is useful.

It is also why people make the mistake of calling RAID a backup.

It is not.

RAID and backup solve different failure problems.

RAID changes how data is laid out across drives

RAID combines multiple physical drives into an array using a defined data layout.

Depending on the RAID level, the design may emphasize performance, fault tolerance, usable capacity, or a combination.

The tradeoff is never free.

More redundancy usually means more raw capacity is consumed to protect the array from some drive failures.

State comparison

Redundancy changes failure tolerance—not backup

Compare array state before choosing rebuild, replacement, restore, or escalation.

1. 01
   Healthy

   All expected members participate and the array is consistent.

   Evidence: Normal member and controller status
2. 02
   Degraded

   The array still serves data but has lost intended redundancy.

   Evidence: Failed or missing member; elevated risk
3. 03
   Failed

   The redundancy limit was exceeded or required metadata is unusable.

   Evidence: Unavailable volume or controller failure state
4. 04
   Unknown

   Evidence is incomplete; do not initialize, rebuild, or reorder disks blindly.

   Evidence: Capture member order, controller state, and backups

RAID 0: striping without fault tolerance

RAID 0 spreads data across multiple drives.

A simplified model:

block 1 → drive A
block 2 → drive B
block 3 → drive A
block 4 → drive B

This can improve performance because multiple drives participate in the workload.

But there is no redundancy.

If one member fails, parts of the striped data are gone and the array is typically unusable.

RAID 0 solves a performance and capacity-combination problem.

It does not solve a drive-failure problem.

RAID 1: mirroring

RAID 1 stores copies of the same data on multiple drives, commonly as a two-drive mirror.

data → drive A
     → drive B

If one drive in a two-drive mirror fails, the other can often keep the data available.

That gives fault tolerance against that specific member failure.

What happens if a user deletes a file?

The deletion is mirrored too.

That is the backup problem in one sentence.

RAID 5: striping plus single parity

RAID 5 requires at least three drives.

Data and parity information are distributed across the array so the system can typically tolerate one drive failure.

The array can continue in a degraded state after a member fails, depending on the controller and system.

Degraded does not mean healthy.

The array has lost its normal fault-tolerance margin until the failed member is replaced and the array is successfully rebuilt.

RAID 6: more parity, more fault tolerance

RAID 6 uses double parity and requires at least four drives.

It can typically tolerate two member-drive failures.

That added protection costs more usable capacity and introduces additional write and rebuild considerations.

Again, design is tradeoff.

RAID 10: mirrors plus striping

RAID 10 combines mirroring and striping, typically using at least four drives.

It can provide strong performance with redundancy, but fault tolerance depends on which drives fail.

If both members of the same mirrored pair fail, the array can be lost even though another pair remains healthy.

So the phrase "RAID 10 survives two drive failures" is incomplete without context.

Compare the basic levels

Do not memorize the table as trivia.

Ask what the array is doing with each piece of data and what information remains when one member disappears.

A degraded array is already an incident

Consider a four-drive RAID 5 array.

Controller state:

array: online, degraded
member 3: failed
members 1,2,4: online
audible alert: active

Files still open.

Is everything fine?

No.

The array is operating with reduced fault tolerance. Another drive failure before a successful rebuild could cause data loss.

The correct response is not panic, and it is not ignoring the alert.

A controlled response includes:

1. preserve and verify backup or recovery state;
2. identify the failed member from controller evidence;
3. verify replacement procedure and drive requirements;
4. replace and rebuild according to the approved procedure;
5. monitor the rebuild;
6. verify the array returns to a healthy state;
7. verify required data and services after recovery.

RAID status evidence matters

Possible RAID failure evidence includes:

• status LEDs;
• degraded or failed-array state;
• missing member;
• missing array;
• audible controller or enclosure alarm;
• reduced performance during failure or rebuild;
• controller logs.

An alarm is not the diagnosis.

It is a reason to inspect the controller state.

Why RAID is not backup

Imagine a mirrored RAID 1 array.

A user accidentally deletes the entire project folder.

What happens?

The deletion is written to both members.

Now imagine ransomware encrypts the mounted filesystem.

The array can mirror the encrypted data perfectly.

Now imagine the system is stolen or destroyed by fire.

Both drives may disappear together.

RAID can protect against certain hardware member failures.

Backup protects against a different set of failures by preserving additional recoverable copies.

Those are separate jobs.

3-2-1 is a recovery mindset

A commonly taught backup principle is 3-2-1:

• 3 copies of important data;
• 2 different media or storage systems;
• 1 copy off-site or otherwise isolated from the primary failure domain.

Treat this as a model, not magic.

A backup is useful only if it contains the required data, survives the same failure, is accessible to the right people, and can actually be restored.

A backup job reporting "success" is not the same as a proven restore.

Worked example: small file server

Requirements:

shared files used daily
server should stay online after one drive failure
moderate budget
important data must be recoverable after deletion or ransomware

Would RAID 1 or RAID 5 help availability?

Potentially, depending on capacity and drive count.

Would RAID alone meet the recovery requirement?

No.

The design needs a separate backup strategy.

The requirements contain two different problems:

• tolerate hardware failure;
• recover a previous data state.

One technology should not be forced to solve both.

Worked example: gaming PC

Requirements:

one desktop
fast game loading
no critical unique data on game drive
cloud saves and installers available
limited budget

Does RAID automatically make sense?

No.

The added complexity may not solve an important requirement.

A single fast SSD plus appropriate backup for any unique files may be the cleaner design.

More technology is not automatically better architecture.

Make a RAID decision from a requirement

Choose one supplied scenario and decide whether RAID is justified.

Your explanation should include:

• the failure or performance problem you are solving;
• selected RAID level or reason for no RAID;
• minimum drive count;
• usable-capacity tradeoff;
• what member failures the design can tolerate;
• what the array looks like when degraded;
• what separate backup or recovery mechanism is still required.

If your explanation says "RAID backs up the files," fix it.

Before you move on

Keep these two questions separate:

Can the storage system remain available after a drive fails?

and

Can I recover an earlier good copy of the data after deletion, corruption, encryption, theft, or disaster?

RAID may help with the first.

Backup exists for the second.

Next, we use all of this to choose storage for an actual workload instead of chasing the largest number on a product page.