Backup Strategy: The 3-2-1 Rule and Why RAID Is Not Backup
Every guide on this site that discusses RAID says the same thing: RAID is availability, not backup. This is the guide that covers what backup actually means, because the distinction is where organisations lose data.
What RAID does not protect against
RAID protects against a drive failing. That is one failure mode out of many, and it is not the one that most often destroys data.
Deletion. A file deleted by mistake is deleted on every member instantly. Parity faithfully reconstructs the deletion.
Corruption. Application or filesystem corruption propagates across the array as written.
Ransomware. Encryption is a legitimate write operation as far as the array is concerned.
Controller failure. A controller that fails badly can leave an array unreadable even with every drive healthy.
Fire, flood, theft. Everything in the chassis goes together.
Correlated drive failure. Covered in our drive lifespan guide: drives bought together age together, and a rebuild is the hardest work an old drive does. Second failures during rebuild are not rare.
An array with no tested backup behind it is one mistake away from total loss, regardless of RAID level.
The 3-2-1 rule
The standard framing, and it holds up because each part addresses a different failure.
Three copies of the data — the production copy plus two backups. One backup means a single point of failure in the backup itself.
Two different media types or systems. If everything sits on the same kind of storage in the same way, a systemic problem takes all of it.
One copy off site. This is the part that covers fire, flood, theft and site-wide events, and it is the part most often skipped because it is the most inconvenient.
Many organisations now extend this with a copy that is offline or immutable — unreachable from the production network, or written so it cannot be modified for a defined period. That addition exists specifically because ransomware attacks backup systems deliberately, and a backup reachable with production credentials is a backup that can be encrypted along with everything else.
Recovery objectives decide the design
Two numbers turn backup from a vague obligation into a design.
Recovery point objective is how much data you can afford to lose, measured in time. If backups run nightly, an incident at 4pm loses the whole working day. If that is unacceptable, backups need to run more often.
Recovery time objective is how long you can afford to be down. This is where plans most often fail, because restoring a large volume takes real time — and time to restore is governed by the speed of the backup medium and the network between it and production.
Work these out per system rather than globally. A file share and a transactional database usually have very different tolerances, and treating them identically means overspending on one and underprotecting the other.
Where backup storage differs from production storage
Backup targets have a specific workload profile, and it changes the hardware answer.
Backup is large sequential writes, read rarely. There is essentially no random I/O. That means cost per terabyte governs completely and flash offers nothing the workload uses — a point our SSD versus HDD guide covers.
Nearline drives are the correct tier: 7200 RPM, built for 24/7 sustained duty, priced for terabytes. SATA is usually the right interface, since backup is single-path sequential work.
Two design points specific to backup arrays.
Use double parity. A backup array that fails during a restore is worse than useless. Our RAID guide covers why RAID 5 is inadvisable on large drives.
Size for retention, not for one copy. Retention policy multiplies capacity requirements, and deduplication and compression help but should not be relied on for a specific ratio when sizing.
Restore testing is the whole point
The single most common backup failure is not a missing backup. It is a backup that existed and did not restore.
Causes are mundane and consistent: the job had been failing silently for weeks; the backup covered the wrong volumes; the media was unreadable; the restore procedure required something not backed up, such as an encryption key or a configuration file; or nobody had done it before and the process took far longer than the recovery objective allowed.
All of those are found by testing and none are found by monitoring job status.
A reasonable routine: restore something real on a schedule, restore to a different machine than the source, time it and compare against your recovery objective, and periodically test a full system restore rather than only individual files.
On ageing hardware this matters more, because the probability of losing an array is materially higher than on current equipment.
What gets forgotten
Backup coverage tends to follow the obvious data and miss the things needed to actually rebuild.
Configuration — RAID controller settings, network configuration, firewall rules, switch configurations. Encryption keys and certificates, without which encrypted backups are unrecoverable. Management controller settings. Documentation of the restore procedure itself, which is unhelpful if it only exists on the system that is down.
A useful test: if the building were gone, could you rebuild from what is off site? That question usually finds the gaps quickly.
Common questions
Why is RAID not a backup?
RAID protects against a drive failing, which is one failure mode. Deletion, corruption, ransomware, controller failure, fire and theft all propagate across every member or take the whole chassis. Parity faithfully reconstructs a deletion.
What is the 3-2-1 rule?
Three copies of the data, on two different media types or systems, with one copy off site. Many organisations add a fourth condition — one copy offline or immutable — because ransomware attacks backup systems deliberately.
What storage should a backup target use?
Nearline drives on SATA. Backup is large sequential writes read rarely, so cost per terabyte governs and flash offers nothing the workload uses. Use double parity, since a backup array that fails during a restore is worse than useless.
Why do backups fail to restore?
Usually mundane reasons: the job had been failing silently, it covered the wrong volumes, the media was unreadable, the procedure needed an encryption key that was not backed up, or the restore took far longer than the recovery objective allowed. All are found by testing, none by monitoring job status.
What gets left out of backups?
The things needed to rebuild rather than the obvious data: RAID and network configuration, switch configurations, encryption keys and certificates, and the restore documentation itself. Ask whether you could rebuild from what is off site if the building were gone.
Tell us your retention requirement and recovery objectives and we will size a backup target properly rather than by raw capacity.
