The 3-2-1 backup rule: where immutability and offsite copies fit

What 3-2-1 covers, and the gap it leaves

The rule is easy to remember: keep at least three copies of your data (the live data plus two backups), on two different kinds of storage, with one copy offsite. The NCSC describes it as the most common method for creating resilient backups, and it copes well with the things it was designed for: a failed disk, a stolen laptop, a flooded server room.

The catch is in the NCSC's own wording. Its backup guidance points out that 3-2-1 does not require any backup location to be offline. A copy can be offsite and still be reachable with the same admin account an attacker has just taken over. The NCSC's guidance on preparing for disruptive attacks goes further and says to make backups immutable where possible, because attackers often target them to slow recovery.

So 3-2-1 answers 'where are my copies?'. Offline, logical separation and immutability answer a different question: 'who or what can change or delete them?'. You need both answers.

Offsite, offline and immutable are three different protections

These terms get used as if they were interchangeable. They are not, and a single backup can have one, two, all three or none of them.

Here is a fictional example. A twelve-person architecture practice backs up its file server every night to a NAS in the same office, then copies that to a cloud storage account. Both steps use the same domain admin account. On paper that is three copies, two kinds of storage and one offsite, so 3-2-1 is satisfied. But anyone who controls that one account can delete the NAS copy and the cloud copy in an afternoon. The rule was followed and the protection is thin.

• Offsite means a different physical location, so a fire, theft or flood at your premises does not take every copy. The NCSC notes that cloud storage guarantees physical separation from your live environment.
• Offline or logically separated means the backup is not connected to, or controllable from, your live systems except when a backup job needs it. The NCSC says to keep multiple backups and to logically separate them, so that one compromise leaves another copy intact. You cannot unplug cloud storage, so for cloud this comes down to identity and access controls rather than a cable.
• Immutable means the stored backup cannot be changed or deleted for a set retention period, even by someone with administrative rights. Cloud providers describe this as WORM (write once, read many). The NCSC compares the idea to traditional write-once storage.

What immutability gives you, and what it does not

Immutability is a strong control, but it has edges, and most of them are about the retention period. When that period ends, the data can be deleted. Both AWS and Microsoft document this for their object lock and immutable blob features. Choose a period longer than you realistically need to notice a problem, because an attacker who has been quietly inside your network for a while may have been running alongside your backups. The NCSC also advises keeping backups for a fixed period of time rather than a fixed number of copies, since a fixed count can be flushed out quickly by a flood of new bad backups.

Not all immutability is equally strict. Amazon S3 Object Lock has governance mode, where users with a special permission can still remove the lock, and compliance mode, where no one can, including the AWS account root user. In compliance mode AWS says the only way to delete protected data before its retention date is to delete the whole AWS account. Azure's immutable blob storage has a similar split: a policy starts unlocked, so it can be changed or removed, and once locked it cannot be deleted and its retention can only be extended. In AWS, the console includes the governance bypass header by default, so a person with that permission can delete locked objects with one click. That is convenient for an administrator and equally convenient for a thief holding the same permission.

That difference is a real trade-off. The strict setting gives you more protection from a compromised admin account. It also means that if you pick the wrong retention length, or upload something you needed to remove, you cannot undo it. Our judgement is to try an unlocked or governance setting on a small test set first, understand how your backup software writes to it, and only then choose the strict mode for production backups.

Immutability protects the stored copy and nothing else. It does not stop an attacker stopping your backup jobs, encrypting the source data, or locking you out of the account that holds the backups. The NCSC's principles for ransomware-resistant cloud backups cover exactly these: keep an out-of-band way into the backup service, protect encryption keys, and raise alerts on mass deletions, stopped backups or changed retention settings. An immutable copy of data that was already infected is still infected, so the NCSC also advises scanning backups for malware before restoring.

Finally, compatibility. Immutable storage has to suit the way your backup software writes data. S3 Object Lock only works on buckets with versioning enabled (versioning keeps earlier versions of an object rather than replacing them). Azure says immutability is incompatible with point-in-time restore, does not suit the disk files of running virtual machines, and can break backup tools that create a file and then keep appending to it. In practice that means using an immutability feature your backup product explicitly supports, not turning it on at the storage layer and hoping.

Where cloud storage and file sync fit

File sync services such as a shared drive client are convenient, but they are not the same as a backup. The NCSC warns that cloud services often synchronise immediately after your files have been replaced with encrypted copies, so the damage is faithfully copied. It says your cloud service should protect previous versions from being immediately deleted, and that you should be able to restore to them.

The same guidance says you should not rely on several copies in a single cloud service, or on two copies on one removable drive. For a very small business with an external drive, the NCSC's small-organisation advice is that the drive should not stay connected when not in use, and that online backups should be protected with two-step verification. A rotating drive is only offline if somebody actually unplugs it.

How to check your own set-up without changing anything

This is a review you can do at a desk, reading settings and writing notes, before you alter a single thing. Anything in step five that touches real data should be done carefully and only by someone with the right access.

1. List every copy of the data that matters, including the live one. For each, note what kind of storage it is, where it physically sits and what process creates it.
2. For each backup, write down every account, group, service or key that could delete it today. Include the backup software's own service account and any cloud access keys. Then ask the awkward question: if an attacker controlled your main admin account, could they delete this copy?
3. Mark each backup against the three protections: is it offsite, is it offline or logically separated, and is it immutable? For immutability, confirm in the provider's or product's own settings that it is switched on, what the retention period is, and whether the mode is one an administrator can lift. A sales page is not evidence.
4. Check you can still get to the backups if your office systems are down. Where are the backup login details, encryption keys and recovery instructions kept, and can you reach them without your normal accounts? The NCSC recommends keeping recovery documentation separate from production systems.
5. Run a small test restore. Pick a modest, non-critical set of files, restore it to a different location, never over live data, and confirm it opens and is complete. Note roughly how long it took, because that is a more honest planning figure than a vendor estimate. For a real recovery from an incident, scan restored data for malware first.
6. Compare what you have found to this target: at least one copy that someone holding your main admin credentials cannot delete, a retention period that comfortably exceeds how long it would take you to notice a problem, and a restore you have actually watched work. Anything short of that is your to-do list.

A sensible pattern for a small business

This is our engineering opinion rather than a sourced standard, and your data volumes, internet speed and budget will bend it.

Keep a fast local backup on separate storage for everyday restores, using credentials that are not your general admin logins. Add an offsite copy held in a cloud account with its own separate login, protected by two-step verification, and with immutability or at least protected previous versions, set to a retention period you have chosen deliberately. The local copy gives you speed. The immutable offsite copy is the one you will be grateful for on a bad day, though it will restore at the pace of your internet connection, so test how long that really takes.

If the backup holds personal data, think about how long you are comfortable being unable to delete it. A strict retention lock is exactly that: it cannot be undone early. That is a decision to make knowingly, and we are not offering legal advice on it here.

What to confirm before relying on this

Immutability features change between product versions and editions, and the AWS and Azure behaviour described here reflects their documentation at the time of writing. Check your own backup product's current documentation for what it supports and how it is configured. Data held in services such as Microsoft 365 raises its own backup questions, which this note does not attempt to answer.