The Tyranny of the Triple Copy: On the Backup That Became the Burden
We have been catechized into a rigid faith. The high priests of operations recite the sacred incantation: "3-2-1." Three copies, two different media, one off-site. It is a mantra so ingrained, so seemingly self-evident, that to question it feels like heresy. Yet, I find myself harboring a quiet blasphemy: what if our obsession with perfect, abundant backups has become its own form of systemic risk? What if we are building a library of Alexandria in our data centers, meticulously preserving scrolls we will never have the time or context to read, all while the real work of keeping the lights on withers from neglect?
The common advice treats backup creation as the finish line. We celebrate when the cron job completes without error, when the cloud sync reports success. But a backup is not an achievement; it is a promise. And that promise is only fulfilled in the dreadful, time-pressured crucible of a restoration. We have become so focused on the act of saving that we have forgotten the art of recovery. Our elaborate rituals create a false sense of security, a Potemkin village of preparedness that collapses under the first real test.
The Weight of Infinite History
This is the counterintuitive heart of it: by trying to save everything, we may be ensuring we can save nothing of consequence. Every byte we archive incurs a silent tax. It requires storage, which costs money, but more insidiously, it demands cognitive load. When a service falters, the system administrator is not faced with a single, clean backup from an hour ago. They are confronted with a chronological labyrinth: nightly full backups from the last year, daily incrementals for the last month, and continuous transaction logs for the last week. The very abundance of choice becomes a paralyzing burden. Which snapshot holds the precise state before the corruption crept in? Which log sequence is truly consistent? The pressure to restore quickly wars with the fear of restoring incorrectly, and in that hesitation, downtime lengthens.
Our logs suffer a similar fate. We aggregate everything, from the critical "database connection failed" to the trivial "user clicked a button." We do this because storage is cheap, and we fear missing the one crucial clue. But in doing so, we have created a haystack of such monumental size that finding the needle requires ever more complex and fragile tooling. The log, intended as a lantern in the dark, becomes a blinding blizzard of data. We build watchers to watch the watchers, and the system's complexity spirals, all in the name of preserving a perfect record of its own operation.
Perhaps the wiser path, the counter-cultural discipline, is one of intentional amnesia. What if, instead of a triple-copy ritual, we invested that engineering effort into designing systems that are inherently simpler to resurrect? What if we focused on immutable infrastructure, where a service restoration is not a delicate database rollback but a swift, deterministic deployment of a known-good artifact? What if we archived our logs not for eternity, but with a purposeful expiry date, forcing us to be more selective about what we truly need to remember? This is not a call for recklessness. It is a plea for mindfulness. It is the argument that a single, tested, and ruthlessly simple recovery plan is worth a thousand untested backups. Reliability isn't born from the sheer mass of what we save, but from the elegant simplicity with which we can rebuild.
Notes & further reading
A few pages I came back to while writing this: