Backups in 2026: Why Ransomware Now Deletes Your Backups Before It Encrypts Anything, What Immutable Storage and the 3-2-1-1-0 Rule Actually Protect, and How to Prove a Restore Works Before You Need It
- Internet Pros Team
- October 7, 2026
- Networking & Security
Almost every business says it has backups. Far fewer have tried to restore a whole server from them under pressure, against the clock, with the main network down. In 2026 that gap matters more than ever. Modern ransomware crews no longer encrypt first and negotiate later. They spend days quietly finding your backup console, deleting snapshots and corrupting backup copies, and only then set off the encryption. If your backups die first, the ransom note is the only recovery plan left.
Why Attackers Go After Backups First
Paying a ransom only makes sense to a victim who cannot recover alone. Attackers know this, so destroying backups has become a standard step in the attack. Incident response reports from firms such as Sophos and Veeam have found that the large majority of ransomware attacks now try to reach the backup repositories, and that many of those attempts succeed at least in part. When backups are compromised, victims are far more likely to pay.
The method is rarely clever. The attacker steals an administrator password, often through phishing or an infostealer, then logs into the backup server with that same account. If the backup system shares the same domain and credentials as everything else, nothing stops them. A few clicks remove retention policies, delete restore points and wipe the cloud copy too.
A backup that an administrator can delete is a backup that a stolen administrator account can delete. Real protection means some copies cannot be changed by anyone until their timer runs out.
From 3-2-1 to 3-2-1-1-0
The classic 3-2-1 rule asks for three copies of your data on two different types of media, with one copy offsite. It was designed for disk failures, fires and floods, not for an intruder who can reach every copy over the network. The updated rule adds two digits:
- 3 copies of your data, including the live production copy.
- 2 different media or platforms, so one failure mode cannot take out everything.
- 1 copy offsite, in a different building, region or cloud provider.
- 1 copy immutable or air-gapped, meaning it cannot be altered or deleted, even by an administrator, until its retention period ends.
- 0 errors on automated restore verification, meaning you have proof the backups can actually be restored, not just a green tick saying the job finished.
What “Immutable” Actually Means
The word is used loosely in marketing, so it helps to know the main options and what each one really stops.
| Approach | How it works | What to watch for |
|---|---|---|
| Object Lock (compliance mode) | Cloud storage such as Amazon S3, Azure Blob or Backblaze B2 refuses to delete or overwrite an object until a set date, even for the account owner | Governance mode can be bypassed by privileged users. Compliance mode cannot, so choose the retention period carefully |
| Hardened Linux repository | An on-site backup server with immutability flags, single-use credentials and no remote shell | Only as strong as its physical and console security. Keep it off the domain |
| Storage snapshots | Read-only point-in-time copies on a NAS or SAN | Often deletable from the same admin interface the attacker already controls unless snapshot locking is turned on |
| Tape or removable media | Physically disconnected copies stored offsite | A true air gap, but slow to restore. Rotation must actually happen |
Whatever you choose, separate the identities. The backup system should use its own accounts with multi-factor authentication, not domain admin. Deleting a backup or shortening retention should need a second person to approve it, a feature many backup products now call four-eyes or multi-person authorization.
RPO and RTO: The Two Numbers That Matter
Before buying anything, decide two figures for each important system. The Recovery Point Objective (RPO) is how much data you can afford to lose, measured in time. A nightly backup means you could lose up to 24 hours of work. The Recovery Time Objective (RTO) is how long you can afford to be down before the business is seriously harmed.
These numbers drive the design. An accounting database with a one-hour RPO needs frequent snapshots or log shipping. A file share that can be down for two days may be fine with nightly copies to cloud storage. Restore speed matters too: pulling ten terabytes back over a 500 Mbps line takes roughly two days.
The SaaS Blind Spot
Many small businesses believe Microsoft 365, Google Workspace, Salesforce or their accounting platform is already “backed up.” Under the shared responsibility model, the provider keeps its service running and protects against its own hardware failures. Protecting your data from accidental deletion, a malicious insider, a compromised account or a sync mistake is mostly your job. Recycle bins and version history expire and can be purged. A separate third-party backup of mailboxes, OneDrive, SharePoint and shared drives is now a basic requirement, not an extra.
Proving a Restore Works
The most common backup failure is not a missing backup. It is a backup that turns out to be incomplete, corrupted, encrypted with a key nobody can find, or simply too slow to meet the business’s needs. The only way to know is to restore from it on a schedule.
- Automate verification. Many backup platforms can boot a backed-up server in an isolated sandbox, check that it starts and that its services answer, then report the result.
- Do a full test every quarter. Restore at least one critical system end to end and time it against your RTO.
- Test file-level restores monthly. Pick random files and mailboxes, and confirm they open.
- Scan before you restore. Attackers may have been inside for weeks. Check restore points for malware so you do not bring the intruder back with your data.
- Write the runbook down and print it. If the network is down, a recovery guide stored only on the file server is no use to anyone.
Checklist: A Backup Plan That Survives an Attack
- Map what matters. List critical systems and SaaS apps, and set an RPO and RTO for each.
- Follow 3-2-1-1-0. Make sure at least one copy is immutable or physically offline.
- Isolate backup credentials. Use separate accounts with MFA, keep backup servers off the domain and require approval to delete.
- Back up your SaaS data. Cover email, cloud drives, CRM and accounting platforms with an independent tool.
- Protect the encryption keys. Store backup encryption keys and passwords somewhere that is still reachable if the main network is down.
- Alert on tampering. Get notified when retention changes, jobs are disabled or large deletions happen.
- Test restores on a schedule. Do automated checks weekly and a full timed recovery every quarter.
The Bottom Line
Backups are no longer just insurance against a dead hard drive. They are the main thing standing between a ransomware attack and a ransom payment, and attackers know it. A plan that holds up in 2026 keeps at least one copy that nobody can delete, protects backup access as tightly as the bank account and treats restore testing as a routine job rather than an afterthought. If you want help mapping your RPO and RTO, setting up immutable offsite copies or running your first timed recovery test, the Internet Pros team can help.
