The 3-2-1 Backup Rule for Ransomware Recovery in India

The 3-2-1 backup rule means keeping 3 copies of your data, on 2 different types of storage media, with 1 copy stored offsite and offline from your production network. For ransomware recovery, add a fourth requirement: at least one of those copies must be immutable or air-gapped, and every copy must be restore-tested on a schedule — not just "backed up and forgotten." Get this wrong and a ransomware attack stops being an incident and becomes an extinction event for the business.

Most Indian SMBs that get hit by ransomware do not fail because they lacked a firewall or an antivirus. They fail because their only backup lived on the same network the ransomware encrypted, or nobody had actually tried restoring from it in two years. This guide covers how to design a 3-2-1 backup architecture that survives a real ransomware attack, plus the recovery runbook to execute when — not if — it happens.

Why 3-2-1 exists — and why ransomware breaks the naive version

The 3-2-1 rule predates ransomware. It was designed for hardware failure, fire, theft, and human error — scenarios where "backup" just meant "a second copy somewhere else." Ransomware changes the threat model: the attacker is inside your network before encryption begins, and operators actively hunt for and delete or encrypt backups before triggering the payload.

If your "offsite" backup is a NAS device on the same domain, reachable with the same credentials, mapped as a network drive — it is not really offsite in any way that matters to ransomware. It is a second target with a shorter walk. This is the most common backup failure pattern in SMB ransomware cases: technically 3-2-1 on paper, functionally one attack surface in practice.

The 4 components that actually matter

1. Three copies of the data

The production copy plus two backups. This protects against the backup itself being corrupted, misconfigured, or silently failing — a second independent copy catches what the first one misses.

2. Two different media types

Disk and cloud object storage, or disk and tape, or two different cloud providers. The point is that a single failure mode — a bad firmware update, a ransomware strain that specifically targets one storage vendor's API, a misconfigured retention policy — should not be able to take out both copies at once.

3. One copy offsite

Physically or logically separated from your primary site and network. Cloud backup satisfies this if — and only if — access is not tied to the same domain credentials an attacker who compromises your network would already have.

4. Immutability or air-gapping (the ransomware-era addition)

This is what the original 3-2-1 rule did not anticipate, and it is what actually determines whether you recover. An immutable backup cannot be altered or deleted for a set retention window, even by an admin account — including a compromised one. An air-gapped backup is physically or logically disconnected from the network between backup windows, so ransomware has no live path to reach it.

RPO and RTO — the numbers nobody sets until it is too late

Two metrics decide whether your backup strategy is adequate, and most SMBs have never explicitly set either one.

Recovery Point Objective (RPO) — how much data you can afford to lose, measured in time. If backups run nightly, your RPO is up to 24 hours. If ransomware hits at 4pm and your last clean backup is from midnight, everything since midnight is gone.

Recovery Time Objective (RTO) — how long you can afford to be down before the business is materially harmed. A services business might tolerate hours; an e-commerce operation processing live orders loses revenue and trust every additional hour.

These are business decisions, not IT decisions — set by leadership based on what the business can actually tolerate, then engineered backward into backup frequency and recovery architecture.

Restore testing — the step everyone skips

A backup that has never been restored is a hypothesis, not a safeguard. The most common finding in post-ransomware incident reviews is a backup that existed, was current, and simply would not restore cleanly — a corrupted archive, a missing dependency, forgotten credentials, or a restore process nobody had rehearsed under pressure.

Restore testing should be scheduled, not incidental:

1. Quarterly minimum — a full restore of a representative system to a sandboxed environment, verified against a checklist, timed against your stated RTO.
2. After any infrastructure change — new server, new database version, new backup software version. Restore compatibility breaks silently.
3. Document actual restore time — not the vendor's marketing number. If a full restore takes 14 hours and your RTO target is 4, you have a gap that only surfaces during a real incident unless you find it now.

The recovery runbook

When ransomware hits, the difference between a contained incident and a business-ending one is usually whether a runbook existed and was followed calmly, versus improvised under panic.

1. Isolate immediately. Disconnect affected systems from the network before doing anything else. Do not power off encrypted machines — forensic evidence and encryption keys sometimes live in memory.

2. Identify the blast radius. Which systems, shares, and backup targets were reachable from the compromised account or machine? Assume anything reachable is compromised until verified clean.

3. Verify backup integrity before you trust it. Check the last known-clean backup timestamp against when the intrusion likely began — dwell time before encryption is often days to weeks, so a "recent" backup may already contain a dormant payload.

4. Restore to a clean, isolated environment first. Never restore directly back into a still-compromised network. Rebuild or wipe the affected environment, verify it is clean, then restore.

5. Report as required. Under CERT-In's 2022 directions, ransomware and other covered incidents must be reported to CERT-In within 6 hours of noticing — regardless of whether it is contained internally.

6. Do the post-incident review. What let the attacker in, why detection took as long as it did, and whether the backup and restore process performed as designed. Update the runbook with what was actually learned.

What contributes to ransomware downtime cost

Ransom payment is rarely the largest cost of a ransomware incident. Downtime, the recovery effort itself, permanently lost data, and reputational damage typically outweigh it — which is exactly why a tested 3-2-1 backup strategy is a financial control, not just a technical one.

Common 3-2-1 backup rule mistakes that defeat the whole point

1. Backup credentials reused from domain admin. If the account that got phished can also delete backups, you do not have an offsite copy — you have a second copy of the same compromise.
2. "Offsite" that is actually a mapped network drive. A NAS in another building on the same VPN, reachable with the same login, offers almost none of the isolation the rule is designed for.
3. No retention lock on cloud backups. Storage without an explicit immutability or object-lock policy can be overwritten or deleted by anyone with write access — including ransomware that harvested those credentials.
4. Backups that were never restore-tested. Worth repeating — it is the single most common gap found in post-incident reviews.
5. One backup schedule for every system. A single nightly policy applied to both a low-change archive and a live transaction database ignores that they need very different RPOs.

Building this without an in-house infrastructure team

Most Indian SMBs do not have a dedicated backup or disaster-recovery engineer, and that is normal — a documented 3-2-1 architecture and runbook does not require one on staff full-time. It requires:

1. One person accountable for the backup schedule and quarterly restore test, named explicitly, not implied.
2. A written runbook a non-specialist can follow under pressure, stored somewhere reachable even if the primary network is down.
3. Immutability or air-gapping configured once, correctly, and re-verified after any infrastructure change.
4. A relationship with a CERT-In empanelled partner for formal incident response when a real incident crosses that threshold — day-to-day posture stays in-house.

References

1. CERT-In, Directions under sub-section (6) of Section 70B of the IT Act, 2022 — cert-in.org.in
2. IBM, Cost of a Data Breach Report 2024 — ibm.com/reports/data-breach
3. Sophos, State of Ransomware 2024 — sophos.com