The classic 3-2-1 rule (three copies, two kinds of storage, one off-site) was written for a world where the main threats were disk failure, theft and fire. Those still matter. But ransomware changed the picture: attackers now look for backups first and try to delete or encrypt them before they encrypt anything else.
The response, popularised by backup vendors over the last several years, is an extended version: 3-2-1-1-0.
The two new numbers
1 — one copy offline, air-gapped or immutable
At least one copy must be impossible for an attacker to change or delete, even if they have your passwords. There are three common ways to get there:
- Offline: a drive or tape that is physically disconnected. If it is not plugged in, it cannot be encrypted over the network.
- Air-gapped: a copy on a separate system with no standing network path from production. Often a logical gap rather than a physical one.
- Immutable: storage that refuses to modify or delete an object until a set retention date passes. In cloud object storage this is usually called object lock, and it is enforced by the storage service, not by your own software.
0 — zero errors after verification
The backup has been checked and restores without errors. Not “the job said success”, but the data has been read back, checksums match, and ideally a real restore has been tested. A backup with unknown errors is a guess.
The extra “1” protects the backup from the attacker. The “0” protects you from discovering, on the worst day, that the backup never worked.
How object lock works
Object lock is the most practical form of immutability for most teams, because it does not need anyone to rotate drives.
When you write a backup file to a bucket with object lock enabled, you attach a retention period, for example 30 days. Until that date:
- the object cannot be overwritten or deleted through the normal API
- in compliance mode, not even the account administrator can shorten the retention
- in governance mode, specially privileged users can override it, which is more flexible but less strict
Most serious backup tools (restic, Veeam, pgBackRest and others, depending on version and configuration) can either work with object lock directly or be paired with bucket-level retention rules.
Things to get right
- Choose the retention period carefully. Too short and an attacker can wait it out; too long and you pay to store data you cannot delete. Many teams start at 14 to 30 days for daily backups and longer for monthly ones.
- Understand compliance mode before you use it. It really cannot be undone. Test with a small bucket first.
- Separate credentials. The account that writes backups should not be the same account that administers the bucket. Use keys that can write but not delete.
- Watch costs. Locked data is billed until it expires, even if you no longer want it.
How verification works
“Zero errors” needs a routine. A simple one:
- After every backup: check the job’s exit status and alert on failure, not just log it.
- Weekly: run the backup tool’s built-in integrity check (for example,
restic checkor pgBackRest’s verify) against a sample of the data. - Monthly: restore a few files or a database to a scratch location and open them.
- Quarterly or twice a year: do a full restore test of a critical system, timed, as if it were a real incident.
Write down what you tested and when. It turns “I think it works” into evidence.
Putting the full rule together
Here is what 3-2-1-1-0 might look like for a small business with a file server and a Postgres database:
| Copy | Where | Purpose |
|---|---|---|
| 1 | Production server | Live data |
| 2 | Local NAS, nightly | Fast restores for everyday mistakes |
| 3 | Cloud object storage in another region | Off-site copy |
| +1 | Same cloud bucket with object lock, 30-day retention | Cannot be deleted by a compromised account |
| 0 | Monthly test restore, logged | Proof it works |
Note that the immutable copy and the off-site copy can be the same copy, as long as the lock is enforced by the storage provider.
For households
Most families do not need compliance-mode object lock, but the ideas still apply:
- Keep one copy that a stolen phone or a compromised email account cannot reach. A service with long version history in a separate account, or a drive that stays unplugged in a cupboard, will do.
- Every few months, try to restore a photo album or a folder of documents. If it is painful, fix it while nothing is on fire.
Common mistakes
- Using the same admin login everywhere. If one password can delete the production data, the backups and the lock settings, you have one point of failure.
- Immutability without monitoring. A locked bucket that stopped receiving new backups three months ago is not much help.
- Testing only small restores. Restoring one file proves the files are there; it does not prove you can rebuild a server in a reasonable time.
Closing note
triplicate’s business plans are being built with object lock for immutable backups, and an S3-compatible endpoint that works with tools like restic, Veeam and pgBackRest. We are not live yet. See the integrations and security pages, or talk to us if you have specific retention requirements.
Keep reading
Ransomware recovery for small businesses
What to do in the first hours after ransomware hits a small business, how backups decide the outcome, and how to prepare before it happens.
What is the 3-2-1 backup rule?
Three copies, two kinds of storage, one copy somewhere else. What the 3-2-1 rule means, where it came from, and the mistakes people make applying it.
RPO and RTO explained
Recovery Point Objective and Recovery Time Objective in plain terms, how to pick sensible values, and how they shape your backup design and costs.