The Seductive Lie of the Immutable Vault

In the small operations world, a powerful dogma has taken hold: the sanctity of the immutable backup. We are told, with the fervor of a catechism, that our backup targets must be locked down, write-once-read-many, impervious to encryption by ransomware, and utterly unchangeable after the initial write. The vault door must slam shut, never to be reopened by the hands that sealed it. This idea is presented as the final, untouchable pillar of data integrity. I think it’s a dangerous oversimplification, a lie we tell ourselves to feel safe from complexity.

The logic is seductively clean. If a backup file cannot be altered or deleted, then the threat of malicious overwrite vanishes. It becomes a digital fossil, preserved in perfect amber. For large-scale, compliance-driven archives, this has undeniable merit. But for the keeper of a small service—the one-person ops team, the indie developer, the in-house sysadmin—this immutability can become a different kind of trap. It trades the acute risk of malicious deletion for the chronic, creeping risk of operational paralysis and resource bloat.

The Tyranny of the Perfect Snapshot

Immutability enshrines every mistake. That accidental backup of the 80-gigabyte temporary cache directory? It’s now a permanent tenant, consuming resources and costing money, a monument to a stray keypress. The corrupted database dump from a faulty script run three weeks ago? It sits there, useless but untouchable, counting down the days until you need that specific point-in-time restore and discover the stone you relied on is made of sand. The policy, designed to protect you from an external attacker, instead protects your own errors from being remediated.

Worse, it can foster a false sense of security. “The backups are immutable,” the report says, and the box is checked. But were they ever verified? Immutability doesn’t mean recoverability. A vault can be perfectly sealed and yet empty, or filled with unreadable stone tablets. The focus shifts from the active, human practice of testing and validating recovery to the passive, technical state of the storage medium. We stop being gardeners tending a living system and become curators of a mausoleum.

The true goal isn’t immutability; it’s integrity and recoverability. For a small service, this is often better achieved through a layered, thoughtful approach: multiple copies with different retention policies, strong access controls (the ‘how’ of modification, not the ‘if’), and relentless, automated verification. Sometimes, the most reliable operation is the judicious, logged, and authorized pruning of a known-bad backup to make room for a healthy one. It requires more vigilance, more ceremony, and more trust in process over platform. It’s messy, human work.

We reach for the immutable vault because it promises to absolve us of judgment. It turns an ongoing practice of stewardship into a one-time configuration setting. But in our world, the world of small services and limited resources, there are no set-and-forget solutions, only trade-offs. The next time you hear the siren call of the forever-locked archive, ask yourself: are you building a last line of defense, or are you building a prison for your future self?

Notes & further reading

A few pages I came back to while writing this: