How to Protect Backups from Ransomware

Backups are one of the most important ransomware recovery controls, but simply having a backup job is not enough. Modern attacks may search for connected drives, shared folders, backup consoles and administrator credentials before encrypting or deleting recovery copies.

CISA recommends maintaining offline, encrypted backups of critical data and regularly testing their availability and integrity in a disaster-recovery scenario. The goal is not merely to create copies, but to keep at least one trustworthy copy outside the attacker’s reach.

Build several layers of recovery

Control	Risk reduced	Practical action
Version history	Encrypted or overwritten files replacing good copies	Retain multiple recovery points
Offline copy	Ransomware reaching connected storage	Disconnect or isolate a backup after completion
Immutable storage	Attackers deleting or altering backups	Use retention locks where supported
Separate credentials	One stolen account controlling production and backup	Use unique admin accounts and MFA
Restore testing	Discovering corruption or gaps during an incident	Test representative files and systems

Keep one copy offline or immutable

An offline backup is not reachable from the protected environment when it is not being written. Immutability prevents stored recovery points from being changed or deleted for a defined period. These controls address different operational needs but share the same purpose: preserving a copy that compromised production credentials cannot destroy.

Separate backup administration

Do not use the same everyday administrator account everywhere. Protect backup-console accounts with unique credentials and multi-factor authentication, restrict who can change retention or delete repositories, and record administrative events. Businesses should ensure recovery contacts and procedures remain available if normal identity systems are offline.

Use retention that predates detection

Ransomware may remain unnoticed before files are encrypted. A very short history can leave only damaged versions by the time the incident is discovered. Retention should cover plausible detection delays and the time needed to investigate. Our provider reviews explain how version history differs between services.

Monitor for backup failures

• Investigate missed jobs and disconnected devices.
• Alert on unexpected deletion or retention changes.
• Confirm newly added folders and workloads are protected.
• Track capacity so backups do not stop silently.
• Review administrator and recovery-account activity.

Test recovery, not just backup completion

A green status indicator confirms that a job ran; it does not prove the right data can be restored within the required time. Test a sample of documents, a larger folder and—where applicable—a complete system or application recovery. Record the result, duration and any missing dependencies.

What to do during an incident

Do not immediately reconnect every backup to an infected network. Isolate affected systems, preserve evidence where appropriate, determine the likely infection window and identify a clean recovery point. Businesses should follow their incident-response plan and obtain specialist help where necessary.

For provider choices with historical recovery features, see our best cloud backup for small business guide and IDrive vs Acronis comparison.

Continue learning: build independent copies with the 3-2-1 backup rule and verify them with a planned restore test.

Sources and further reading

• CISA: StopRansomware Guide
• NIST: Protecting Data from Ransomware and Other Data Loss Events