1. Introduction

When everything else fails — antivirus, patching, the human factor — one answer remains for the worst-case scenario: the backup. But a copy without immutability is a false sense of security when the attacker knows where your data lives, because 94% of ransomware attacks attempt to compromise backups and 57% succeed. Immutable backups are the difference between a restoration in days and a negotiation with the extortionist or, in the worst case, the end of the business.

In this article you will see the 3-2-1-1-0 rule explained piece by piece, what real immutability means compared with a revocable permission, the most expensive mistakes that turn a copy into a false sense of security, and the recovery protocol that follows an encryption event. It is written for executives and IT managers who want to turn the question “do we have backups?” into “do we have working backups?”.

2. The 3-2-1-1-0 Rule: The “0” That Decides

The 3-2-1 rule was born in 2012 in a document from the Software Engineering Institute at Carnegie Mellon and was popularized through professional photography. Its modern version, the one that today’s ransomware demands, is 3-2-1-1-0: at least three copies of the data, on two different types of media, one of them offsite, one additional immutable or offline copy, and ZERO errors in restoration verification.

The “0” is the piece most companies ignore, and it is the one the attacker exploits: the goal of ransomware is not only the production file, but also the copy that would let you refuse to pay. A paper RTO is systematically optimistic: a “we restore in four hours” ends up taking days when nobody has tested the process. Immutability protects you from deletion; verification protects you from surprise.

Two types of media is the detail most configurations get wrong: a NAS and a second NAS are not two media, they are one failure domain. Combine a disk repository with tape or with object storage in a different provider, and keep the recovery method for both tested. The number of copies matters less than the independence of their failure modes: when ransomware encrypts the disk repository, the tape in the safe should not even be reachable.

3. Why 94% of Attackers Target Your Copies

Modern ransomware is a business with a six-phase attack chain, and one of those phases attacks recovery directly: technique T1490 in MITRE ATT&CK (Inhibit System Recovery) covers shadow volume deletion, antivirus deactivation and, above all, locating and destroying the backup copies before encrypting. The Sophos State of Ransomware 2024 data confirms it: 94% of attacks attempted to compromise backups and 57% succeeded. If the attacker destroys the safety net too, paying stops being an option and becomes the only way out.

That is why immutable backups are not an optional improvement: they are the requirement that decides whether you will pay. Real immutability does not depend on a revocable permission — which the attacker already has if you shared administration — but on a storage configuration that not even the administrator can bypass without waiting for the retention period to expire.

4. Real Immutability: WORM by Configuration

Modern immutability is the evolution of the WORM concept (write once, read many). The mature technologies in 2026 are several: the Object Lock of Amazon S3 in Compliance mode, also available from providers such as Wasabi, Backblaze B2 or MinIO; the Veeam Hardened Repository, a hardened Linux repository with an ext4 filesystem that marks copies as immutable; and LTO tape with WORM functionality, the medium least attractive to the attacker and in practice the most resilient. Critical environments combine them with a real air gap: a copy stored outside the network that is only connected during the backup window.

The detail that separates a right decision from an apparent one is that immutability must be “by storage configuration, not by revocable permission”. If the backup administrator shares credentials with the rest of the company, the attacker has them too. Administrative separation — dedicated backup credentials, hardened MFA, monitoring of repository access — is part of the design, not decorative extras.

# Verify the immutability of an S3 bucket with Object Lock (awscli)
aws s3api get-object-lock-configuration --bucket backups-company

# List versions retained in Compliance mode (not deletable until expiration)
aws s3api list-object-versions --bucket backups-company \
  --query 'Versions[?ObjectLockMode==`COMPLIANCE`]'

# Test restoration from the immutable repository
aws s3 sync s3://backups-company/restore/2026-09-30/ /mnt/restore/

Fig. 1 – Commands to verify that an Object Lock backup is truly immutable.

5. Mistakes That Turn a Backup into a False Sense of Security

The most expensive failures are not in the technology, but in the design of the strategy:

Mistake	Consequence	Fix
Backup in the same segment as production	Encrypted together with the data	Separate network for the repository
NAS or SMB as a “backup”	It is just another disk for ransomware	Immutable repository or air gap
Shared backup-production credentials	Attacker deletes copies with your accounts	Administrative separation
Rotation failing without alerts	Copy gaps nobody notices	Automatic success and failure alerts
Short retention (14 days)	Every copy is infected	Retention beyond typical dwell time
Encryption keys next to the backup	The protection is decorative	Keys in a separate HSM or KMS
Backup never fully restored	Corrupt catalog on day D	Real restoration tests

