Against the Immutable Backup: In Defense of Forgetting
Our field is built on a creed of preservation. We are taught, from the very first time a junior admin deletes a production table, that redundancy is sacred. The 3-2-1 rule is our liturgy. Immutable backups—those perfect, indelible, write-once-read-many snapshots of a moment—are often held up as the ultimate goal. They are the digital equivalent of carving records in stone, safe from ransomware, safe from error, safe from time itself. I’d like to propose a heresy: this quest for perfect, eternal memory is not only impossible, but often harmful to the small, living systems we aim to protect.
The Tyranny of the Permanent Record
Consider what we’re truly preserving. Not just clean data and elegant code, but every mistake, every piece of transient junk, every compliance nightmare waiting to happen. That hastily written script with the hardcoded credentials? Immortalized. That user data from a service you sunsetted three years ago, which you are now legally obligated to delete? Locked in stone. The immutable backup, in its righteous defiance of deletion, becomes a museum of your worst decisions and a liability vault. For a small service, the administrative and legal overhead of managing these perfect fossils can quickly outstrip the value of the data itself.
More subtly, this philosophy assumes a static world. It assumes the systems that wrote the data will always exist to read it. But technology rots. Formats become unreadable. Encryption keys are lost. The immutable backup from five years ago might be physically intact, but logically entombed. We pour effort into preserving the artifact, while neglecting the far more critical art of restoration—the living process of understanding, translating, and reintegrating data into a new context. A backup you cannot practically restore is not a backup; it’s an archive of anxiety.
There is a profound operational wisdom in planned, graceful forgetting. A backup strategy that includes deliberate, scheduled expiration is not a weakness; it’s a form of hygiene. It forces you to regularly consider what is truly essential. It demands that you validate your restore processes on current data, not ceremonial data from an eon ago. It aligns your defensive practice with the natural lifecycle of your services and the evolving landscape of regulation. A system that can shed its old skin is more agile and less burdened.
This isn’t an argument for negligence. It’s an argument for intention. Instead of striving for immutability at all layers, focus on creating robust, tested, and repeatable processes for generation and restoration. Build your services so that their state can be recreated from a combination of code, configuration, and a much smaller, more curated dataset. Design for resurrection, not mere preservation. Sometimes, the most reliable thing you can do is to let the past, in all its flawed and forgotten glory, dissolve into the bitstream. The goal isn’t to remember everything forever. The goal is to ensure the thing that matters can always, reliably, live again.
Notes & further reading
A few pages I came back to while writing this: