Why Your Backup Won't Save You From Ransomware (and What Immutable Backup Does Differently)
November 1, 2026
Most businesses have a backup. Fewer have a backup that survives the attack it was purchased to survive. The difference is not capacity, speed, or the number of copies. It is whether the attacker who has taken over your network can reach the backup and delete it.
That is the part ransomware operators plan around. Encryption is the visible event at the end. The work that makes it profitable happens earlier: finding the backup infrastructure, stealing the credentials that control it, and removing the recovery points before anyone notices.
Ransomware Deletes What It Can Reach
A modern ransomware attack is rarely a single malicious file. It is an intrusion that runs for days or weeks before the encryption starts. During that time, attackers map the network, collect credentials, and locate the systems that make recovery possible.
Backup infrastructure sits near the top of that list. Before encrypting production data, a typical operator will:
- Delete Volume Shadow Copies so local snapshots cannot be used
- Stop or disable backup services and scheduled jobs
- Use stolen administrative credentials to wipe repositories, network shares, and cloud buckets
- Change backup console passwords and lock out the IT team
- Turn off monitoring and alerting so deletions go unnoticed
None of that requires breaking encryption. It requires credentials that work. In many environments, the same directory account that administers servers also administers the backup platform, and a backup server joined to the same domain is reachable with the same stolen login. Once an attacker owns the domain, they own every backup that trusts it.
Replication Is Not Backup
Cloud sync, storage snapshots, and replication are useful, but they are not the same thing as an immutable backup. Replication copies whatever is on the source. If ransomware encrypts the source, replication copies the encrypted files. If the attacker's credentials can delete a snapshot, the snapshot was never a recovery point.
The same problem applies to versioning that the attacker can purge and to cloud repositories whose delete rights sit with the same account used for daily administration. A backup you can delete is a backup an attacker can delete, whether it lives on a server in the closet or in a cloud region.
There is also the quieter failure: the job that has been failing for six weeks and nobody noticed. Backup software is good at reporting success and less good at making someone read the report. Capacity limits, expired credentials, an agent that stopped running after an update, and a repository that filled up all produce the same result at recovery time: no usable copy.
What Immutable Backup Does Differently
Immutable backup writes recovery points into storage that cannot be changed or deleted for a set retention period. The technical term is WORM: write once, read many. Once a backup lands in an immutable repository, it stays exactly as written until its retention window expires, and that rule is enforced by the storage layer rather than by the account using it.
In practice, immutability looks like this:
- Object lock or WORM retention in cloud storage, where a compliance-mode policy prevents deletion even by an administrator
- Hardened backup appliances that run a locked-down operating system, accept only inbound backup traffic, and expose no general-purpose file shares
- Separate identity and credentials for the backup platform, with multi-factor authentication and no trust relationship to the production domain
- Retention policies that cannot be shortened by the account that runs daily backups
When an attacker deletes the production data and every backup they can reach, the immutable copies remain readable. That is the entire point: not that immutability stops encryption, but that it guarantees a clean restore point that existed before the attack began.
Immutability Is One Layer, Not the Plan
An immutable repository does not fix a weak password, an unsegmented network, or an unpatched server. It protects the recovery path while the rest of the security program does its job. The combination that holds up is usually described as 3-2-1-1-0:
- Three copies of the data, so one failure does not end the conversation
- Two different media or platforms, so one flaw does not take every copy
- One copy offsite, outside the building and outside the blast radius
- One copy offline or immutable, unreachable by production credentials
- Zero errors, verified by restoring data rather than reading a success message
Around that structure, a few controls matter more than most:
- Isolate the backup network. Backup traffic should not share a flat network with workstations and servers.
- Use dedicated backup administrators. The account that runs backups should not be a domain administrator, and the domain administrator should not be able to delete backups.
- Alert on destructive actions. A backup deletion, a retention policy change, or a disabled job should page someone the same day.
- Keep retention longer than the dwell time. If an intrusion runs for three weeks before detection, a fourteen-day retention window can leave you with no clean copy.
It is also worth being clear about what immutability does not do. It does not stop an attacker from stealing data and threatening to publish it, which is now a common second lever in ransomware extortion. It does not replace endpoint protection, patching, multi-factor authentication, or network segmentation. It protects one thing well: the ability to restore without paying.
Test the Restore, Not the Backup
A green checkmark means the backup software finished writing. It does not mean you can recover. The only test that counts is restoring real data into a working environment and measuring how long it takes.
That test should answer three questions. How much data would we lose if the attack happened right now? That is the recovery point objective. How long would it take to be operational again? That is the recovery time objective. And who actually performs the restore at two in the morning when the person who built the system is unavailable?
Restore into an isolated environment first. A recovery that reintroduces the malware is not a recovery. Validate the restored data, scan it, confirm the applications work, and document the runbook. Then test again on a schedule, because backups, staff, and infrastructure all change.
Questions to Ask About the Backup You Have
These are the questions that separate a backup from a recovery plan:
- Can the account your IT team uses delete the backup copies? Can a domain administrator?
- Is at least one copy offline or immutable, and for how many days?
- Do backups share a network or credentials with production?
- When did you last restore something real, and how long did it take?
- Would a deleted backup generate an alert, and who receives it?
- Does your cloud copy preserve versions that an attacker with stolen credentials cannot purge?
- Does retention outlast the time an intruder could realistically stay hidden in your network?
If any answer is uncertain, the backup is a hope rather than a control. The fix is rarely a larger purchase. It is usually configuration, separation, and a tested restore.
Build the Recovery Path Before You Need It
Technolink of the Rockies has designed and managed data backup and recovery for Colorado businesses since 1983. We can review how your current backups are configured, identify what an attacker with domain credentials could delete, and design a repository that stays out of reach, then test the restore so the answer is known before an incident forces the question.
If you are not certain your backups would survive an attack, contact us to review the recovery path. It is cheaper to find the gap now than to discover it during an outage.
Posted in: Data Backup & Recovery, Cybersecurity
