The 3-2-1 backup rule is old enough that plenty of engineers can recite it without thinking: three copies of your data, on two different types of media, with one copy stored offsite. It's a good rule. It's also one that a striking number of teams believe they're following while actually violating at least one clause of it, usually without realizing until the moment a restore is the only thing standing between them and a very bad week.
What the rule actually requires, clause by clause
Three copies means the production data plus at least two backups — not the original plus one backup, which is only two copies total and leaves zero room for a backup itself failing. Two different media means the backups shouldn't both live on the same type of storage subject to the same failure modes: a primary server plus a backup on an identical drive in the same array doesn't count, because whatever kills one likely threatens the other. One offsite means at least one copy physically or logically separated from the original's location — a different data center, a different cloud region, or genuinely different infrastructure, not just a different folder on the same network. Teams tend to satisfy this on paper while quietly failing it in practice, because "offsite" has quietly come to mean "a different folder" rather than a genuinely separate failure domain.
The untested restore is the trap that gets people
A backup that has never been restored is a hypothesis, not a backup. It's extremely common for a backup job to report success for months while the actual archive is subtly corrupt, incomplete, or missing a dependency needed to bring a system back up — a config file, a credential, a schema version the current tooling no longer understands. Nobody finds out until an actual incident forces a real restore, which is the worst possible time to discover it doesn't work. The only real defense is scheduling periodic restore drills as a standing task: pick a system, restore it to a test environment, and confirm the result is usable, on a calendar, not "whenever someone remembers."
Ransomware doesn't care about your backup schedule
Modern ransomware is written with backups specifically in mind, because backups are the thing that makes a ransom demand ignorable. If your backup destination is continuously mounted and reachable from the same network and credentials as production, ransomware that gains a foothold will typically enumerate and encrypt or delete that backup right alongside everything else, turning your safety net into just another encrypted target. This is why "it syncs automatically to a network share" is not the safety property people assume it is — automatic and continuous is exactly the access pattern an attacker wants to inherit.
A few properties worth checking against your actual setup, not just your backup vendor's marketing page:
Immutability — backups stored in a mode where they cannot be modified or deleted for a set retention window, even by an account with admin credentials.
Air-gapping — at least one copy disconnected from the network by default, whether that's offline media or a cloud tier that requires a separate, deliberate action to reach.
Separate credentials — backup storage that doesn't authenticate with the same identity provider or admin account as production, so one compromised credential can't reach both.
"It syncs to the cloud" is not a backup
File sync services are genuinely useful, and genuinely not backups, and the distinction matters more than it gets credit for. Sync tools are built to propagate changes quickly, including the change where a file gets deleted, overwritten, or encrypted by ransomware — the sync engine dutifully replicates that damage to every connected device and to the cloud copy, often within seconds. Real backup software is built around versioned, point-in-time snapshots specifically so you can roll back to before the bad event happened, not just to the most recent state, which in a ransomware incident is precisely the state you don't want. If the only copy of critical data lives in a synced folder with no independent version history, that's a single-point failure wearing a backup costume.
Getting 3-2-1 right in practice is less about buying a specific tool and more about periodically asking uncomfortable questions of a system that appears to be working: is the offsite copy actually offsite, or just a different folder; has the restore ever been tested against something other than a single small file; and does anything protecting the backups depend on the same credentials protecting production. Teams that build in an a managed IT services provider partner specifically to own that ongoing verification tend to catch the gap in a tabletop exercise instead of during an actual incident, which is the entire point of doing it at all.
A backup that has never been restored is a theory. Ransomware that can reach your backup storage isn't being blocked by anything. 3-2-1 was never meant to be checked off once and forgotten.
None of this is exotic engineering. It's the difference between treating 3-2-1 as a rule you configured once and treating it as a property you actively verify, on a schedule, against the specific failure modes — corruption, ransomware, and plain human error — that backups exist to survive.
Top comments (0)