Backups that survive ransomware: 3-2-1 rule, immutable copies and tests

Why many backups do not survive a ransomware attack

Modern ransomware attacks rarely start with encryption. Attackers often obtain administrator rights first and then hunt for backups to delete or encrypt them as well. A backup that sits on the same network and can be reached with the same admin account is lost together with the production data.

For a backup to survive such an attack and still be restorable afterwards, three things are needed: at least one copy is offline or immutable, the backup environment has its own separate credentials, and the restore has demonstrably been tested. Our article on ransomware: the first 24 hours covers what to do during an incident. This article is about preparation.

The 3-2-1 rule and the 3-2-1-1-0 extension

The 3-2-1 rule has been the foundation of backup strategies for many years. It spreads the risk so that a single hardware fault, a fire or a user error cannot hit every copy at once. On its own it is no longer enough against ransomware, because the external copy is often reachable online too, which is why the 3-2-1-1-0 extension is now widely recommended.

The second 1 is the decisive one. An external copy in the cloud is of little help if the attacker can delete it with stolen credentials just as easily as the local one. In practice, a single copy often meets both requirements: an external backup that is also immutable.

The protected copy: offline or immutable, with its own access

Offline copy

An offline copy is physically disconnected from the network, for example a removable drive unplugged after the backup or a tape taken out of the drive. This is also called an air gap. It cannot be reached over the network, but it requires discipline: someone has to rotate, label and store the media off site reliably. For smaller businesses this is often a good, low-cost starting point.

Immutable copy

With an immutable backup the storage stays online, but every backup is locked against changes and deletion for a defined period. Typical options are S3-compatible object storage with Object Lock or hardened backup repositories. What matters is that the lock cannot be lifted early, not even with administrator rights. Check whether your provider offers such a strict mode and whether it is switched on.

Separate credentials for the backup environment

Many backups fail not because of the technology but because of the credentials. If the domain admin account also opens the backup console, a single stolen account is enough to destroy data and backups at the same time. Keep the backup environment strictly separate from the rest of your IT:

• Use dedicated backup admin accounts that are outside the Windows domain and protected with multi-factor authentication.
• Where possible, do not join the backup server to the domain, and allow only the network connections it actually needs.
• Store the key for encrypted backups separately, for example in the password manager and on paper in a safe. Without it, even a careful backup is worthless.
• Turn on alerts for deleted backups, shortened retention periods and disabled jobs.

RPO and RTO: how much data loss and downtime is acceptable

Two figures help you choose a suitable solution. The RPO (recovery point objective) is the maximum data loss you can accept, measured in time. If the backup runs once a night, up to 24 hours of work can be lost. If that is too much, back up more often, for example several times a day. The RTO (recovery time objective) is the maximum time a system may be down.

Set both values per system together with management rather than across the board. Accounting may tolerate a day of downtime, while the till system or order processing may manage only a few hours. Restoring large amounts of data from the cloud can also take a long time, depending on bandwidth. A local copy for fast restores plus a protected external copy is therefore often the sensible combination.

What to back up: more than the file server

Important data often lives outside the classic server too. These areas belong in the backup concept:

• Servers and virtual machines: file servers, databases, ERP, accounting and application servers, ideally as a complete image.
• Microsoft 365: Exchange mailboxes, OneDrive, SharePoint and Teams files. Microsoft runs the platform, but protecting your data against deletion, encryption or user error remains your responsibility. More in our article on securing Microsoft 365.
• NAS systems: they often hold important data themselves and then need their own backup to another system.
• Network and security devices: configurations of firewalls, switches, Wi-Fi controllers and video recorders. Without them, rebuilding takes considerably longer.
• Documentation: network diagrams, the emergency handbook and restore instructions, also kept offline or printed.

Test and document restores

A backup that has never been restored is an assumption. Only a test shows whether the data is complete, the key works and the restore succeeds within the planned time. A simple test plan can look like this:

1. Every month, restore individual files, folders and one mailbox.
2. Every quarter, restore a complete server into an isolated test environment and compare the time needed with the RTO.
3. Check backup reports daily or have them evaluated automatically, and follow up on every warning.
4. Briefly record the result, duration and any problems of each test.
5. Update the restore instructions after every change and keep a copy outside the IT systems.

Common mistakes and how to avoid them

• Backup on the same NAS: if data and backup sit on one device, a fault or encryption takes out both. NAS snapshots are useful but do not replace a separate copy.
• USB drive that is always connected: it is encrypted along with everything else in an attack.
• Never tested: failed jobs, missing data or a lost key otherwise only surface in an emergency.
• Retention too short: attackers often stay undetected for some time. Keep several generations over a number of weeks so that a clean state is available.
• Ignored warnings: a job that has been failing for weeks goes unnoticed without regular checks.

Conclusion: a backup is only finished when the restore works

A backup that survives ransomware is not a single product but the combination of 3-2-1-1-0, separate credentials, clear RPO and RTO values and regular tests. If you would like to review your existing concept or set up a new one, Q-entra supports you as part of cyber security. With managed security, we can also take over ongoing backup checks and restore tests.