Cloud Backup Strategy and the 3-2-1 Rule for Indian SMBs

Cloud backup is the single most effective ransomware control available to Indian SMBs — yet most businesses discover this only after an attack has already wiped their data. The 3-2-1 rule (3 copies of data, on 2 different media types, with 1 copy offsite) is the baseline every organisation should meet. Its modern extension, 3-2-1-1-0, adds 1 immutable or air-gapped copy and 0 errors confirmed through verified restores. If your backup strategy does not include immutability and regular restore tests, you do not have a backup strategy — you have a false sense of security.

Why Backups Are the Real Last Line of Defence

Every security control — firewalls, EDR, patch management — can fail. Ransomware groups know this and have industrialised the process. Modern ransomware does not just encrypt your production data; it actively hunts for backup systems, deletes shadow copies, and exfiltrates data before detonating. If your backup is reachable from the infected machine, it is already compromised.

CERT-In's advisories on ransomware incidents consistently list the absence of tested, isolated backups as the primary factor that converts a recoverable incident into a business-ending one. The organisations that recover quickly are not those with better antivirus — they are those with clean, verified, immutable backups that ransomware could not reach.

The 3-2-1 Rule Explained

The 3-2-1 rule was originally articulated by photographer Peter Krogh and later formalised in enterprise continuity frameworks. It remains the most practical starting framework for any SMB.

The Modern Extension: 3-2-1-1-0

The base 3-2-1 rule was designed before ransomware became the dominant threat. The 3-2-1-1-0 extension addresses the gaps:

1. +1 Immutable or air-gapped copy. Object-lock (WORM — Write Once Read Many) on cloud storage prevents any process, even an administrator account, from modifying or deleting backup objects before a defined retention period expires. An air-gapped copy is physically disconnected from the network entirely.
2. +0 errors verified. Every backup job must be tested. An untested backup is not a backup — it is an assumption. Quarterly restore drills are the minimum; monthly is better for critical systems.

The 3-2-1 Architecture in Practice

graph TD
    A[Production Data] --> B[Local Backup Copy
NAS or External Drive]
    A --> C[Second Media Copy
Different Storage Type]
    C --> D[Offsite Cloud Backup
Regular Backup]
    D --> E{Ransomware Reaches
Network-Accessible Backup}
    E -->|Yes — no immutability| F[Backup Encrypted
or Deleted]
    E -->|No — WORM Object Lock| G[Immutable Copy
Safe and Recoverable]
    B --> H{Ransomware on LAN}
    H -->|Yes — shared drive| I[Local Backup Lost]
    H -->|No — air-gapped| G
    style A fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0
    style B fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0
    style C fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0
    style D fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0
    style E fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0
    style F fill:#5f1e1e,stroke:#EF4444,color:#e2e8f0
    style G fill:#1e3d2f,stroke:#10B981,color:#e2e8f0
    style H fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0
    style I fill:#5f1e1e,stroke:#EF4444,color:#e2e8f0

Backup vs Replication vs Snapshot: Know the Difference

These three terms are often used interchangeably by vendors and confused by buyers. They are not the same thing.

Snapshots are valuable for fast rollbacks of configuration errors or bad deployments. But snapshots stored on the same storage array as production data are destroyed when ransomware hits that array.

RPO and RTO: The Numbers That Matter

Recovery Point Objective (RPO) — the maximum amount of data you can afford to lose, measured in time. If your RPO is four hours, your backup must run at least every four hours. An SMB that backs up daily has an RPO of up to 24 hours, meaning a ransomware attack at 3 PM on a Friday could lose an entire day of transactions.

Recovery Time Objective (RTO) — the maximum time you can afford for systems to be down before the business is seriously damaged. A fintech or e-commerce business may have an RTO measured in hours. A manufacturing firm managing logistics might tolerate a day. These numbers must be defined before an incident, not during one.

Immutability and WORM: Technical Controls Against Ransomware

Object-lock (WORM) is the technical mechanism that enforces immutability on cloud object storage. When a backup is uploaded with an object-lock retention period, no API call — including delete and overwrite — can remove or modify that object until the retention window expires.

Two modes typically exist:

1. Governance mode: Administrators with special IAM permissions can still override the lock. Useful during testing.
2. Compliance mode: No entity, including the root account, can delete the object before the retention period ends. This is the mode that matters for ransomware protection.

Data Residency and Indian Regulatory Considerations

Under India's Digital Personal Data Protection (DPDP) Act 2023, the rules on cross-border data transfers are still being finalised through subordinate rules. However, several sector-specific regulations already govern where data must reside:

1. RBI-regulated entities (NBFCs, payment aggregators, fintechs) must store payment system data exclusively in India under RBI's 2018 circular.
2. IRDAI-regulated entities (insurance) must store policyholder data in India.
3. Healthcare data is increasingly treated as sensitive under IT Act and DPDP principles.

Visit our DPDP compliance guide for a detailed breakdown of how the DPDP Act 2023 affects data storage obligations.

Building a Cloud Backup Policy for an Indian SMB

A backup policy does not need to be a 40-page document. It needs to answer the following questions:

pie title Primary Causes of Business Data Loss
    "Ransomware and Malware" : 36
    "Hardware Failure" : 29
    "Human Error and Accidental Deletion" : 21
    "Natural Disasters and Physical Damage" : 8
    "Insider Threats and Theft" : 6

Encryption: Protecting Backups in Transit and at Rest

Backups themselves must be encrypted to prevent a different class of threat: data exfiltration. Attackers who cannot deploy ransomware may instead exfiltrate your unencrypted backup archive and demand payment to not publish it.

Minimum encryption requirements:

1. At rest: AES-256 encryption on the backup storage target. For cloud backups, enable server-side encryption with a customer-managed key (CMK) where possible.
2. In transit: TLS 1.2 minimum, TLS 1.3 preferred, for all backup data moving to cloud destinations.
3. Key management: Encryption keys must be stored separately from the backup data. A key stored in the same account that holds the encrypted backup is not meaningful protection.

The Restore Test Is Not Optional

CERT-In's cyber hygiene guidelines and NIST SP 800-34 (Contingency Planning Guide for Federal Information Systems) both treat backup verification as a mandatory control, not a nice-to-have. The principle is simple: a backup that has never been restored is a hypothesis, not a recovery asset.

A restore test should confirm:

1. The backup data is actually present and readable (not just a successful backup job log).
2. The restored data is consistent and usable — databases come up, application configurations are correct.
3. The restore completed within your defined RTO.
4. The process is documented so that a team member who was not involved in setting up the backup can execute the restore.

External Resources

1. CERT-In Cyber Hygiene Guidelines — India's nodal agency for cybersecurity incident response.
2. CISA StopRansomware Guide — Practical ransomware recovery controls including backup isolation requirements.
3. NIST SP 800-34 Contingency Planning Guide — The foundational framework for RPO, RTO, and backup testing requirements.