Ransomware vs Backup: Why Most Backups Fail After an Attack

The single most dangerous misconception in business data protection is this: "We have backup, so we're protected against ransomware."

Backup and ransomware resilience are not the same thing. Most standard backup implementations — including well-maintained, monitored, regularly tested backups — have specific failure modes under ransomware attack that render them partially or completely useless for recovery. Understanding these failure modes is the first step to closing the gap.

Failure Mode 1: The Backup Is on the Same Network

The most common and most catastrophic failure mode. Ransomware does not discriminate between primary storage and backup storage — it encrypts every accessible file system it can reach. A backup target that is mounted as a network share, mapped as a drive letter, or accessible via a backup agent using network credentials is within the blast radius.

NAS devices, external drives connected to a server, tape libraries accessible via a network backup server, and on-site backup appliances that are live on the network at the time of the attack are all vulnerable. The ransomware sees them as storage to be encrypted, not as protected recovery infrastructure.

The fix requires architectural separation, not just access controls. A mutable backup target that is accessible from the production network — even with restricted permissions — can be reached by ransomware operating with compromised administrator credentials. Only storage that is logically or physically removed from the network provides genuine protection.

Failure Mode 2: Dwell Time Poisons the Backup History

Modern enterprise ransomware does not encrypt immediately upon infection. It establishes persistence, spreads laterally across the network, and waits — observing the environment — for days, weeks, or sometimes months before triggering the encryption payload.

During this dwell period, your backup jobs run normally. They dutifully back up files, databases, and system states that have been quietly staged for the attack. The backups succeed. The monitoring shows green. Nobody knows anything is wrong.

When the attack triggers and you attempt recovery, you discover that every backup taken during the dwell period — potentially 30, 60, or 90 days of recovery history — contains compromised data. Your most recent clean recovery point may be older than your retention window, leaving you with nothing usable.

The average dwell time for ransomware before detection has been consistently measured at three to four weeks in enterprise environments. For smaller organisations without dedicated security monitoring, it is often longer. A backup retention window of only 30 days provides no margin against this tactic.

What this requires: Sufficiently long backup retention (90 days minimum, ideally longer for critical systems) to ensure a pre-compromise recovery point is available. Immutable storage so that the compromised files backed up during dwell time cannot retroactively overwrite or corrupt earlier clean backups.

Failure Mode 3: The Backup Agent Is Targeted First

Ransomware operators have detailed knowledge of common backup software architectures. Before triggering encryption, sophisticated strains actively identify and terminate backup agent processes, delete VSS (Volume Shadow Copy Service) snapshots, disable backup scheduled tasks, and in some cases log into backup management consoles using harvested credentials and manually delete recovery points.

This is not rare or advanced behaviour. Terminating backup processes and deleting shadow copies has been standard practice in ransomware since at least 2018. If your backup relies on VSS snapshots or agents that run as Windows services with discoverable credentials, this attack is within the capability of commodity ransomware, not just nation-state actors.

What this requires: Backup infrastructure that operates outside the Windows service and VSS framework. Cloud-native backup agents that authenticate to cloud storage via tokens rather than stored credentials. Immutable storage at the cloud layer that cannot be purged even if the local agent is terminated or compromised.

Failure Mode 4: The Cloud Sync Is Not a Backup

Many businesses believe that because their files are in OneDrive, SharePoint, or Google Drive, they are backed up. They are not. These services synchronise your files — which means they also synchronise ransomware encryption.

When ransomware encrypts files on a local device, the sync client detects the change and propagates it to the cloud, overwriting the originals with encrypted versions. Version history provides a partial mitigation — you can potentially restore previous versions — but sophisticated ransomware is specifically designed to cycle through and exhaust version history before triggering, leaving no clean versions to restore.

An organisation that has migrated entirely to Microsoft 365 and uses OneDrive as its file storage without a third-party backup has no ransomware protection for that data beyond Microsoft's limited native retention features.

Failure Mode 5: Backup Jobs Fail Silently During the Attack

Ransomware that is actively spreading across a network creates significant disruption to system processes, file system accessibility, and network performance. Backup jobs that run during or immediately after an attack — before the encryption is detected — frequently fail silently: the job errors out, the failure alert goes to a shared inbox nobody monitors, and the organisation believes it has a current backup when it does not.

Discovering that the most recent backup is actually three weeks old — because jobs have been failing silently — at the moment you need to initiate a restore is a situation that occurs regularly in ransomware incidents.

What Backup Must Have to Survive a Ransomware Attack

Given these failure modes, a backup strategy that is genuinely ransomware-resilient requires:

Immutable storage: Write-once storage at the cloud layer that cannot be modified, deleted, or overwritten during the retention period — by ransomware, by compromised admin credentials, or by anyone. This is the non-negotiable foundation.

Off-network storage: Backup data stored in infrastructure that has no live network connection to the production environment. The attack cannot reach what it cannot access.

Long retention: A retention window that extends beyond the realistic maximum dwell time of ransomware — 90 days at minimum, with longer retention for regulated data categories.

Anomaly detection: AI-driven monitoring that detects unusual encryption or deletion behaviour and triggers alerts or preservation holds before the attack completes — reducing the dwell time window and potentially catching the attack before it finishes.

Independent monitoring: Backup job status monitored independently, with failures generating immediate alerts to a named owner. Not a shared inbox. Not a daily digest. An immediate alert that triggers human review within hours.

Tested restore procedures: Recovery from backup must be tested against realistic scenarios — not just "did the job run" but "can we restore this specific system to this specific point in time in under four hours." The test tells you whether your strategy actually works before you need it to.

Standard backup software, maintained diligently and monitored carefully, closes some of these gaps. It does not close all of them. Immutable, off-network cloud backup — architecturally designed around the specific threat model of ransomware — closes all of them.

That is the distinction between backup that provides a false sense of security and backup that provides genuine ransomware resilience.