3-2-1 and immutable backups: how to check that your backups work
What the 3-2-1 rule is, what immutable backups add against ransomware and how to run a test restore to find out whether your backups actually work.
By Víctor Piles TemporalSRE and systems engineerPublished on Updated on 6 min read
Almost every company says it has backups. Far fewer have tried to restore them. And it’s at that moment, with a broken disk or with files encrypted by ransomware, that they discover the backup had been failing for months, that it didn’t include the database or that it was on the same NAS that has just been encrypted. This guide explains how to set up your backups so they survive the worst and, above all, how to check that they work.
In short: follow the 3-2-1 rule (three copies of your data, on two different media and one away from the office), make sure at least one is immutable or offline so ransomware can’t delete it, and run regular test restores. A backup that has never been restored is a backup you don’t know exists.
The 3-2-1 rule, explained
It’s a classic recommendation and it still holds:
- 3 copies of the data: the originals and two backups.
- 2 different media: for example, a NAS and the cloud, or a NAS and rotating external drives.
- 1 copy offsite: if there’s a theft, a fire or a flood, the backup can’t be in the same place.
These days you’ll often hear about 3-2-1-1-0: the same, plus one immutable or offline copy and zero errors in verification. It’s the version designed with ransomware in mind.
Why ransomware changed backups
Ransomware attacks don’t stop at encrypting computers: they look for backups reachable over the network (the NAS, the backup folder, the backup server) and encrypt or delete them first. If your only backup is mounted as a network drive on your machines, it’s as vulnerable as the originals.
That’s why you need at least one copy the attacker can’t touch:
- Immutable: cloud storage with object lock, or repositories with locked retention, where not even the administrator can delete anything early.
- Offline (air gap): drives that are only connected to take the backup and are then stored elsewhere, or tapes.
- Separate credentials: the backup system shouldn’t use the same domain administrator account.
| Destination | Disk failure | Accidental deletion | Ransomware | Theft or fire |
|---|---|---|---|---|
| RAID on the server itself | Yes | No | No | No |
| NAS in the same office | Yes | Yes, with versioning | Only if isolated | No |
| Cloud without immutability | Yes | Yes | Partly | Yes |
| Cloud with object lock | Yes | Yes | Yes | Yes |
| Rotating external drive stored offsite | Yes | Yes | Yes | Yes |
What to back up (and what usually gets forgotten)
- Servers and virtual machines, including their configuration, not just the files.
- Databases, with a consistent dump rather than copying the files while they’re live.
- Microsoft 365 or Google Workspace: the provider keeps the service running, but protecting your data against deletion or a compromised account is your responsibility. Recycle bins and retention policies have limits.
- Laptops holding documents that aren’t synced.
- Configuration of the firewall, switches and applications.
- Documentation on how to restore, kept outside the systems themselves.
How to check that your backups work
This is the part that makes the difference. A basic check you can repeat regularly:
- Review the alerts. Make sure the backup system sends an email or an alert when a backup fails, and that someone reads it.
- Pick something specific to restore: a folder, a mailbox, a database or a whole virtual machine, rotating each time.
- Restore to a separate location, never on top of production data.
- Check that it works: the file opens, the database starts and has recent data, the virtual machine boots.
- Measure how long it took. That figure is your real recovery time, and it may not be the one you had in mind.
- Write it down: date, what was restored, result and time taken. That record also helps demonstrate due diligence if there’s an incident.
When I ran the infrastructure of a food manufacturing plant as an SRE, consistency of the ERP data came first; that’s why it isn’t enough for me that the backup finishes: you have to open what you’ve restored and check that the data adds up.
Two questions you should be able to answer
- How much data can I afford to lose? If the backup runs overnight and the failure happens at six in the evening, you lose the day. This is the recovery point objective (RPO).
- How long can I afford to be down? Restoring several terabytes from the cloud can take a long time over a normal connection. This is the recovery time objective (RTO).
The answers determine how often to back up and whether it’s worth keeping a local copy for fast restores as well as the offsite one.
In SRE as a service I explain how I set up backups and how often I run test restores, and in the reliability and security audit how I review them on an existing platform. If you want to know whether yours would hold up, start with a free 20-minute call.
Frequently asked questions
Is syncing with OneDrive or Google Drive a backup?
Not entirely. Syncing also replicates deletions and encrypted files. It helps, and versioning and the recycle bin give you some leeway, but it doesn’t replace an independent backup with its own retention.
How often should I run a test restore?
The sensible approach is to have it on the calendar at regular intervals and after every significant change (a new server, a migration). The more critical the data, the more often.
How long should I keep backups?
It depends on the business and on the legal retention requirements for each type of document. A common scheme combines recent daily backups with weekly and monthly ones kept for longer. Bear in mind that keeping personal data for longer than necessary also has data protection implications.
Does RAID protect me?
Only against the failure of one disk (or two, depending on the level). It doesn’t protect against deletions, ransomware, software errors or the loss of the whole machine. It’s availability, not backup.
References
- INCIBE: Copias de seguridad, una guía de aproximación para el empresario, which presents the 3-2-1 strategy (in Spanish).
- INCIBE: Ransomware (topic for businesses): how it spreads, how to prevent it with regular backups and how to recover (in Spanish).
