The 3-2-1 backup rule: what it means and how to actually run it in a small business

The essentials in 30 seconds

The 3-2-1 backup rule is the shortest useful answer to the question of what a backup has to look like to survive contact with reality: three copies of your data, on two different types of storage, with one of them off-site. Build your backup that way and you cover the three events that actually destroy business data: a failed drive, a failed system, and a lost location through fire, water or burglary.

What the rule leaves out is the part that fails most often in practice, namely proof that anything can be recovered from those copies. Plenty of companies run a backup job that has completed successfully for years without anyone ever attempting a restore.

This article walks through what each number is really protecting you from, the assumptions that quietly hollow out a backup strategy, what the newer 3-2-1-1-0 variant adds, and what a workable setup looks like in a company without a dedicated IT department.

What the 3-2-1 backup rule actually says

The rule came out of professional photography. Peter Krogh described it in the mid-2000s in his book on digital asset management, after watching colleagues lose entire archives, mostly to a single failed hard drive rather than to any dramatic disaster. It has since found its way into government guidance and insurance questionnaires, helped along by the fact that you can explain it in one sentence.

The logic underneath is risk spreading. Each number covers a different class of failure.

Number	What it means	The risk it covers	How it breaks in practice
3 copies	The original plus two independent backups	A single drive failing, accidental deletion, one corrupted file	The second backup gets cut as “we probably don’t need that”
2 media	Two different storage technologies or systems, not the same thing twice	A systematic fault hitting an entire technology or product batch	Two identical drives from the same delivery
1 off-site	One copy in a different location, ideally not permanently connected	Fire, water damage, burglary, ransomware inside your own network	The “external” drive sits in the next room on the same switch

Three copies sounds generous until you count properly. The original is one of the three. That leaves two backups, and if one of them is mid-rebuild or a restore attempt from it fails, everything depends on the remaining one. The second backup exists precisely for the day the first one misbehaves.

Two media is the number most often misread. It does not mean two devices, it means two different failure modes. Two identical drives from the same production batch age the same way and tend to fail around the same time; a firmware defect hits both at once. Two virtual machines on the same hypervisor are one medium too, however much the management console makes them look like two systems.

One copy off-site was originally about fire and flood. That reasoning still holds, and it has picked up a second one. Ransomware travels through whatever network it lands in, and everything reachable from an infected machine becomes part of the target from that moment on. Off-site is therefore less a question of distance in kilometres than of reachability.

Four assumptions that quietly break good backups

Companies with no backup at all have become rare. The far more common situation is a backup that exists, runs reliably, and turns out to be useless on the day it is needed. Four patterns show up again and again.

1. The backup lives on the same network

The classic: a share on the NAS, permanently mounted, with write access for the service that writes the backup. Technically tidy, operationally convenient, worthless during a ransomware event. Attack tooling now specifically enumerates reachable shares, shadow copies and backup directories and destroys them first, because a victim without a way back is far more likely to pay. That sequence is documented step by step in our guide to a cyber attack on a company.

The rule of thumb is uncomfortable and clear: if an attacker holding administrator rights can delete your backup, then eventually one will. The protection lies in separation, not in hoping nobody tries.

2. Nobody has ever restored anything

An untested backup is an assumption with a timestamp on it. The reasons a restore fails when it matters are long and thoroughly unglamorous. The database was copied while it was running and is internally inconsistent. A directory dropped out of the backup job during a server migration and was never noticed. The archive is encrypted and the key lives in a password manager that ran on the server you are trying to restore. The backup is complete, and pulling it back over the available line will take eleven days.

None of those problems show up while backing up. All of them show up while restoring.

3. Sync is mistaken for backup

A cloud folder that keeps files in step across devices is a convenience tool. It replicates every change faithfully, including the ones you regret: deleted is deleted everywhere, encrypted is encrypted everywhere, within seconds. Most providers do keep previous versions, frequently for 30 days and not equally reliably for every file type. As your only line of defence, that is thin.

