Backups that survive ransomware: the 3-2-1-1 rule

Why ordinary backups fail

Many businesses discover during an incident that their backups were connected to the same network, used the same administrator password, or had not completed successfully for months. Attackers who gain administrator access often spend days exploring a network before launching ransomware. During that time they look for backup servers, delete snapshots and encrypt the backup files along with everything else.

A backup that the attacker can reach is not a reliable backup. The goal is to keep at least one copy that cannot be changed or deleted, even by someone holding your administrator credentials. That usually means separate credentials, separate systems and a copy that sits outside the reach of your normal network.

The 3-2-1-1 rule explained

The classic 3-2-1 rule calls for three copies of your data, on two different types of storage, with one copy kept offsite. It protects against hardware failure, fire and theft. The extra 1 addresses ransomware: one copy must be immutable or offline. Immutable storage locks backup data for a set period so it cannot be altered or deleted. Offline means physically disconnected, such as rotated drives or tape.

Many cloud backup services offer immutability as a setting. Make sure it is actually enabled and that the retention period is long enough to cover an attacker who stayed hidden for weeks. Thirty days is a common minimum, and longer retention for monthly copies gives you more options if problems are found late.

• 3 copies of your data
• 2 different types of storage
• 1 copy offsite
• 1 copy immutable or offline

Do not forget cloud data

Microsoft 365 and Google Workspace keep your data available, but their built-in retention is not the same as a backup you control. Deleted items age out, and a compromised account can delete or encrypt synced files. A third-party backup of email, OneDrive, SharePoint and Teams gives you independent, point-in-time copies and makes restoring a single mailbox or folder straightforward.

The same thinking applies to line-of-business applications hosted by vendors. Ask how they back up your data, how long they keep it, and how you would get a copy if the vendor itself had an incident. Many vendors will provide a scheduled export if asked, which you can include in your own backup routine.

Separate the keys

Backup systems should have their own credentials that are not used anywhere else and are protected with MFA. Avoid joining backup servers to the main Windows domain where possible, because a compromised domain administrator account would then control them too. Limit who can change retention settings or delete backup sets, and set alerts for those actions.

Encrypt backups at rest and in transit, and store the encryption keys somewhere safe and separate. A backup you cannot decrypt during a crisis is no better than no backup at all. Record where the keys are kept in your incident response plan, and make sure at least two trusted people can retrieve them.

Test restores, not just backups

A green tick on a backup report only tells you a job finished. It does not tell you the data can be restored, or how long that takes. Schedule regular restore tests: a single file monthly, a full server or key application at least a few times a year. Time the full restore and compare it with how long the business can tolerate being down.

Write the restore steps down, including where credentials are kept and who to call. During a real incident, the person who set up the backups may not be available. Keep a printed or offline copy of the instructions, because your documentation system may be one of the things that is down. Review the steps after every test so they stay accurate.