Backups that survive ransomware: the 3-2-1-1-0 rule, immutable storage and restore testing

A backup protects you from ransomware if an intruder already inside the network cannot wipe or encrypt it, and if it can be restored before the outage does damage the business cannot absorb. Industry surveys show the first condition often fails. Whether the second holds is only known once someone has timed a restore.

Sophos's State of Ransomware 2024 survey found that 94% of organisations hit by ransomware had seen attackers try to compromise their backups, and that 57% of those attempts succeeded. Its analysis of compromised backups compares victims whose backups were compromised with those whose backups survived. The first group faced a median initial ransom demand of $2.3 million, against $1 million, and paid in 67% of cases, against 36%. Their median recovery cost was eight times higher.

Why do ransomware attacks go after backups first?

Ransomware operators go after backups first because a victim who can restore has little reason to pay for a decryptor. That would leave the threat of leaking stolen data as their only leverage.

A common sequence runs through stolen domain admin credentials. If the backup server is joined to that domain, the same credentials open its console, and the intruder uses them to delete jobs, shorten retention and remove restore points before triggering encryption. MITRE ATT&CK lists this stage as T1490, Inhibit System Recovery, with commands such as vssadmin.exe delete shadows /all /quiet, wbadmin delete catalog -quiet or, on ESXi hosts, vim-cmd vmsvc/snapshot.removeall. Because these are legitimate system tools, spotting their abuse means watching for them running out of context, which our guide to detecting living-off-the-land binaries covers.

Attackers also go after the backup software. As of 1 October 2026, CISA's Known Exploited Vulnerabilities (KEV) catalogue lists four Veeam Backup & Replication flaws exploited in ransomware campaigns. The two most recent are these:

• CVE-2023-27532 exposed the encrypted credentials stored in the configuration database. BlackBerry saw the Cuba group exploit it in 2023. WithSecure linked several attacks that year on exposed Veeam servers to FIN7, or an actor borrowing its tradecraft, and assessed with low-to-medium confidence that this flaw was the way in.
• CVE-2024-40711 allowed unauthenticated remote code execution and is scored 9.8 on CVSS. Sophos X-Ops found it in Akira and Fog attacks whose operators had come in through VPN gateways without multi-factor authentication.

There is little time to catch an intruder before they reach the backups. Sophos's Active Adversary Report 2026, covering cases from November 2024 to October 2025, put the median dwell time at three days and the median time before attackers went after Active Directory at 3.4 hours. Mandiant's M-Trends 2025 gave a six-day median for ransomware-related intrusions, and 29 days when the organisation found the intrusion itself.

Veeam's 2025 report, From Risk to Resilience, found that attackers targeted backup repositories at 89% of the organisations attacked and modified or deleted 34% of those repositories on average, as Veeam summarises on its blog.

What is the 3-2-1-1-0 backup rule?

The 3-2-1-1-0 backup rule extends the 3-2-1 rule with one immutable or offline copy and a requirement of zero errors when restores are verified. Veeam popularised it and explains it in its article on the 3-2-1 backup rule. None of the frameworks covered in this guide mentions it, and ENISA's technical guidance cites only 3-2-1.

The photographer Peter Krogh coined the original 3-2-1 in the first edition of The DAM Book, published in 2005, as he recounted on the Backup Wrap-Up podcast. Keeping several copies, one of them off site, was long-standing advice; Krogh gave it the name that stuck.

Each digit maps to a requirement:

• 3: three copies of the data, counting the production copy.
• 2: two different types of storage, so a single fault cannot take out every copy.
• 1: one copy off site.
• 1: one copy that is immutable or offline (air-gapped).
• 0: zero errors when restores are verified.

The last two requirements were added with ransomware in mind. An immutable copy is still reachable over the network, but the system holding it refuses any change or removal during the retention period. An offline copy, such as a tape removed from the library, is out of reach for whoever controls the network.

Both options have drawbacks. Restoring from tape is slow. As for immutability, CISA's #StopRansomware Guide says to "use immutable storage with caution", because it does not meet the compliance criteria for certain regulations and a misconfiguration can prove expensive.

How do you set up immutable backups on S3, Azure, Linux and NAS?

You set up an immutable backup by applying a retention lock that not even an administrator can lift before it expires, configured so that an attacker with privileges cannot relax it afterwards. Each platform does this differently: Object Lock on Amazon S3, locked policies on Azure, Veeam's Hardened Repository on Linux and WORM folders or immutable snapshots on NAS devices. Our glossary entry on immutable backup has the full definition.