Fig. 2 – Recurring mistakes in backup strategy and their fix.

Retention deserves an additional nuance: if the attacker stays inside the network for weeks, a 14-day retention guarantees that every copy is contaminated. The retention period must cover the known dwell times of active groups and, where possible, be combined with the offline copy as a safety belt.

The typical incident case in the book sums it up: nightly copies, logs that say “backup OK” and nobody who ever validated a complete restoration. On the day of the encryption, the catalog is corrupt, 20 terabytes are missing and “restoring” becomes a ten-day project. “We have backups” is not the same as “we have functional, tested backups”: the difference is a restoration that someone actually ran.

6. RTO and RPO: Objectives Agreed with the Business

Immutability without objectives is a guarantee without direction. The RPO (how much data loss you can afford) and the RTO (how quickly you must be operating again) are agreed with management and the business, not only with IT: an RPO of one hour on the invoicing system means a maximum loss of one hour of invoices, and that is a business decision, not a technical one. Paper RTOs are systematically optimistic; only tests measure the real one.

For critical and regulated systems — Spain’s ENS requires proven continuity for high-level systems, and NIS2 and DORA push in the same direction — a business continuity plan aligned with ISO 22301 and NIST SP 800-34 is also advisable. The metrics to watch every week: backup success rate, RTO and RPO measured against the committed ones, inventory coverage and age of the last success.

7. Testing Restoration: The Three Levels

Restoration testing has three levels. The minimum, automated one: engines such as Veeam SureBackup or Rubrik’s anomaly detection verify every night that the copies can be mounted. The intermediate one: a quarterly restoration of a complete critical service in an isolated environment, with real measurement of the time taken. The complete one: an annual disaster recovery exercise with realistic scenarios and observers documenting every friction point. Most companies live at level zero: trusting the log.

An observation from recovery exercises: teams that test quarterly find their gaps in the lab; teams that never test discover them during the incident, at the worst possible time. Schedule the intermediate test for a quiet month, put a real operator in front of the restore wizard and measure everything: elapsed time, errors, missing pieces. Paper drills do not count.

8. The Recovery Protocol After an Encryption

When ransomware strikes and your immutable backups are still intact, the protocol is strict. First, verify integrity before restoring and choose a copy demonstrably older than the first sign of compromise, not the most recent one. Second, restore in an isolated environment and confirm with the EDR or with forensic analysis that no indicators of compromise remain before promoting the data to production.

# Recovery protocol after ransomware (operational summary)
# 1. Verify integrity BEFORE restoring (backup older than the compromise).
# 2. Restore in an isolated environment and validate cleanliness with EDR/IR.
# 3. Hunt for indicators of compromise (IOC) in the restored copy.
# 4. Change ALL credentials before returning to production.
# 5. REBUILD, do not restore, the compromised components
#    (domain controllers, hypervisors, management platforms).

Fig. 3 – Operational recovery protocol after ransomware encryption.

Third, change all credentials — users, services, certificates, API keys, OAuth tokens and CI/CD secrets — and rotate the krbtgt password twice if the domain was compromised. Fourth and most important: rebuild rather than restore the compromised components. The domain controller, the hypervisors and the management platforms can hide a footprint the forensic analysis does not see. Rebuilding from a clean image costs hours; discovering a backdoor months later is priceless.

9. Conclusion

The company that never suffers the attack is the exception; the one that recovers in days is the one with tested immutable backups. The 3-2-1-1-0 rule, immutability by configuration and restoration tests are not a luxury for large corporations: they are the difference between a ransom invoice and an orderly restoration. It is the difference that explains why 60% of attacked small businesses close within six months while others are operating again within a week.

If the worst-case scenario has already happened, the complete guide to acting as a victim is in our article on what to do if your company suffers ransomware, and you can fit these copies into the overall program with our reference on planning and designing technical audits. At Jaymon Security we design and audit immutable backup strategies so your last line of defense can take the hit it is built for.

Need help with Immutable backups?

At Jaymon Security, we help organizations protect their systems. From security audits to SIEM/SOC implementation, our expert team designs custom solutions.

Contact us for a free infrastructure assessment.