“Do you have backups” is the wrong question, because the answer is almost always yes. The question that separates organisations is when somebody last restored one, how long it took, and how much work was lost in the gap between the last usable copy and the incident.
The 3-2-1 rule remains the most compact answer to that problem. It is worth knowing that it is not a standard and never was. Peter Krogh formulated it for digital photography archives, and it survived into infrastructure practice because it describes how data is actually lost rather than how storage vendors prefer to discuss it.
What the rule asks for
Three copies of the data, on two different storage media, with one copy off site.
The value is not in the numbers themselves but in the fact that each one defends against a different class of failure, and those classes do not overlap.
Three copies means production plus two backups rather than one. The second backup exists for the case where the failure is discovered during a restore from the first. A restore that fails from your only copy leaves you with nothing, and you find this out at the worst possible moment.
Two media types defends against correlated failure. Two drives from the same batch, bought on the same day and run at the same temperature, fail far closer together than independent probability suggests. The same logic applies above the hardware layer: two copies in one filesystem, one storage pool or one cloud account share a failure mechanism no matter how separate they look on a diagram.
One copy off site defends against everything that takes out a building. This is the part most organisations already do, usually by synchronising to object storage, and it is the part that gets cited when someone asks whether backups are handled.
Three assumptions that stopped holding
The rule was written when the dominant risks were hardware failure and human error. Both still happen. Neither is what causes the expensive incidents now.
It assumes the attacker is not looking for your backups. Modern ransomware operators spend days or weeks inside a network before encrypting anything, and during that time they specifically hunt the backup infrastructure: the management console, the shares that receive the copies, the service account with delete permissions. Encryption is triggered after the copies are gone, because otherwise there is no reason to pay. An architecture that satisfies 3-2-1 on paper can fail completely here. Three copies reachable with the same administrative credentials are, from the attacker’s position, one copy.
It assumes your data sits on infrastructure you control. Microsoft 365 and Google Workspace are not backed up on your behalf in any sense that matters. The provider guarantees the availability of its own platform. It does not guarantee recovery of content deleted by a user, or by an attacker holding that user’s session, beyond short recycle bin windows. The same applies to most SaaS: the shared responsibility model puts the platform on the vendor and the data on you, and organisations routinely discover which side of that line they are on during an incident.
It assumes corruption is loud. Data degrades quietly, and a logically corrupted database backs up perfectly well. If retention is short enough, the last healthy version can be overwritten before anyone notices the problem. You then hold a complete, verified, restorable set of unusable data.
Immutability is the control that survives compromise
The current formulation adds two digits, giving 3-2-1-1-0. The two additions carry most of the value in a modern threat model.
One immutable or air-gapped copy. Immutability is enforced through object lock or WORM mechanisms, where a written copy cannot be altered or deleted until its declared retention expires, including by an account with full privileges. This matters more than any other single control, because it is the only one that holds when the attacker has valid administrator credentials. Access policy can be changed by whoever compromised the account that manages it. A retention lock enforced by the storage platform cannot.
Worth checking when you configure it: whether the lock is in compliance mode or governance mode. Governance mode can be overridden by a sufficiently privileged account, which returns you to the problem you were trying to solve.
Zero errors on verification. A copy whose restorability is unknown has a known cost and an unknown value.
The number nobody measures
Most organisations can state their backup frequency. Far fewer can state their restore time, and the two are unrelated.
Restore time is dominated by factors that never appear in the backup schedule: the throughput of the link between the storage and the target, whether the data must be rehydrated from a cold storage tier first, how long the database takes to replay its logs, and how much of the procedure exists only in one engineer’s memory. An hourly backup with a twelve-hour restore gives you an excellent recovery point and a business outage that lasts a day and a half.
Cold storage tiers deserve specific attention here. They are attractive on price and they are frequently chosen for the off-site copy, but retrieval can take hours and is often billed per gigabyte on the way out. Both facts are discovered during the first real incident unless someone checks beforehand.
The only way to know these numbers is to run a full restore into an isolated environment and time it. That exercise measures three things nobody knows in advance: real restore duration, real data loss, and the undocumented steps. It rarely finishes without finding something.
What regulators actually require
For organisations in scope of NIS2, business continuity including backup management and disaster recovery is named explicitly among the risk management measures. The directive does not prescribe technology. It requires the measure to exist and to be demonstrable.
GDPR carries a related obligation framed around personal data: the ability to restore availability and access in a timely manner following a physical or technical incident.
Both are written in terms of restoration capability rather than copy existence. That distinction is the whole point. Holding backups is a purchasing decision. Being able to restore is an operational one, and the evidence for it is a test result rather than an invoice.
A structure that works
For an organisation running its own servers alongside some SaaS, a defensible arrangement usually looks like this.
Local copies live on storage separate from production, with short retention and fast recovery, covering the ordinary cases: a deleted file, a failed update, a virtual machine that will not boot. Speed matters here and retention does not.
Off-site copies go to object storage with retention lock enabled. The account that writes them holds no delete permission, and its credentials are not the ones used to administer the rest of the estate. The retention period is chosen against how long a problem can plausibly go unnoticed in your environment, not against a vendor default.
SaaS data is backed up explicitly, by a tool chosen for that purpose, because nothing in the platform does it for you.
Retention is set per data class rather than uniformly. A production planning system and a document archive have different values, and treating them identically means paying too much for one or accepting undeclared risk on the other.
Monitoring covers backup outcomes rather than backup execution. A job that completes successfully after silently skipping half its volumes reports success.
Mistakes that recur
Confusing replication with backup is the most common and the most expensive. Replication copies current state, including corruption and encryption, almost instantly. It is an excellent availability mechanism and a useless recovery mechanism.
Running backups under a domain administrator account is convenient, works immediately, and turns the backup system into a target with full access to everything else.
Accepting the default retention period ties your recovery window to a vendor’s product decision rather than to how long problems go unnoticed in your organisation.
Having no inventory means systems nobody remembers are not being backed up, and every environment that grew over time contains some.
Where to start
Pick your most important system, restore it into an isolated environment, and time the whole thing with a stopwatch. The result will tell you more than any policy document.
We design and operate backup schemes as part of backup and disaster recovery, and the credential isolation that makes them survive an intrusion belongs to cybersecurity and compliance.