Cloud object storage

On Amazon S3, immutability comes from Object Lock, which requires bucket versioning and offers two modes. In compliance mode no user, the root user included, can overwrite or erase an object or shorten its retention before it expires. The only way out is to close the AWS account.

Governance mode offers far less protection. Any principal holding s3:BypassGovernanceRetention can override the lock, and the AWS console includes the bypass header by default. Against an attacker with privileges in the account only compliance mode holds, and only if they cannot also disable or delete the AWS KMS keys that encrypt the objects. Disabling takes effect at once, while deletion involves a waiting period of 7 to 30 days, which leaves time to react if scheduled deletions trigger an alert.

Azure Blob Storage uses immutability policies that are either locked or unlocked, and unlocked policies can be shortened or deleted. Microsoft recommends locking them, typically within 24 hours of setting them up. Once locked, retention can only be extended.

Linux backup repositories

Veeam's Hardened Repository keeps backups on a Linux server, usually on XFS, the file system Veeam recommends, and marks the files immutable through file-system attributes. It uses single-use credentials that are not stored on the backup server, so compromising the console does not give an attacker a way to delete backups.

Veeam's best-practice guide is clear about the limits of this design. It calls for SSH to be disabled and sudo rights removed after deployment, and warns that anyone with physical access to the machine could still compromise it. Out-of-band management interfaces such as iDRAC or iLO give equivalent access and need a dedicated network and credentials of their own.

NAS devices and tape

On supported models, Synology offers immutable snapshots on Btrfs volumes and WORM folders through its WriteOnce feature. According to Synology's documentation, those snapshots cannot be removed by any means during the protection period. QNAP has WORM folders in two modes, and only compliance mode prevents the shared folder from being deleted, although an administrator can still remove the storage pool that holds it.

Whatever the vendor, the NAS admin interface should not face the internet or share credentials with the domain. Whoever controls it can at least stop new backups being taken.

Tape taken out of the library remains the hardest copy to reach from the network. The price is restore time, which needs measuring in a test before you depend on it.

What retention period do immutable backups need?

Immutable backups need a retention period longer than an intruder can stay inside undetected, plus the time it takes to realise that recent backups were already tainted. Published medians are three days across all of Sophos's cases and six days for the ransomware-related intrusions Mandiant investigated. The distribution has a long tail, though: in Mandiant's data only 56.5% of those intrusions lasted a week or less, and those the victim organisation detected itself had a median of 29 days.

Synology, for one, recommends protection periods of 7 to 14 days for its snapshots. Given the data above, we think seven days is too short for critical systems. Our starting recommendation is at least one immutable backup set covering a month, and longer if detection is slow. Storage cost sets the upper limit. Because a misconfigured retention period in compliance mode cannot be shortened, trial the first setup in a test bucket with short periods.

How should backup infrastructure be isolated from the domain?

Backup infrastructure should be treated as a Tier 0 system, with the level of protection that Active Directory tiering reserves for domain controllers. That means taking it out of the production domain, protecting it with separate credentials and MFA, placing it on its own network segment and leaving no standing remote access. Mandiant's M-Trends 2026 explicitly recommends removing hypervisors and backup infrastructure from the corporate Active Directory domain.

Veeam's CVE-2025-23120, scored 9.9 on CVSS, illustrates the risk. It let an authenticated domain user run code, but according to Veeam's advisory it only affected domain-joined backup servers. In October 2025 Veeam fixed two more flaws, also scored 9.9, with the same restriction to domain users and domain-joined machines. They are CVE-2025-48984, on the backup server, and CVE-2025-48983, in the Mount service on backup infrastructure hosts. As of 1 October 2026, none of the three was in the KEV catalogue.

These are the measures we check on every backup platform review:

• Backup server and repositories outside the production Active Directory, or in a separate management forest.
• Dedicated console accounts that do not reuse domain passwords, protected by MFA, in line with least privilege.
• A dedicated network segment, open only on the ports the agents need, with no console access from the user network; our piece on internal network segmentation goes into the design.
• No permanently open RDP or SSH, and out-of-band management on an isolated admin network.
• Top-priority patching for the backup software, since its flaws appear in CISA's KEV catalogue.
• Backup encryption secrets stored separately from the backup data, as ENISA recommends.
• Alerts on deleted jobs, retention changes or mass deletion of restore points, reaching someone who is watching at night. In Sophos's 2026 report, 88% of the ransomware analysed was deployed outside business hours.

