Module 4 · Backup Strategy — 3-2-1-1-0 and Ransomware-Resilient Architecture

Why this module exists. A backup that fails to restore is worse than no backup — it costs effort to maintain and provides false assurance. This module covers what to back up, how to store it so attackers cannot destroy it, and how to verify it works.

The 3-2-1 rule — the baseline

The classic backup recipe: 3 copies of data, on 2 different media types, with 1 copy off-site. The interpretation in modern cloud-native environments:

• Primary (production data) + 2 backups.
• Two different storage technologies (e.g., disk + object storage; or cloud + on-prem).
• One copy geographically separated from the others — different region, different cloud, different building.

The modern addition — the 3-2-1-1-0 rule

Ransomware reality forced the 3-2-1 to evolve:

• 3 copies of data
• 2 different storage media
• 1 copy off-site
• 1 copy immutable or air-gapped (the new addition)
• 0 errors after recovery verification

The immutable / air-gapped copy is what defeats ransomware that targets the backup itself.

Immutable storage — what it actually means

• S3 Object Lock: AWS S3 + GCS + Azure Blob support immutability policies. Once written with a retention period, the object cannot be modified or deleted until the period expires — by anyone, including the account owner. The strongest cloud-native immutability.
• WORM-capable on-prem storage: vendor-specific (Veritas NetBackup with appliance WORM, Veeam Hardened Repository on Linux with immutable flag).
• Linux immutable bit + dedicated user: chattr +i on backup files; backup-service user can write but not modify; root account separated from backup operations.

Air-gapped backups

The strongest defence: the backup storage is physically or logically disconnected from production network, accessible only during backup windows.

• Tape backups rotated to offsite vault. Slow restore, near-perfect ransomware resistance.
• Periodic tape pulls from VTL: virtual tape library that maintains tape-like semantics on disk; copies offloaded to actual tape.
• Cloud backup vaults with separate-credential access: backup written by production-side service account; restore requires a credential held only by the IR team.
• Pull-not-push architecture: backup server pulls from production rather than production pushing. Production cannot delete or corrupt the backup server’s state.

Backup-target ransomware patterns

Modern ransomware operators specifically target backups. The attacker workflow:

1. Domain Admin acquired.
2. Enumerate backup infrastructure — Veeam, Commvault, Backup Exec.
3. Authenticate to backup admin console using credential reuse or stolen Veeam/Commvault admin credentials.
4. Delete or encrypt all backups.
5. Detonate ransomware on production.

The backup architecture must make step 3-4 impossible. Separate credentials, immutable storage, MFA on backup admin, network segmentation are the four controls.

What to back up

Restore verification — the often-skipped half

A backup that has never been tested is a hope, not a recovery capability. Verification cadence:

• Weekly: spot-check restore of one random file or database from each backup tier.
• Monthly: full restore of one critical system to an isolated environment; functional verification.
• Quarterly: full DR drill — restore an entire workload tier; measure actual RTO and RPO achieved.
• Annually: chaos exercise — restore production state in a parallel environment as if production was destroyed.

Indian-regulatory backup requirements

• RBI: backup data must be on Indian soil for regulated entities.
• SEBI: market-infrastructure operators require BCP-DR architecture including geographically-separated data centres.
• DPDP: backup data is personal data — same protection requirements (encryption, access control, retention bound).

Common failure modes

• Backup admin credentials same as production admin — same compromise destroys both.
• Backups stored on same SAN as production — single hardware failure loses both.
• Cloud backup with same provider as production — provider-account-compromise loses both.
• No verification cadence — backup runs report “success” but actually fail silently.
• Long retention without lifecycle — costs accumulate; restore window of older backups never tested.

Key takeaways

• 3-2-1-1-0: 3 copies, 2 media, 1 off-site, 1 immutable/air-gapped, 0 errors after verification.
• Immutable: S3 Object Lock, on-prem WORM, or chattr +i with separated user.
• Backup admin credentials separated from production; MFA mandatory.
• Verification weekly / monthly / quarterly / annually.
• Indian regulatory: data residency, geographically-separated DR, DPDP backup data protection.