Most organizations have a backup schedule. Far fewer have a backup strategy — one that's been deliberately designed around what actually needs to be recovered, how fast, and against what threats. This article covers the 3-2-1 rule and its modern extension toward immutability, the tradeoffs between backup types, and how to build a strategy around real recovery requirements instead of a generic schedule.
The 3-2-1 rule, and its modern extension
The 3-2-1 rule has been the baseline standard for backup strategy for a long time, and it's still a sound starting point: keep 3 copies of data, on 2 different media types, with 1 copy stored offsite. The logic is straightforward — a single copy is one hardware failure away from gone, two copies on the same media type are vulnerable to the same failure mode, and no offsite copy means a single site-level event (fire, flood, theft) can take out every copy at once.
That rule was built for an earlier threat landscape, and it needs one essential modern addition: immutability. At least one copy of backup data should be immutable — meaning it cannot be altered, encrypted, or deleted, even by a compromised administrator account, for a defined retention window. This isn't optional refinement anymore; it's become the single most important defense against modern ransomware, which CISA's #StopRansomware guidance confirms specifically targets backup systems as part of the attack. An attacker who gains administrator credentials can typically reach and destroy standard backups just as easily as production data — an immutable copy is the one thing that credential compromise cannot touch.
3-2-1 without immutability has a hole ransomware is built to find
Modern ransomware operators actively seek out and destroy accessible backups before triggering encryption, specifically to eliminate the recovery option and force a ransom decision. A 3-2-1 strategy without at least one immutable, access-restricted copy leaves exactly that gap open.
Backup types and their tradeoffs
Not all backups are captured the same way, and the choice of backup type affects storage cost, backup window, and — critically — how long recovery actually takes.
| Backup type | What it captures | Tradeoff |
|---|---|---|
| Full backup | A complete copy of all data at the time of the backup | Simplest and fastest to restore from, but slowest to run and most storage-intensive |
| Incremental backup | Only data changed since the last backup of any type | Fastest to run and most storage-efficient, but restore requires the last full backup plus every incremental since — slower and more failure-prone to restore |
| Differential backup | All data changed since the last full backup | A middle ground — faster restore than incremental (only the full plus the latest differential are needed), but each differential grows larger until the next full backup |
Most real backup strategies combine these — a periodic full backup as an anchor, with incrementals or differentials in between to keep backup windows and storage costs manageable. The right mix depends on how much data changes, how large the environment is, and how quickly a restore needs to complete, which is exactly why backup type selection can't be separated from recovery requirements.
Designing strategy around recovery requirements, not "backups exist"
The most common failure in backup strategy isn't a missing backup — it's a backup strategy that was never actually designed, just accumulated. A schedule gets set up once, based on whatever the default was, and nobody revisits whether it actually matches what the business needs to recover and how fast.
A real backup strategy starts from the same place a real disaster recovery plan does: the Recovery Point Objective (how much data loss is tolerable) and Recovery Time Objective (how much downtime is tolerable) for each system, tied to how critical that system actually is to the business. See RPO vs. RTO Explained for how those numbers get set. A system with a one-hour RPO needs backups running far more frequently than one that can tolerate losing a day of data, and a system with a tight RTO needs a restore process proven to be fast, not just a backup that technically exists somewhere.
Treating every system with the same nightly-backup, 30-day-retention default is easy to set up and almost never correct — it typically over-invests in low-priority systems while under-protecting the systems the business can least afford to lose. Backup strategy done well is tiered: retention windows, backup frequency, and immutability requirements set deliberately per system based on what that system's data is actually worth and how quickly it needs to come back.
Common mistakes
- No immutable or offline copy. Ransomware that encrypts production can also reach and destroy accessible backups — without at least one copy the attacker genuinely cannot touch, backups don't guarantee recovery.
- Treating backup frequency and retention as one-size-fits-all. A generic nightly-backup, 30-day-retention policy applied to every system regardless of criticality wastes resources on some systems and underprotects others.
- Never testing restores. A backup that has never been test-restored is an assumption, not a guarantee — corrupted backups and broken restore processes are routinely discovered only when a real restore is attempted.
- Confusing backup existence with backup strategy. Backups running on a schedule someone set up years ago, never revisited against current RPO/RTO needs, is accumulation, not strategy.
FAQ
Is cloud backup automatically offsite and therefore compliant with the "1" in 3-2-1? Generally yes, as long as it's genuinely a separate location and infrastructure from the primary environment — but confirm the cloud copy also meets the immutability requirement, since not all cloud backup configurations enable it by default.
How long should backups be retained? It depends on the data and any applicable compliance or cyber insurance requirements, but retention should be a deliberate decision per system tier, not a single default applied everywhere. See Backup Testing Best Practices for how retention interacts with restore testing.
Is immutability the same as air-gapping? Related but not identical — an air-gapped backup is physically or logically disconnected from the network, while an immutable backup can remain connected but is protected from alteration or deletion for a defined period, often through write-once storage or retention locks. Many modern strategies use immutability rather than a true air gap because it's operationally easier while still defeating credential-based attacks.