4. Only the latest state exists

If last night’s backup overwrites the one before it, you own exactly one restore point. That is fine for a file someone deleted this morning. It is not fine for the cases that get expensive: encryption that ran unnoticed for three weeks, a bad import that only surfaces at month-end close, a slowly corrupting file that has been unusable since spring. Versioning across several weeks is the difference between recovering the state from before the damage and having a very well-preserved copy of the damage.

Storage media compared: what is good for what

The rule deliberately prescribes no technology, and that is why it has aged well. Still, it helps to look soberly at what each medium can and cannot do. The following reflects typical small-business use as of 2026.

Medium	Cost	Can it be offline?	Ransomware resistance	Typical role
External hard drive	very low	yes, if unplugged after the job	high while disconnected, low while attached	Micro businesses, extra manual copy, rotation across several drives
On-premises NAS	low to moderate	no, permanently on the network	low to moderate, depending on credential separation and snapshots	Fast first-line restores, short recovery times
Cloud backup	recurring fee by volume	not technically, but separated	moderate to high, high with immutability and a separate account	The off-site copy, protection against losing the location
Tape (LTO)	high up-front, very low per terabyte	yes, the cartridge sits in a cabinet	very high, a cartridge on a shelf is unreachable	Large volumes, long retention, archival
Object storage with immutability	moderate	no, but write-protected	very high, the retention lock applies to administrators too	The modern alternative to tape when nobody wants to handle cartridges

For most companies running one or two servers, this points to an unspectacular combination: a fast local backup for everyday mistakes, plus an encrypted off-site copy at a provider, stored immutably. If you move large volumes or have to satisfy retention obligations spanning many years, tape is still the cheapest medium per terabyte by a wide margin.

3-2-1-1-0: the version ransomware made necessary

The classic rule was written when the main adversaries were hardware failure and human error. Both are still with us; what has been added is an adversary that actively looks for your backups. The extended version answers that:

• 3 copies
• 2 different media
• 1 copy off-site
• 1 copy offline or immutable
• 0 errors in the restore test

That extra 1 demands a copy nobody can reach, including someone with valid administrator credentials. There are two proven routes. The physical one: a tape in a cabinet, a drive in a safe, a disk that gets unplugged when the job finishes. The gap between that copy and the network is called an air gap, and it is as effective as it is unglamorous. The logical one: object storage with a retention lock, where a written object cannot be altered or deleted for a defined period, enforced by the provider regardless of what permissions an account holds.

The 0 is the genuinely new part, even though it demands the least technically. It redefines when a backup counts as done. The successful backup job no longer qualifies; a demonstrably clean restore does. That moves testing out of the wish list and into normal operations, which is where it belongs.

Building it: a setup that survives everyday operations

Between the rule and a running backup there are a handful of decisions that have to be made inside the company. This order works.

1. Decide what is genuinely business-critical. Not everything deserves the same care. The ERP system, the accounts, the customer database, production data and the mailboxes sit in a different class from the archive of old proposal drafts. An honest list, sorted by “how long can we work without this”, is the foundation for everything else. That list overlaps heavily with the system inventory you need anyway to handle an IT security vulnerability sensibly. Maintain one and you have most of the other.

2. Agree on two numbers. The jargon calls them RPO and RTO; the questions behind them are perfectly ordinary. How many hours of work can we afford to lose in the worst case? That sets your backup frequency. And how long may it take before people can work again? That sets how and where the backup has to be stored. A workshop that can absorb a day of lost paperwork but must be producing again within four hours needs a different setup from a law firm with the priorities reversed. Both numbers are management decisions, not IT decisions.

3. Build the tiers. Once those two numbers exist, most of the design follows. A common shape for a company with its own server: hourly or daily backups to a local system for quick recovery, a daily encrypted transfer to an off-site provider where copies are held immutably for 30 to 90 days, plus a monthly restore point kept longer. If the server runs at a provider, put this chain in the contract, spelling out what is backed up, how often, for how long, and who is responsible for testing. With our managed hosting that chain is part of running the platform rather than an add-on somebody has to remember.

