![Ransomware Backup Recovery: 7 Steps That Work [2026]](/images/blog/ransomware-backup-recovery-7-steps-that-work-2026.jpg)
Most IT teams discover their backup strategy doesn't work the moment ransomware locks them out. Recovery isn't about having backups—it's about having backups you can actually restore, verify, and trust when every file server shows a ransom note.
I've walked dozens of teams through post-incident recoveries. The pattern repeats: backups existed, but they were either encrypted alongside production, corrupted weeks earlier without anyone noticing, or stored in locations the malware reached before anyone pulled the plug. A real ransomware backup recovery strategy needs immutability, air gaps, regular test restores, and integrity verification baked in—not bolted on after the first incident.
Step 1: Enforce Immutable Storage at the Repository Level
Immutability means an attacker can't delete or encrypt your backups even with admin credentials. Start here.
Configure your backup software to write to object storage with S3 Object Lock enabled, or use a dedicated backup appliance with native immutability. Most enterprise backup platforms—Veeam, Commvault, Rubrik—support immutable repositories. Enable it in the storage target configuration, not just as a policy flag.
# Example: Enable S3 Object Lock on an existing bucket (AWS CLI)
aws s3api put-object-lock-configuration \
--bucket your-backup-bucket \
--object-lock-configuration \
'ObjectLockEnabled=Enabled,Rule={DefaultRetention={Mode=GOVERNANCE,Days=90}}'
Set retention windows longer than your longest restore window plus a buffer. Thirty days minimum; ninety is safer. Governance mode lets you delete with explicit approval; compliance mode doesn't, even for the root account.
If you're running purely on-premises, physically separate at least one backup copy. An attacker who compromises your hypervisor or SAN can still reach backups on the same network. Tape, removable drives, or a second site with strict firewall rules all work.
Step 2: Isolate Backup Infrastructure from Production Networks
Your backup servers should not trust production. Period.
Place backup storage on a separate VLAN with strict firewall rules. Only the backup agent should initiate connections to the repository—never the reverse. If your backup server lives in the same flat network as file servers and endpoints, an attacker pivoting laterally will find it.
# iptables example: allow only backup server to initiate to production
iptables -A INPUT -i eth1 -s 10.20.30.40 -p tcp --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -i eth1 -m state --state ESTABLISHED -j ACCEPT
iptables -A INPUT -i eth1 -j DROP
Disable RDP and SSH on backup appliances entirely if possible; use console or dedicated management networks instead. Change default service accounts and disable any credentials stored in plain text on production clients.
Air-gapped copies—backups physically disconnected from the network—are your last line. Rotate external drives weekly or use tape libraries with media you eject and store offsite. Yes, tape still matters in 2026 for exactly this reason.
How Do You Know the Backups Are Actually Restorable?
You test them. Every month.
Schedule a full restore drill to an isolated recovery environment. Pick a critical system—your main database, file server, or email stack—and restore it completely to a quarantined VM or physical host. Boot it, verify services start, and confirm data integrity.
# Example: restore PostgreSQL from a backup and verify
pg_restore -U postgres -d test_restore /backup/prod_db.dump
psql -U postgres -d test_restore -c "SELECT COUNT(*) FROM users;"
Document the time it takes and the steps that broke. I've seen teams assume a restore would take four hours only to discover it needed sixteen because nobody accounted for database index rebuilds. Record the actual duration and add 50% as your real RTO.
Automate verification where you can. Many backup platforms support automated boot tests: they restore a VM snapshot, power it on in isolation, check for a heartbeat, then tear it down. Schedule these weekly for your top ten systems.
Step 3: Validate Backup Integrity with Hash Checks and Logs
A successful backup job doesn't mean the data is usable. Check integrity separately.
Most backup software calculates checksums during writes. Enable verification on every backup cycle—it adds overhead but catches bit rot and incomplete transfers immediately. Configure your platform to re-read a random sample of blocks after writing and compare hashes.
# Example: verify file integrity with sha256sum after backup
sha256sum /backup/data.tar.gz > /backup/data.tar.gz.sha256
sha256sum -c /backup/data.tar.gz.sha256
Review backup logs daily. Don't rely on email alerts alone—attackers disable those. Export logs to a separate SIEM or syslog server that production systems can't reach. Flag any "partial success" or "completed with warnings" as failures until you investigate.
Test random file restores weekly. Pull a handful of files from last night's backup and open them. If you're backing up databases, restore a single table to a scratch instance and query it.
Step 4: Implement Versioning and Retain Multiple Snapshots
Ransomware often sits dormant for days or weeks, encrypting files slowly or waiting for maximum impact. A single backup generation won't save you if the malware was active before the snapshot.
Keep incremental backups going back at least thirty days. Retain full snapshots at weekly and monthly intervals for at least six months. This gives you clean restore points predating the initial compromise.
# Example: rotate daily backups, keep weeklies, monthlies
# Day 1-7: daily incrementals
# Week 1-4: weekly fulls
# Month 1-6: monthly fulls
When an incident hits, you'll compare file hashes or modification timestamps across snapshots to pinpoint when encryption started. The more versions you keep, the easier that becomes.
Configure alerts for unusual backup size changes. A sudden 30% increase or decrease often signals mass encryption or deletion. Automate this with a simple script that compares today's backup size to the rolling seven-day average.
Step 5: Document and Rehearse the Full Recovery Workflow
Write down every step from "we're locked out" to "production is back online." Not a high-level runbook—actual commands, file paths, and decision trees.
Your recovery plan should include:
- Who declares an incident and authorizes recovery
- How to access air-gapped or offline backup media
- The sequence to restore systems (databases first, app servers second, front-ends last)
- Validation checks after each restore
- Communication templates for leadership and users
Store this document in three places: your internal wiki, a printed binder in the NOC, and a USB drive locked in a manager's desk. Ransomware will take down your wiki.
# Example recovery checklist snippet
1. Power off all affected systems to contain spread
2. Retrieve offsite backup drive from safe
3. Boot recovery jumpbox from clean ISO
4. Mount backup volume read-only
5. Verify backup hashes before extraction
6. Restore in order: DB primary, DB replica, app tier, web tier
7. Change all service credentials before bringing systems online
8. Monitor logs for 72 hours post-restore
Run a tabletop exercise every quarter. Gather your team, simulate an incident, and walk through the plan step by step. Time how long decisions take when people are stressed.
Step 6: Separate Backup Credentials and Rotate Them
If an attacker gets domain admin or root, they shouldn't automatically own your backups.
Use dedicated service accounts for backup operations with no other privileges. Store credentials in a password manager or vault outside the domain, and require MFA for access. Rotate backup account passwords every ninety days at minimum.
# Example: create a dedicated backup user with limited scope (Linux)
useradd -r -s /bin/false backup_agent
chown backup_agent:backup_agent /var/backups
chmod 700 /var/backups
For cloud backups, use IAM roles with write-only permissions to the backup bucket and a separate read role for restores that requires MFA. An attacker who compromises your AWS key can't delete backups if the key lacks delete permissions.
Never store backup credentials on the systems being backed up. I've seen ransomware scrape saved RDP sessions and password files, then use those credentials to corrupt the backup repository.
Step 7: Monitor for Ransomware Indicators Before Encryption Starts
Recovery is your last resort. Catching ransomware before it locks your files is better.
Configure alerts for:
- Mass file modifications (>1,000 files changed in under a minute)
- Unusual file extensions appearing (.locked, .encrypted, or randomized strings)
- Processes making network connections to known C2 infrastructure
- Privilege escalation attempts or new scheduled tasks
- Backup service failures or stopped agents
Modern EDR platforms flag many of these automatically, but you can build basic detection with open-source tools. OSSEC, Wazuh, or even a well-tuned rsyslog pipeline can catch behavioral anomalies.
# Example: simple inotify script to alert on mass file changes
inotifywait -m -r -e modify /var/www | while read path action file; do
count=$(find /var/www -mmin -1 -type f | wc -l)
if [ $count -gt 1000 ]; then
echo "ALERT: $count files modified in 1 minute" | mail -s "Possible ransomware" [email protected]
fi
done
Enable verbose logging on file servers, especially for SMB and NFS shares. Attackers often encrypt network shares first because they affect the most users. Catch that early and you can isolate systems before production databases get hit.
Can I use cloud snapshots as my only backup?
No. Cloud snapshots are convenient but they live in the same account an attacker can access with compromised credentials. Use snapshots for quick rollbacks, but pair them with immutable object storage or offsite backups for ransomware resilience.
How long should I keep backups?
Thirty days minimum for incrementals, six months for monthly fulls. Compliance requirements might push that to seven years for certain data. The longer you keep them, the better your chances of finding a clean restore point.
What if ransomware encrypted my backups too?
If you followed step one and enabled immutability, that's not possible. If you didn't, your options narrow to negotiating, restoring from even older backups if they exist, or rebuilding from scratch. This is why immutability isn't optional.
Should I pay the ransom to speed up recovery?
That's a business decision, not a technical one. Paying doesn't guarantee decryption, and it funds future attacks. If your backup strategy works, you shouldn't need to pay. If it doesn't, rebuilding is often faster than waiting for a decryption key that might not arrive.
What to Check After You've Built Your Strategy
Once you've implemented these steps, audit the whole chain monthly. Verify immutability settings haven't been changed, test a restore end-to-end, confirm logs are still flowing to your SIEM, and rotate credentials. Recovery works when you've practiced it so many times that the actual incident feels like another drill.
Your backup infrastructure is the last thing standing between a bad Tuesday and a company-ending event. Treat it that way.