Backup that actually works: the 3-2-1 rule and what businesses get wrong

A backup that has never been restored is a hypothesis. That single sentence covers most of what goes wrong with backup in the businesses we audit, and it is worth checking before reading anything else here: when did you last restore something, and who did it?

The 3-2-1 rule, and why it still holds

Three copies of your data. On two different types of media or platform. With one copy off-site. It predates cloud and survives it, because the failure modes it protects against have not changed: hardware failure, site loss, and something that corrupts or encrypts the primary copy.

The modern version usually looks like production data, a local backup for fast restore, and a cloud copy for site loss. Increasingly there is a fourth consideration: at least one copy that cannot be altered or deleted by an attacker who has your administrator credentials.

Immutability matters more than it used to

Ransomware operators look for backups and delete them before encrypting anything, because that is what forces payment. A backup an administrator can delete is a backup an attacker with administrator access can delete. Immutable or write-once storage, or a copy in an account with separate credentials, is what breaks that.

Cloud data still needs backing up

This is the most common misunderstanding we encounter. Microsoft 365 and Google Workspace protect their own infrastructure. They do not protect your data from a user deleting a mailbox, from ransomware syncing through OneDrive, or from a departing employee clearing a SharePoint site. Retention policies and recycle bins help within limited windows and are not a backup.

Third-party backup of cloud data is a separate purchase and a necessary one. Treat it as part of the subscription cost rather than an optional extra.

Recovery time and recovery point

Two numbers decide what backup design you need. How long can you be down, and how much data can you afford to lose. Answer those per system rather than globally, because they differ enormously: an hour of lost email is an inconvenience, an hour of lost transactions may not be.

Most businesses have never been asked these questions and, when asked, discover that the current design does not meet the answer. That gap is the useful output of the exercise.

Testing a restore properly

A restore test is not checking that the backup job reported success. It is taking a real file, a real mailbox, or ideally a real server, and bringing it back somewhere isolated, then confirming the data is actually usable.

Do it at least quarterly for critical systems. Record who did it, what was restored and how long it took, because that record is what an auditor, an insurer and your own board will ask for. It is also how you discover that a restore takes eleven hours when you had assumed two.

What we find most often

Backups covering the file server but not the database. Cloud data with no backup at all. Backup credentials that are the same domain administrator account used for everything else. A job that has been failing silently for months because the alert went to somebody who left. And, most often, a backup nobody has ever restored from.

A short checklist

Everything critical is covered, including cloud. One copy is immutable or separately credentialled. Recovery time and recovery point are defined per system and the design meets them. Restores are tested quarterly and recorded. Failure alerts go to somebody who currently works here. That is most of it.