4. Encrypt, and store the key elsewhere. Anything leaving the building should be encrypted. The key must not live exclusively on the systems it is supposed to rescue. A printed recovery key in a safe looks quaint and has saved a lot of recoveries.

5. Separate the credentials. The account that writes backups should not be allowed to delete them. Access to the off-site copy should use different credentials from your directory administration, protected with a second factor. That separation takes an afternoon to set up and decides whether one compromised admin account takes the backups with it.

6. Write down how recovery runs. One page is enough: where the copies are, who has access, in which order systems come back up, which phone numbers you will need. Print it and keep it near the rack, because your intranet is the first thing that stops being reachable.

How often to test, and what a test has to prove

A restore test answers three questions. Does the copy open? Is the data usable in substance? And how long did it take? The third one gets skipped most often and matters most in a real incident, because a recovery that runs for four days is a fundamentally different business event from one that takes four hours.

Type of test	Frequency	What it proves
Automated job monitoring	daily	Did the job complete, is the volume plausible, were errors reported?
Spot check	monthly	Recover one file, one mailbox or one table and inspect the contents
Full restore	quarterly	Rebuild a complete system on spare hardware or in a test environment, and time it
Recovery exercise	annually	Walk through the documented procedure, including who calls whom

The full restore is where most companies hesitate, because it costs real time. One morning per quarter is usually enough if you decide in advance which system is being tested. Document the outcome: date, system, duration, errors encountered, signature. That record is also the document your cyber insurer or auditor will ask for, and they will ask.

Retention and versioning: how long is long enough?

Two separate topics get mixed up here more often than not.

A backup exists to get you running again. It holds a manageable window of restore points so you can go back to a moment before the damage. The Grandfather-Father-Son (GFS) scheme still works well: daily restore points for two to four weeks, weekly for two to three months, monthly for a year. The longer tail exists because damage surfaces late. Intruders frequently sit in a network for weeks before acting, and quiet data corruption rarely announces itself.

An archive exists to prove things. Accounting records, invoices, annual statements and business correspondence fall under retention obligations that run six to ten years in many jurisdictions, with requirements around immutability and readability. A rotating backup cannot serve that purpose, since it overwrites old states by design. This job needs its own immutable store, in a format that will still open in seven years.

Treat both as one system and you end up doing both badly: a bloated backup with slow recovery times, and an archive that would not hold up to scrutiny.

What the rule does not do

For honesty’s sake, this belongs in here too. The 3-2-1 rule is a structure for copies and nothing more. It says nothing about whether the right data is being captured, and that gap is surprisingly common. The line-of-business application is backed up, its configuration files are not. The server is in the job, the cloud mailboxes are not, because “that’s all automatic anyway”. The virtual machine is captured as a whole while the database inside it keeps writing, producing a copy that will not start cleanly.

Nor does a backup replace the work of not needing one. Current software, minimal privileges, segmented networks and an outside look at your own attack surface prevent a large share of the incidents you would otherwise be restoring from. What is reachable from the internet, and whether one single weakness would be enough, is what a security audit answers with findings rather than guesswork.

The bottom line

Three copies, two media, one off-site. Those three numbers have stayed useful for twenty years because they take a messy problem apart cleanly. Add an immutable copy and a passed restore test and you have a strategy that holds up against the realistic threats of daily operations, from a dead disk to an attacker with an encryption key.

Implementation is rarely the hard part. The effort sits in deciding, in assigning ownership, and in repetition: someone has to say how much data loss is acceptable, someone has to put the test in the calendar, and someone has to actually run it, including in the quarter when everything else is on fire. Companies that come through an incident intact usually introduced that unremarkable routine years earlier, long before there was any sign they would need it.

If you take one thing from this article, take this: restore something before you have to. Everything else about the 3-2-1 backup rule is a matter of setup. Only the test turns an assumption into certainty.