Ask a room of infrastructure people whether their backups are protected against ransomware and almost everyone says yes. Ask what specifically protects them and the answers separate into two groups who think they are saying the same thing.
One group means immutability: the backup repository will refuse to delete or modify data before a retention date. The other means an air gap: the backup data is not reachable from the production environment at all.
These are different controls with different failure modes, and conflating them is how organisations end up confident and exposed at the same time.
What immutability actually protects against
Immutability is enforced by software, in the storage system or the backup platform. It is genuinely strong protection against the common attack: an intruder with domain credentials who tries to delete backups before encrypting production.
Its limits follow directly from how it is implemented. Something enforces the rule, and that something has an administrative interface, and that interface has credentials. If the retention lock can be shortened by an administrator, then the control is only as good as the protection on that administrator account. If the appliance has a support account, a vendor remote access path, or a factory reset that clears the lock, those are all part of your threat surface.
So the question to ask your backup vendor is not “do you support immutability”. Everyone says yes. The question is: who can shorten or remove the lock, through which interface, and what exactly happens if someone with full administrative rights on the platform tries? A good answer names a specific mechanism. A vague answer is an answer.
What an air gap protects against
An air gap means there is no network path. Tape in a cupboard. A replication target that is powered off between windows. A copy in an account with entirely separate identity infrastructure.
The strength is that it does not depend on software behaving correctly under attack. The weakness is operational: air-gapped copies are older, slower to restore, and only as good as the process that maintains them. An air gap maintained by a human who is on holiday is an air gap with a gap.
The thing that undermines both
Shared identity. If your backup infrastructure authenticates against the same directory as production, then compromise of that directory is compromise of both, regardless of which control you implemented.
I have reviewed environments with excellent immutable storage, correctly configured, protecting a backup console that was a member server in the same domain as everything it was protecting. The control was real. The blast radius still included it.
Separate identity for backup infrastructure is unglamorous, moderately annoying to run, and probably the single highest-value change most organisations could make to their recovery posture.
The question that settles it
Forget the architecture diagram and ask this instead: if an attacker has full domain administrator rights and four uninterrupted hours, which copy of our data still exists afterwards?
Follow the answer honestly. For each copy: what stops it being deleted, what credential controls that mechanism, and is that credential in the compromised domain? Most people find at least one surprise on the first pass. That is the point of the exercise.
And then the part everyone skips
A copy you cannot restore from is not a backup, it is a receipt. The recovery time nobody has measured is not a recovery time, it is a hope.
Test a restore of something large and important, on a schedule, with the clock running, and write down the real number. Not a file-level restore of a test document — a restore of a system that matters, from the copy you would actually reach for after a bad week.
Almost every organisation I have seen do this for the first time discovers their real recovery time is several multiples of the number in the policy document. Better to find that out on a Tuesday of your choosing.
Summary in one line
Immutability protects the data from deletion. An air gap protects the data from reachability. Separate identity protects both from the credential that would otherwise undo them. You want more than one, and you want to have tested the restore.