"We have backups" is one of the most common things said during a ransomware incident, and one of the most often disappointed. Typical stories: the backup server was joined to the same domain, so once the attackers had domain admin they simply wiped it; the backups lived on an always-connected NAS and were encrypted along with everything else; or the backups were all there but had never been tested, and the real restore turned out to take days and was missing critical configuration. Attackers deliberately delete shadow copies, backup catalogs, VM snapshots and cloud backups precisely so that paying becomes the only way out[1].

This article explains how to design backups that still work during an attack: the 3-2-1 rule and its common extensions, offline and immutable copies, separating backup privileges from the domain, using RPO and RTO to set backup frequency, and what needs backing up besides files. For the full ransomware attack sequence, see how ransomware gets into a company.

The 3-2-1 rule and its extensions

Taiwan's Administration for Cyber Security lists 3-2-1 as a baseline measure in its basic cybersecurity guide for small and medium-sized enterprises: keep 3 copies of data, on 2 different types of storage media, with 1 copy off-site and at least 1 copy stored offline (air-gapped), and run backup drills (testing and restoring) regularly[2].

Each number protects against a different risk:

  • 3 copies: the original plus at least two backups, so if one is damaged there are still alternatives
  • 2 media types: for example a disk array plus tape or object storage, so a single kind of failure or a single vulnerability cannot destroy every copy at once
  • 1 off-site: against physical events such as fire, flood or a data centre power loss
  • At least 1 offline: against ransomware. Off-site is not the same as offline. A copy that continuously syncs to cloud storage or a second data centre can be deleted or encrypted along with everything else if it is reachable from the internal network and managed with the same accounts

The industry also talks about "3-2-1-1-0", an extension promoted by the backup vendor Veeam: on top of 3-2-1, keep 1 more copy that is immutable or air-gapped, and aim for 0 errors when restores are verified[3]. This is an industry convention rather than a formal standard, but it makes two useful points: at least one copy should be something an attacker cannot change, and you need to verify that backups actually restore.

Why backups become a target

MITRE ATT&CK treats "inhibit system recovery" as a technique in its own right. Common methods include using built-in tools to delete shadow copies and the Windows backup catalog, disabling automatic recovery, deleting or encrypting ESXi virtual machine snapshots, and, in cloud environments, turning off versioning and deleting snapshots and backup policies[1]. CISA's #StopRansomware Guide also notes that many ransomware variants look for accessible backups and then delete or encrypt them, which is why its core recommendation is to keep offline, encrypted backups of critical data[4].

In other words, any backup that an ordinary user or a domain admin can reach should be assumed reachable by the attacker too. The design question is not "do we have backups?" but "could someone holding domain admin wipe every copy in one go?"

Offline, immutable and separated

Offline copies

The simplest offline copy is a set of external drives or tapes that are rotated regularly and kept disconnected. The key is that they are normally disconnected: unplug them as soon as each backup finishes, and keep at least two sets in rotation so that the one currently connected is not the only one left if encryption strikes.

Immutable copies

Immutable means that once data is written it cannot be modified or deleted during the retention period, also known as WORM (write once, read many). With Amazon S3 Object Lock in compliance mode, for example, no user can overwrite or delete a protected object version during the retention period, not even the AWS account's root user[5]. Many backup appliances and cloud backup services offer similar features. CISA advises using immutable storage with caution[4]. A retention period that is too short will not outlast an attacker who stays hidden for a while, and one that is too long builds up storage costs you cannot delete, along with any data that was stored there by mistake.

Separating backup privileges from the domain

The UK National Cyber Security Centre (NCSC) has published principles for ransomware-resistant cloud backups, and most of them apply to any backup system[6]. The key points:

  • Deleting or altering backups should require an attacker to compromise a second, separate system, not just one account
  • There should be an access route that does not depend on the main environment, so a single stolen account cannot lock the organization out of its own backups
  • Retention should be based on time rather than a number of copies, so an attacker cannot push good versions out by generating a burst of corrupted backups
  • Mass deletions, stopped backups and changes to retention or encryption settings should raise alerts whether or not they succeed, delivered through channels that still work if the main environment is compromised