If nobody answers those alerts in the small hours, a managed SOC closes the gap.

How often should you test restores?

Restores should be tested as often as the criticality of the data demands and whenever the infrastructure changes. As a benchmark, ENISA's technical guidance for NIS2 gives the example of checking backups weekly for high-criticality data, monthly for medium- or low-criticality data and immediately after any significant change.

Testing is the zero in 3-2-1-1-0 and, from what we see in audits, the step most often neglected. A backup job that finishes without errors only shows that data was copied. In the same Veeam report, just 28% of respondents restored data to an isolated "sandbox" environment and scanned it for integrity, while 39% had to restore straight into production, at the risk of bringing the attacker back.

A useful test covers these steps, in this order:

1. Set an RTO (how long each service can be down) and an RPO (how much data it can lose) as part of the disaster recovery plan.
2. Restore into an environment separated from production, never on top of it.
3. Scan what you restored for persistence, because the backup was taken while the attacker may have been inside.
4. Bring identity back first (Active Directory and DNS), then databases and finally applications.
5. Time the whole exercise, compare it with the RTO and record what had to be fixed.

Active Directory is rehearsed separately. Microsoft's AD forest recovery guide asks for regular backups of at least two writeable domain controllers per domain and says to start with the forest root domain. A backup of a read-only domain controller cannot be used to restore a writeable one. The guide also warns that it does not cover security recommendations for recovering a forest that has been hacked or compromised. After a ransomware attack, choosing a clean restore point takes digital forensics and an incident response plan that allows for it.

What do ENS, ISO 27001, NIS2 and DORA require for backups?

ENS, ISO 27001, NIS2 and DORA all require backups, and most also require restore testing, but none of them explicitly requires immutability. ENS requires testing only from medium level. Under NIS2, the explicit testing duty sits in an implementing regulation that covers only certain digital providers.

• ENS, Spain's National Security Framework (Royal Decree 311/2022), measure mp.info.6. It applies according to the level of the availability dimension, not the system category. From medium level, reinforcement R1 requires regular testing of backup and restore. At high level, R2 requires at least one copy stored separately in a different place, so that a single incident cannot hit both the original and the copy. We check this measure on every ENS compliance project.
• ISO/IEC 27001:2022, control A.8.13. Backups of information, software and systems must be maintained and regularly tested in line with a topic-specific backup policy. Auditors on ISO 27001 engagements ask for evidence of it.
• NIS2, Article 21(2)(c). It names backup management and disaster recovery as part of business continuity. Implementing Regulation (EU) 2024/2690 adds copies kept outside the system's network, integrity checks and documented recovery tests, but only for a closed list of digital providers that includes cloud, data centre, managed service and managed security service providers. ENISA's technical guidance suggests the 3-2-1 rule and mentions immutable or offline backups. For where Spain stands, see our analysis of NIS2 without a national transposition law.
• DORA, Article 12. Financial entities must test backup, restoration and recovery periodically and check data integrity after a recovery. When they restore data with their own systems, those systems must be physically and logically separated from the source. More on our DORA page.

To evidence the separate copy that ENS (at high level) and the NIS2 implementing regulation call for, the simplest route is usually an immutable or offline copy kept at another site. What audits most often find missing is the record of restore tests.

Checklist: are your backups protected from ransomware?

Seven questions to answer in an afternoon to see whether your backups would survive an attack:

• Is there at least one copy a domain admin cannot delete or shorten?
• Are the backup server and repositories outside the production domain?
• Does the backup console require MFA and use accounts that do not exist in Active Directory?
• Does immutable retention cover more days than it would take you to spot an intrusion?
• Is the backup software up to date with published security patches?
• When did you last run a full restore in an isolated environment, and how long did it take?
• Would an alert fire at night if someone deleted jobs or restore points?

Each "no" or "not sure" points to something to fix. If an attack is already under way, our guide on what to do when you have been hacked covers the first hours. To design or review the platform, our business continuity and disaster recovery service covers backup strategy and testing. Our systems hardening service deals with the servers and repositories.

This article is for guidance only. The configurations described are taken from public AWS, Microsoft, Veeam, Synology and QNAP documentation as of 1 October 2026 and may change with new releases. Survey figures belong to the editions cited. Test any immutable retention policy in a non-production environment first, because in compliance mode it cannot be undone.