Ransomware crews learned the trick years ago: don't just encrypt the production data, delete the backups first. A backup you can delete is not protection against ransomware, it is a copy waiting to be removed by whoever ends up holding your admin credentials. That is why "immutable" is now printed on every backup vendor's box. It is worth knowing what the word actually buys you, and what it doesn't.
The mechanism underneath most of it is S3 Object Lock. Here is what it does, where it stops, and the two decisions that decide whether it protects you or just looks like it does.
What "immutable" actually means
S3 Object Lock is write-once-read-many at the object level. When a backup version is written with a retention date, the storage refuses to delete or overwrite that version until the date passes. It is not a flag the client can turn off afterwards, and not a "please keep this" label: the storage itself rejects the delete API call. Veeam 12 and later, Commvault and others speak S3 object storage natively and set that per-object retention for you, so an immutable backup tier is a bucket setting plus a retention policy, not a separate appliance.
Compliance vs Governance
Object Lock has two modes, and the difference between them is the entire point.
Governance mode locks the object, but a user holding one extra permission can still delete it early. That is fine against a fat-fingered admin. It is useless against a compromised one, which is exactly the ransomware case: the attacker is using real credentials.
Compliance mode locks the object for everyone until retention expires: the account root, the person with every permission, even the storage operator. There is no bypass. If the threat you actually care about is someone holding your keys, only compliance mode helps. It is also why Veeam's own immutability requirement is compliance mode, not governance. ZERO-Z3 uses compliance mode.
The one setting that matters
Governance mode can be bypassed by a privileged user. Compliance mode cannot, by anyone, until the retention date. If immutability is meant to survive a credential compromise, it has to be compliance mode. Check which one your storage target actually uses.
What it does not protect against
Immutability is one property, not a backup strategy. Being honest about the edges:
It protects the objects that are locked. It does not create the copy, verify that a restore works, or replace the 3-2-1 rule. It is the copy that survives an attack, not the whole plan.
You cannot delete a locked copy early, on purpose. So retention length is a cost and capacity decision you make up front: every immutable restore point sits there, paid for, until it expires. Set retention too long and you are paying to keep data you are not allowed to remove.
It locks data, not identity. The credentials and the path that sets retention still need protecting. And the lock releases on a date, so the retention policy and the clock are part of what you are trusting.
Where the copy lives
Immutable is necessary but not sufficient. An immutable backup sitting in a US-owned cloud is immutable and still reachable under the US CLOUD Act, whatever the region label says. For regulated data, finance, health, public sector, anything under DORA or GDPR, where the immutable copy lives is as much a control as whether it is locked. ZERO-Z3 keeps it in EU-only datacenters, operated by a German company with no US parent: immutable and outside foreign jurisdiction.
The honest cost
Immutable copies are storage you have committed to keep, so do the math before you set the policy. Storage accrues for the full retention, because you cannot prune early. Restores read the data back out, and that is where hyperscaler backups surprise you: per-request and egress metering hand you a bill during an incident, exactly when you least want one.
ZERO-Z3 is flat: €7.50/TB/month storage, €5/TB egress, no per-request fees. The rate is not the point, the predictability is. You can size a retention policy without guessing what a large restore will cost.
If you are turning on immutability, the checklist is short. Object Lock enabled on the bucket at creation, because it cannot be added afterwards. Compliance mode, not governance. Retention set by your backup software, per restore point. And the copy in a jurisdiction you actually control. The lock is the easy part. The mode, the retention math and the jurisdiction are where it is won or lost.