Problems & fixes · Backup and recovery
Why backups fail when you need them and how to make them ransomware-resilient
Last updated 25 October 2026 · 2 sources listed · Reading time about 3 minutes
Short answer
Backups fail in predictable ways: attackers delete or encrypt them using stolen administrator access, jobs fail silently, restores are slow or incomplete, and keys or documentation are missing. Resilience comes from isolated or immutable copies, separate credentials, monitored jobs, regular restore tests and a rehearsed rebuild order that includes identity services.
Who this is for: An administrator who has backups running but is unsure they would survive a ransomware attack or restore cleanly under pressure.
What to evaluate
Credential separation
If backup systems accept the same administrator accounts as production, one stolen credential reaches both.
How to check: Confirm backup administration uses separate accounts with strong multi-factor authentication.
Immutable or offline copy
Attackers specifically look for and destroy backup repositories before triggering encryption.
How to check: Verify at least one copy cannot be modified or deleted from the production network.
Verified restorability
Corrupt, incomplete or application-inconsistent backups only reveal themselves in a restore.
How to check: Perform scheduled restores, including full-system and application-level, and record results.
Clean restore process
Restoring infected systems reintroduces the attacker.
How to check: Define how you confirm a restore point predates compromise and how systems are scanned and credentials reset.
Dependencies for rebuilding
Restoring applications needs identity, DNS, network configuration and encryption keys to be available first.
How to check: Store recovery documents, configuration backups and keys somewhere reachable when production is down.
Comparison
| Failure mode | Cause | Countermeasure |
|---|---|---|
| Backups deleted by attacker | Shared administrator credentials and reachable repositories | Separate credentials, immutability and offline copy |
| Jobs silently failing | No alerting or ignored reports | Monitored alerts and regular review with ownership |
| Restore takes far longer than expected | Untested process and bandwidth limits | Timed restore tests and local copies for large systems |
| Restored application does not work | Inconsistent database or missing dependencies | Application-aware backups and documented rebuild order |
| Encrypted backups unreadable | Lost or inaccessible encryption keys | Key escrow in a separate protected location with tested retrieval |
Decision worksheet
Rate up to three options against this guide’s own criteria. It runs in your browser and saves only on this device. It is a thinking aid, not a recommendation.
1. Have you checked each criterion?
0 of 5 criteria checked.
2. Compare options (0 = fails or unknown, 3 = meets it well)
| Criterion | |||
|---|---|---|---|
| Credential separation | |||
| Immutable or offline copy | |||
| Verified restorability | |||
| Clean restore process | |||
| Dependencies for rebuilding | |||
| Total (max 15) | 0 | 0 | 0 |
Questions to ask before you commit
- Can anyone with production domain administrator access delete or modify our backups?
- Which backup copy would survive if every system on the network were encrypted?
- When did we last restore each critical system and how long did it take?
- Where are recovery documentation and encryption keys kept if our systems are down?
- How would we know a restore point is free of the attacker's tools?
- Who is authorised to make recovery decisions during an incident?
- Do we have offline contact details for responders and key suppliers?
Typical trade-offs
Offline copies versus convenience and speed
- Upside
- Offline copies are beyond the reach of network attackers.
- Downside
- Require discipline to refresh and are slower to restore.
Restoring quickly versus verifying cleanliness
- Upside
- Speed limits business disruption.
- Downside
- Skipping verification risks reinfection and a second outage.
Detailed retention versus protection of privacy obligations
- Upside
- Longer history improves recovery options.
- Downside
- Holds personal data beyond business need, which may conflict with data protection duties.
Common mistakes
- Joining backup servers to the production directory with the same administrator accounts.
- Assuming success because jobs show green. Run actual restores and open the restored data.
- Storing recovery instructions and keys only on systems that will be unavailable during an incident.
- Restoring directly over compromised systems. Rebuild or validate first, and reset credentials.
- Never rehearsing. The first time you restore at scale should not be during an attack.
Related questions
How do attackers target backups?
They look for backup servers, consoles and storage with stolen administrator credentials, then delete, encrypt or corrupt copies before launching the main attack so that recovery fails and pressure rises. They may also steal backup data for extortion. Defence relies on isolation: separate credentials, strong authentication, immutable storage, network restrictions on backup systems and monitoring for unusual backup deletions or configuration changes. Government ransomware guidance highlights offline, tested backups.
What should a restore test include?
Select a representative sample: individual files, a mailbox, a database and a full server. Restore into an isolated environment, confirm the application starts and data is readable and consistent, record elapsed time and note every manual step or missing item. Include a scenario where the primary backup system is unavailable and you must use a secondary copy. Update documentation with what you learn and assign fixes.
How do we know a backup is clean after ransomware?
Establish when the intrusion began using logs and investigation, then select restore points before that date. Restore into an isolated network, scan with updated tools, and look for persistence mechanisms before reconnecting. Reset all credentials and rebuild identity services if they were compromised. Involve experienced responders if possible, as hasty restoration can repeat the incident.
Should we pay a ransom if backups fail?
That is a legal and business decision outside the scope of technical advice. Government agencies generally discourage payment because it offers no guarantee of recovery and encourages further attacks, and legal restrictions or reporting duties can apply depending on jurisdiction. Prepare in advance with tested backups so the decision never arises, and know in advance whom to contact, including legal counsel, law enforcement and your insurer.
Sources and further reading
These pages were reachable when we last checked. They informed definitions and rules referred to above; they do not endorse this guide. Where rules differ by country, check the authority for your location.
- StopRansomware — Cybersecurity and Infrastructure Security Agency, retrieved 27 October 2026
- Computer Security Incident Handling Guide (SP 800-61 Rev. 2) — National Institute of Standards and Technology, retrieved 27 October 2026
Related guides
How to choose · Backup and recovery
How to choose a business backup solution
Choose backup by what you must restore and how fast, then test it. Look for protection of every data source including cloud applications, immutable or offline copies that attackers cannot erase, separate credentials from your main environment, encryption, and restore testing you can actually perform. A backup that has never been restored is an assumption, not a control.
Comparison · Backup and recovery
Backup vs replication vs file sync vs snapshots
Backup keeps independent, versioned copies you can roll back to. Replication mirrors data to another site for fast failover but copies mistakes and corruption. File sync keeps files consistent across devices and also propagates deletions. Snapshots capture a point in time on the same storage and are fast but share its fate. Strong protection combines mechanisms rather than treating them as interchangeable.
Requirements · Backup and recovery
Setting recovery point and recovery time requirements
Recovery point objective is how much recent data you can afford to lose, and recovery time objective is how long a system can be unavailable. Set them per system by asking the business what an outage costs in operations, obligations and trust, then choose backup and recovery methods that meet them. Tighter objectives demand more cost and operational effort, so rank systems rather than demanding the same target for all.
Problems & fixes · Network security
Why firewall rules become unmanageable and how to fix them
Rule sprawl happens when temporary exceptions are never removed, rules lack owners and several people edit without records. It causes hidden exposure, outages when something is changed and slow audits. Fix it by documenting what exists, using hit counters and logs to identify unused rules, consolidating through objects and groups, and putting a change process in place.
Problems & fixes · B2B software
Why software implementations fail or run late and how to prevent it
Implementations falter less from technology than from unclear scope, poor data, weak ownership and underestimated change effort. Prevent trouble by defining outcomes and boundaries up front, cleaning data before migration, naming a business owner with decision authority, and planning training and adoption as seriously as configuration. When a project slips, reset scope and sequence rather than adding pressure.
Suitability · Privacy tools
Do you actually need a consumer VPN?
A consumer VPN helps in specific situations: untrusted public networks, hiding your address from sites, accessing a work network or choosing a different apparent location where legal. It does little against phishing, malware or account tracking. For many people, device updates, strong unique passwords, second-factor sign-in and HTTPS provide more protection than a VPN subscription.
Comparison · Business operations
Payment gateway versus merchant account: what each does and when you need both
A merchant account is the arrangement that lets you receive card funds into a bank account; a payment gateway is the software link that securely passes card details from checkout to the processor. Bundled providers hide the split, while unbundled setups give you more control and more paperwork. The right structure depends on volume, technical ability and how much you want to negotiate separately.