The 3-2-1 backup rule, and why almost nobody follows it

When we audit a company's infrastructure, we always ask the same question: "When did you last restore a backup?"

The most common answer is silence. Then: "We have automatic backups, they run every night." That is not the same thing.

A backup you have never restored is not a backup

It is a hypothesis. Until you have brought your data back onto a clean system and verified that it is complete and usable, you do not know whether your setup works. You only know that a script runs without returning an error.

The failure modes we encounter most often are all silent:

• the backup runs, but excludes a directory added six months ago;
• the database is copied mid-write, producing a corrupted file;
• the destination has been full for weeks, and the job fails without alerting anyone;
• the archives are encrypted, and the key sits on the server that just died.

The 3-2-1 rule

It is the simplest formulation of a serious strategy, and it fits in one line: three copies of your data, on two different media, one of them off site.

Three copies. The original plus two backups. Not the original plus one: the day you discover the backup is corrupted, you have nothing left.

Two different media. If both copies live on the same server, or on two disks in the same enclosure, one electrical incident or one theft takes them together.

One copy off site. This is the protection against fire, water damage and burglary — and against ransomware, which systematically encrypts every network share reachable from the infected machine.

The nuance that matters: offline

The 3-2-1 rule was formulated before ransomware became widespread. Today, an off-site copy remains vulnerable if it is writable from the system being backed up.

A genuinely protected backup is either physically disconnected, or stored with an immutability lock that forbids any modification for a defined period — including by an administrator whose credentials have been stolen.

The test we ask for

Once a quarter, without warning the technical team, we request a full restore onto a fresh environment. The clock runs. The exercise answers three questions nobody can guess on paper:

• How long? If the restore takes eleven hours and your business tolerates two, your setup does not fit, even if it works perfectly.
• How much data lost? Between the last successful backup and the incident there is always a gap. Its size should be a decision, not a discovery.
• Who knows how? If a single person masters the procedure and cannot be reached, your backup only protects you during their office hours.

Where to start

If you only do one thing this week: take last night's backup, restore it onto a test machine, and open the data. Not the archive file — the actual data, inside the application.

In half the cases we handle, this simple exercise reveals a problem nobody suspected. Better to find it on a calm Tuesday morning than on the day everything is already gone.