Backup Strategy 2026: 3-2-1 Is Dead — Here's What Replaced It

Three copies, two media, one off-site. The 3-2-1 rule defined backup strategy for two decades and survived as a credible mental model far longer than the technology underneath it. In 2026 the rule still applies — but the world it described is now a minority case, and the rule alone is no longer a credible compliance answer.

This article walks the evolution: what 3-2-1 was, why it stopped being enough, what the 3-2-1-1-0 framework adds, and the concrete minimum-viable backup posture for an EU SMB in 2026. Aimed at the IT lead who has been told "we already do 3-2-1" and needs to know whether that sentence still buys them anything.

What 3-2-1 meant in 2008

Peter Krogh formalised the rule for digital photographers around 2008. The threat model was hardware failure: a single hard drive dies, a single optical disc gets scratched, a single office burns down. The defence:

• 3 copies of your data (the original + at least 2 backups)
• 2 different media types (so a media-specific failure does not take both backups)
• 1 off-site copy (so a site-wide event does not take everything)

For its time the rule was excellent. Cheap, memorable, defensible. For 18 years it provided a useful conversation starter — "do you do 3-2-1?" forced people to think about backup at all.

What broke 3-2-1

Three categorical shifts in the threat model:

Shift 01: Ransomware became the dominant threat

The 3-2-1 rule assumes the bad event is mechanical. Ransomware is intelligent. It hunts for backups. It encrypts NAS volumes, dwell-times the cloud sync, finds the offline copy if it can reach it. The "3 copies" defence is worthless if the attacker can encrypt all three.

By 2024, the median ransomware operator's attack chain included explicit backup-discovery and backup-destruction stages. The 2025 ENISA threat report cited "compromised backup integrity" as a recurring finding in incident close-out reports across regulated EU industries.

Shift 02: The "off-site" became "the cloud"

In 2008, "off-site" meant tapes in a fireproof safe at a sister office. In 2026, "off-site" almost always means a cloud bucket. This is operationally easier but introduces new failure modes: account compromise, API rate limits during restore, retention policy misconfigurations, sub-processor concentration risk.

The cloud-as-off-site is good, but it does not produce the air-gap that the original rule assumed. A backup target reachable over the network is reachable by the same compromised credentials that touched production.

Shift 03: Recovery became a tested capability, not a checkbox

3-2-1 produces backup. It does not produce recovery. Most companies discover this at the worst moment — the day they actually need to restore, when the team learns the backups exist but cannot be restored within the implied SLA, or were corrupted at source, or were missing critical data, or were encrypted by ransomware before the cloud sync.

The shift in 2026 thinking: "do you have backups" is the wrong question. "Have you proven you can recover" is the right one.

The 3-2-1-1-0 framework

The natural evolution. The numbers extend; the discipline is what changes.

• 3 copies of the data
• 2 different media types
• 1 off-site copy
• 1 immutable / air-gapped copy (the ransomware defence)
• 0 errors in the most recent restore test

Each addition addresses one of the shifts above. The framework is not magic — it is the same boring discipline applied with the new threats in mind.

The "1 immutable" copy

The single most important addition. An immutable backup is one that cannot be modified or deleted for a fixed retention period, even by a fully privileged admin. The mechanisms:

• Object Lock (S3-compatible storage): writes a retention period on the object that cannot be shortened. AWS S3, Wasabi, Backblaze B2, Minio all support this.
• WORM (Write Once Read Many): the legacy term, still used by some backup vendors and tape libraries.
• Air-gapped tape: physically disconnected when not actively being written. The oldest defence; still works.
• Backup vendor immutability: Veeam, Acronis, Keepit, Barracuda all offer immutable tiers with documented retention enforcement.

The pattern that works for most SMBs: backup vendor → S3-compatible storage with Object Lock for compliance retention (e.g., 365 days) + a separate snapshot tier with longer Object Lock retention for ransomware resilience (e.g., 90 days minimum).

The "0 errors" requirement

Recovery testing was always implicit in good 3-2-1 practice. 3-2-1-1-0 makes it explicit. The standard:

• Restore tests run on a documented schedule
• Restore tests cover representative artefacts (mailbox, file share, database, VM)
• Restore tests measure actual RTO against the documented target
• Restore tests produce a signed report
• Restore tests catch errors before users discover them

"Zero errors" is the bar. A successful restore test with one minor finding is not zero errors. The discipline matters because the alternative is finding the errors at incident time.

The minimum viable backup posture for a 2026 EU SMB

For a 50-300 seat company that wants to be defensible to an audit and recoverable under realistic attack, the floor:

Microsoft 365 + Google Workspace data

Third-party backup is now table stakes. Microsoft's native retention is a soft-delete window, not a backup. The vendors that satisfy 3-2-1-1-0 on M365:

• Veeam Backup for Microsoft 365: deepest feature set, EU-resident storage available, immutable tier mature. Our default.
• Acronis Cyber Protect Cloud: bundles backup + EDR; popular for SMB-scale.
• Keepit: EU-native, cloud-only, strong sovereignty story.
• Barracuda Cloud-to-Cloud: economical for smaller tenants.

What good looks like: hot tier 30 days, warm tier 1 year, archive tier 7 years (for regulated data), immutable retention 90+ days on the cold tier, restore drill every quarter on a real artefact, EU-resident storage with documented data-residency attestation.

Infrastructure-as-a-Service (Azure / AWS / GCP)

Cloud-native backup at the IaaS layer:

