Ransomware: 5 reasons your backups won't save you
In 94% of attacks, criminals go after your backups first, and they succeed half the time. The 5 flaws that make a backup useless, and how immutability puts a stop to it.
You have backups. Good. But in 94% of ransomware attacks, criminals first try to compromise those backups, and they succeed in 57% of cases (Sophos, State of Ransomware report). A backup the attacker can reach is not a safety net: it is a target.
And when the backup falls, everything gets worse. According to Sophos, when backups are compromised:
- recovery costs are eight times higher;
- the ransom demand doubles;
- victims are almost twice as likely to pay (67% versus 36%).
Here are the five reasons a backup fails against ransomware, and what fixes each one.
1. It is reachable from the production network
If your backup server answers on the same network as your servers, an attacker who takes over the domain sees it too. They encrypt your data and your copies in one move. A backup only protects if it lives on an isolated plane that the production network cannot reach under normal operation.
2. It is not immutable
This is the most common and most serious flaw. If an administrator can delete a backup, then a compromised administrator can too. And that is exactly what attackers aim for: steal privileged credentials, then wipe the copies before encrypting.
An immutable backup changes everything: for a defined window, it cannot be modified or deleted, by anyone, even with root account credentials or the API key. More on this below, because it is the heart of the defense.
3. Retention is too short
Modern ransomware does not strike on the day of the breach. It often dwells in the network for weeks, spreading and locating the backups. If your immutability window or your retention is shorter than that dwell time, your only clean copies have already been overwritten by the time the attack triggers. Retention must cover wider than the observed dwell time.
4. You have never restored it
Some backups already contain the encrypted data or the dormant malware, without anyone knowing. The only way to find out before the incident is to restore and boot a machine for real. That is the whole point of our article Verified backups: why testing your restores became non-negotiable. A copy never tested is a hypothesis, not a guarantee.
5. The backup credentials are the domain credentials
If you log into the backup console with the same Active Directory account as the rest of the estate, then compromising the domain means compromising the backup. The backup must have its own identity: separate accounts, multi-factor authentication, a clean split from the production directory.
Immutability: the one flaw ransomware cannot exploit
Remember one word: immutable. Technically, it is the WORM principle (write once, read many): once written, the data is locked for a chosen period. That is what Object Lock does on object storage.
The difference from a simple “read-only” is crucial. A read-only permission can be removed in one click by anyone with the right privileges. Object Lock, on the other hand, is enforced at the storage layer: during the retention window, no command can delete or overwrite the object, even one issued by the root account or with the API key. The ransomware may hold your admin credentials, but it hits a wall.
Immutability does not replace the other protections, it crowns them. The winning combination: a copy that is isolated (reason 1), immutable (reason 2), with retention longer than the dwell time (reason 3), and tested (reason 4). That is what turns a backup into a guaranteed point of return.
What it looks like in practice
This is exactly the architecture of our managed Proxmox backup. Your data goes to a managed, encrypted Proxmox Backup Server that is immutable through Object Lock, hosted in Canada, beyond the reach of the Cloud Act. The copy is isolated from your production, retention is set to survive dormant malware, and every backup is monitored, verified and tested through a real restore. Ransomware can encrypt your servers: it cannot touch the clean point you restart from.
To go further when downtime is costly, immutability pairs with a disaster recovery plan.
Frequently asked questions
Can ransomware really delete my backups? Yes, and it is the norm. In 94% of attacks, criminals try to compromise the backups, and they succeed half the time. That is why immutability is no longer optional.
Does immutable mean I can never delete anything again? No. The data is locked only during the retention window you choose. After that, the normal cycle resumes. You keep control, the attacker does not.
Object Lock or plain read-only, what is the difference? A read-only permission can be removed with the right privileges. Object Lock is enforced by the storage itself: during retention, no one can delete the object, not even the root account or the API key.
Is immutability enough on its own? No. It must come with network isolation, retention longer than the dwell time, separate credentials and restore testing. It is the whole set that protects.
Would your backups survive ransomware? Explore managed Proxmox backup, immutable, isolated and tested, or create your account to discuss it and get a price.