The ransom note usually arrives on a weekend, and the first question the IT head asks is not about the encrypted servers. It is: are the backups still there? Too often the answer is no, because the attackers found the backup console days earlier, deleted the restore points, and only then triggered encryption. As a result, immutable backup storage has moved from a nice-to-have to a basic requirement for any organisation that cannot afford to pay, or to lose its data.
Ransomware is a small share of total threats, under 1 percent of detections according to the Seqrite India Cyber Threat Report 2026, but its impact is out of all proportion. In addition, the same report places Maharashtra among the most affected states and Mumbai among the most targeted cities. In fact, a single successful attack can halt operations for days.
Why attackers go after your backups first
Modern ransomware groups are patient. After gaining access, they spend time mapping the network, collecting administrator credentials, and locating backup servers, NAS shares and cloud storage accounts. Their logic is commercial: if you can restore cleanly, you will not pay. So they delete snapshots, encrypt backup repositories, or quietly change retention settings so old copies expire. A Security Operations Center (SOC), meanwhile, can help organisations monitor suspicious activity and investigate potential threats before they escalate.
Traditional backups fail here because anyone with sufficient admin rights can delete them, and stolen admin rights are exactly what attackers hold. Therefore, protection has to survive a compromised administrator account, and that is exactly what immutable backup storage does by design. For broader context, see PACE’s guide to cybersecurity strategies.
What immutable backup storage actually means
Immutability, WORM and object lock
People use several terms interchangeably, but they are not the same, and the difference matters when you read a vendor datasheet.
Immutability means that once a system writes a backup, nobody can modify or delete it until a set retention period ends. In other words, WORM, short for write once, read many, is the older storage term for the same behaviour, originally from tape and optical media. Also, object lock is how S3-compatible object storage implements immutability. In compliance mode, nobody, including the root account, can shorten the lock; governance mode, by contrast, allows privileged users to override it, which is weaker. So, for ransomware protection, compliance mode or an equivalent hardened setting is what you want.
Physical and logical air gaps
An air gap is a separation between the backup copy and the production network. A physical air gap means tapes or disks that you disconnect and store away. A logical air gap, by contrast, uses network isolation, separate credentials and controlled access windows to achieve a similar effect without manual media handling. Moreover, many organisations now combine an on-premises immutable repository, such as a hardened Linux repository or an object storage appliance with object lock, with an offline or isolated copy.
Backup protection methods compared
| Method | What it is | Protects against admin compromise? | Typical use | Main limitation |
|---|---|---|---|---|
| WORM | Write-once, read-many storage behaviour | Depends on implementation and access controls | Retaining data that nobody may change during its retention period | Capabilities depend on the storage implementation |
| Object lock — compliance mode | Object retention that prevents deletion or alteration before expiry | Designed to prevent privileged users from shortening the lock | Immutable backups on supported object storage | Teams must plan retention and configuration correctly |
| Hardened Linux repository | A repository configured with restricted access and hardened controls | Can reduce the risk of backup deletion; exact protection depends on configuration | Backup repositories with restricted administrative access | Not automatically immutable; verify the hardening and backup software design |
| Physical air gap | Disconnected tape or disk stored separately | Strong separation while disconnected | Offline recovery copy | Media handling, restoration time and physical storage requirements |
| Logical air gap | Network isolation, separate credentials and controlled access windows | Can reduce exposure; effectiveness depends on implementation | Isolated backup environments without routine manual media handling | Poor access controls or misconfiguration can weaken isolation |
However, the methods are not interchangeable. Confirm the retention behaviour, administrative permissions and recovery process of the actual implementation before describing it as ransomware-proof.
The 3-2-1-1-0 rule in practice
The industry has extended the classic 3-2-1 rule to reflect ransomware. Each number answers a specific failure scenario.
- Keep 3 copies of your data: the production data plus two backups.
- Store them on 2 different media types, for example disk and object storage, or disk and tape, so one hardware failure cannot take out everything.
- Keep 1 copy offsite, in a second location or a secure cloud region, to survive fire, flood or a site-wide incident.
- Keep 1 copy immutable or offline, so it survives an attacker with full admin access.
- Aim for 0 errors after recovery verification, meaning you test your backups and confirm they restore, not just accept a success report.
However, the final zero is the one most teams skip. A green tick in the backup console only tells you a job finished. It does not prove, for example, that a database will mount or an application will start.
Recovery testing: the part that decides the outcome
Schedule restore tests at least quarterly for critical systems, and after every major change. First, restore into an isolated environment, start the application, and have a business user confirm the data is usable. Measure how long it takes, because your recovery time objective is only real if you have timed it. In addition, you can review PACE’s Audit Services when planning an infrastructure or backup-readiness assessment.
Also plan for scanning. Otherwise, restoring a backup that already contains the attacker’s foothold simply restarts the incident. Good backup platforms can scan restore points for malware before recovery. Keep backup logs too: CERT-In directions require organisations to retain ICT logs for 180 days and report specified incidents within six hours, and the investigation will need them.
Sizing for Indian SMEs and BFSI
How to size your immutable repository
Immutable backup storage changes capacity planning. Because you cannot delete locked data early, your repository must hold every restore point for the full retention period, plus growth. Start with the size of your protected data, the daily change rate, the number of days you need to retain, and realistic deduplication and compression ratios for your data types. Databases and virtual machines, for example, usually compress well; already compressed media and encrypted files do not.
Retention needs for SMEs and BFSI
For a typical SME, 30 days of immutable retention on-premises plus a longer offsite copy is a reasonable starting point. BFSI organisations, however, usually need longer retention driven by regulatory and audit requirements, separate immutable copies for core systems, and documented restore drills. Furthermore, with the Digital Personal Data Protection Act, 2023 and the DPDP Rules, 2025, organisations should review their applicable data-protection obligations. The Act provides for penalties of up to Rs 250 crore for specified contraventions, but that is not an automatic penalty for every backup failure.
If you need to review retention, access controls or recovery testing, ask PACE whether a backup-readiness review is available. Alternatively, explore storage and backup solutions or contact PACE to discuss your requirements.
Protecting the backup infrastructure itself
Do not forget the backup infrastructure itself. For example, use separate credentials for the backup system, enforce multi-factor authentication, keep the backup server off the domain where practical, and restrict who can change retention settings. Finally, organisations that need ongoing operational support can review Managed Services and Remote Infrastructure Management.
Building a backup design that survives an attack
PACE Business Machines designs storage and backup environments, along with SOC and cyber security services, for BFSI, PSU, Government and corporate clients, and holds ISO 27001 certification. If you want a review of how your current backups would hold up against a ransomware attack, contact us at info@pbmpl.com or +91 22-20811955.
Frequently asked questions
1. What is immutable backup storage?
Immutable backup storage protects saved backup data from modification or deletion during a defined retention period. This can help preserve recovery points if an attacker gains administrative access to the production environment or backup console. Therefore, combine it with separate credentials, isolated copies, malware scanning and restore testing rather than treating it as a complete security solution.
2. Is immutable backup storage the same as an air-gapped backup?
No. Immutability prevents changes or deletion during a specified retention period, while an air gap separates a backup from the production network. A physical air gap uses disconnected media; a logical air gap uses isolation and access controls. Organisations may, therefore, combine immutable storage with an offline or isolated copy to reduce different types of risk.
3. What is the difference between object lock compliance and governance mode?
Object lock compliance mode aims to stop anyone, including privileged users, from deleting a protected object or shortening its retention before the lock expires. Governance mode, in contrast, allows authorised privileged users to override the lock. For ransomware backup protection, understand the exact permissions and retention behaviour before choosing a mode.
4. What is the 3-2-1-1-0 backup rule?
Keep three copies of data, use two different media types, store one copy offsite, maintain one immutable or offline copy, and aim for zero errors through recovery verification. Overall, the rule addresses hardware failure, site-wide incidents, malicious deletion and untested backups. The final zero means checking that you can actually restore data and applications.
5. How often should organisations test backup restores?
The article recommends testing restores at least quarterly for critical systems and after every major change. First, restore into an isolated environment, start the application and ask a business user to verify the data. Record recovery time as well as success, so recovery time objectives reflect what the organisation has actually tested.
6. How much storage does immutable retention need?
Capacity depends on the amount of protected data, daily change rate, retention period, data growth, and realistic deduplication and compression. In addition, you must retain locked restore points for the full configured period. Databases and virtual machines may compress well, while already compressed media and encrypted files may not. Therefore, plan capacity using actual workload characteristics.
7. Does immutable backup help with DPDP and CERT-In requirements?
Immutable backups can support resilience and evidence of recovery planning, but they do not by themselves establish compliance. Instead, the DPDP Act and Rules apply according to their provisions and commencement schedule. Similarly, CERT-In directions include log-retention and incident-reporting requirements for covered entities. As a result, organisations should confirm their specific obligations and retain relevant logs separately.
8. Can ransomware delete immutable backups?
A properly configured immutable copy should prevent deletion or modification during its retention period, even if an attacker compromises an administrator account. However, the outcome depends on the storage implementation, lock mode, permissions and configuration. Attackers may still reach other copies, and compromised credentials can affect systems beyond the protected repository, so isolation and testing remain important.