• Azure Backup + Recovery Services Vault with immutable vault tier enabled
• AWS Backup + Vault Lock with compliance-mode lock
• GCP Backup and DR Service with retention enforcement

The non-obvious requirement: backup the IaaS config + IaC state, not just the workloads. A successful recovery from total loss includes reproducing the network topology, IAM roles, KMS keys, and policy attachments. Terraform state in a separate region with versioning is part of the backup architecture.

On-premises infrastructure

For the workloads that remain on-prem (which is more than you would think — local databases, line-of-business applications, file shares):

• Local backup target (NAS, dedicated backup server) — the "2 different media" line
• Cloud replication tier (Wasabi, Backblaze, AWS S3 IA) with Object Lock — the "1 off-site immutable"
• Optional: air-gapped tape rotation for the highest-tier workloads

SaaS data beyond M365 / Workspace

The forgotten line. Salesforce, HubSpot, Notion, Linear, GitHub. Vendor-side backup is "good enough" until it is not (data loss from user error, vendor bug, contract dispute, ransomware in your own admin account that propagates to admin-controllable SaaS).

For each SaaS holding business-critical data, ask: can we restore yesterday's state? In most cases the vendor's answer is "we have backups but restoring is a paid service with multi-day SLA". For data where that is unacceptable, third-party SaaS backup (Rewind, OwnBackup, etc.) is the pattern.

The cost honest enough to discuss with the CFO

For a 200-seat EU SMB with M365 + Azure + on-prem mix:

Line	Annual cost
M365 third-party backup (200 seats × €4/seat/mo)	€9,600
Azure Backup with immutable vault (workload-dependent)	€6,000-€12,000
On-prem backup hardware (amortised) + cloud replication	€4,000-€8,000
SaaS backup for top 3 critical SaaS	€3,000-€6,000
Operational engineering (quarterly drills, monitoring)	€8,000-€15,000
Total	€30,600-€50,600

Context: the median ransomware incident at this scale runs €150k-€800k in direct costs + business interruption, with insurance coverage increasingly contingent on demonstrated backup discipline. The economic case is straightforward.

The drill cadence we ship

Quarterly is the floor for any regulated entity. Monthly is the bar for high-stakes workloads. Annual is acceptable for archive tiers.

Tier	Drill cadence	Coverage
Tier 1 (production databases, primary apps)	Monthly	End-to-end restore with data validation
Tier 2 (collaboration, M365, file shares)	Quarterly	Granular + bulk restore samples
Tier 3 (dev/staging, internal tools)	Bi-annual	Sampled restore, automated verification
Tier 4 (archive, compliance retention)	Annual	Sample restore + retention verification

The drill is not a fire drill. It runs in an isolated environment, against real backup data, with measured RTO captured. The output is a signed report.

The compliance angle (DORA, NIS2, ISO 27001)

Every modern compliance framework now has explicit backup + recovery testing requirements:

• DORA Article 11: "ICT business continuity policies and disaster recovery plans" with explicit testing requirements
• NIS2 Article 21(2)(c): "business continuity, such as backup management"
• ISO 27001 Annex A.5.30: "ICT readiness for business continuity" with testing as a control
• ISO 27001 Annex A.8.13: "Information backup" with verification requirement

The auditor expectations align: documented strategy, evidence of execution, evidence of testing, evidence of corrective action when testing finds gaps. The 3-2-1-1-0 framework maps cleanly to all four.

The five anti-patterns we still see

1. "We use Microsoft 365 retention — that's backup." No, it is a soft-delete window. Microsoft's shared responsibility model is explicit: customer data preservation is the customer's job.
2. "We have a NAS in the office for backup." Single point of failure + on-network = ransomware target. Needs the off-site immutable layer.
3. "We back up to the cloud — that's our off-site." Cloud sync is not backup if it uses the same credentials as production and lacks immutability.
4. "We restored a file last year, so we know recovery works." File restore proves nothing about database restore, tenant restore, or DR-site failover.
5. "Our backup vendor handles it." Vendor SLAs cover availability, not your specific recovery capability. Drill or do not claim recovery.

The four-question diagnostic

Run this against any current backup posture:

1. If our most-privileged admin account were compromised right now, which backups could the attacker reach?
2. What is our committed RTO per workload tier, and when did we last verify it?
3. Where is our backup data resident, and does that satisfy our compliance scope?
4. If we tried to restore yesterday's full state of $critical_saas, what is the documented procedure?

If any answer is vague, the posture has a gap. The gap may be acceptable for your risk appetite. The gap may not be. Either way, name it.

The one paragraph version

3-2-1 was right for 2008. 2026 needs 3-2-1-1-0: three copies, two media, one off-site, one immutable / air-gapped, zero errors in the last restore test. The additions are not cosmetic — the "1 immutable" defends against ransomware that hunts backup targets; the "0 errors" forces the drill cadence that catches silent backup failures before users do. Minimum viable posture for an EU SMB: third-party M365 backup + cloud-native IaaS backup with immutable vault tiers + SaaS backup for the critical few + monthly to quarterly drills depending on tier. The compliance frameworks (DORA, NIS2, ISO 27001) all require the same disciplines under different headings.

If you want this designed + deployed + operated, that is the engagement shape under our Microsoft 365 Backups service for the M365 estate and Backup & Disaster Recovery for the broader infrastructure + SaaS surface. The free Bloodbath Scan includes a backup-posture assessment as part of the resilience baseline.