For a typical company, that translates into: keep the backup server out of the production domain and give it separate accounts protected by MFA; allow the backup management console to be reached only from a management network; and keep backup encryption keys in a separate offline location.

Define RPO and RTO first

Backup frequency and architecture should follow business needs, not the software's default of "once a night". The two key metrics are defined in NIST SP 800-34:

  • RPO (recovery point objective): the point in time to which data must be recovered after an outage[7]; in other words, how much data you can afford to lose
  • RTO (recovery time objective): how long system components can remain in the recovery phase before that starts to harm the organization's mission and business processes[7]

For example, an order system might tolerate losing only 15 minutes of data and need to be back within four hours, while an internal file server might tolerate a day of data loss and a two-day recovery. Business owners should sign off on these numbers; IT then chooses backup frequency, retention and storage media to match. The Administration for Cyber Security's incident response guide likewise recommends starting from core business processes when inventorying assets and running a business impact analysis (BIA) to identify the core assets that need protecting first[8].

What to back up besides files

After a ransomware incident, what holds up recovery is often not the files themselves but what you need to rebuild the environment:

  • System images and deployment templates: CISA recommends maintaining and regularly updating "golden images" of critical systems, and if you deploy cloud resources with infrastructure as code (IaC), keeping offline backups of the template files too[4]
  • Active Directory: if every domain controller fails you need a full forest recovery; Microsoft's AD forest recovery guide is meant as a template for your own recovery plan[9]. At a minimum, have trustworthy domain controller backups and recovery steps written down in advance
  • Network and security device configuration: firewall, switch, VPN and virtualization platform configuration files and licences
  • SaaS data: under the cloud shared responsibility model, data, accounts and access management remain the customer's responsibility whether the service is IaaS, PaaS or SaaS[10]. Decide in advance how you would restore email and documents in Microsoft 365 or Google Workspace that were deleted by mistake or maliciously encrypted, and whether that requires a separate backup
  • What you need in order to recover: backup encryption keys, emergency access to the password vault, vendor and ISP contacts, and the recovery runbook should all have a copy you can reach without the company network

Restore drills: an untested backup is not a backup

CISA recommends regularly testing the availability and integrity of backups in a disaster recovery scenario[4], and the Administration for Cyber Security's SME guide likewise calls for regular backup drills[2]. Drills can be tiered by how important each system is, for example:

  • Routine spot checks: restore a few random files and one database and confirm the contents are correct and open properly
  • Periodic full restores: fully restore a critical server into an isolated network segment, record how long it actually took, and compare that with the RTO
  • Scenario exercises: assume the domain, DNS and internal file servers are all unavailable, rebuild core services using only offline or immutable copies, and find the dependency problems in your recovery order

During a real incident, confirm that backups are clean before restoring them. The Administration for Cyber Security recommends running an independent malware scan of backup images before any restore, and loading data only into environments that have already been cleaned and rebuilt once the backups are confirmed safe[8], so that you do not restore a dormant ransomware binary or attacker scripts along with your data.

Action checklist

  1. List every backup job: what it covers, how often it runs, where it is stored and who can delete it. Identify the systems that have no offline or immutable copy at all.
  2. Check whether backup servers and backup storage are joined to the production domain or can be logged into with domain admin credentials; move them to separate accounts with MFA.
  3. Enable immutable retention or offline rotation for at least one copy, with a retention period that covers the longest time you expect an intrusion could go unnoticed.
  4. Set up alerts for backup failures, mass deletions and changes to retention policies, delivered through a channel that does not depend on company email.
  5. Agree RPO and RTO for core systems with business owners and check whether current backup frequency meets them.
  6. Confirm that AD, network device configuration, SaaS data and backup encryption keys are all backed up, and that the keys have an offline copy.
  7. Run a full restore drill this quarter, record the actual time taken and where you got stuck, and update the recovery runbook.
  8. Keep a separate copy of the recovery steps, emergency contacts and how to obtain critical credentials somewhere you can reach even when the company network is down.