The Unnecessary Artifact: On the Case for Deleting Old Backups

We are taught, from the moment we first save a file, to hoard. The mantra is repeated in every ops room, every admin guide, every disaster recovery plan: keep everything. Retain logs for seven years. Maintain a grandfather-father-son rotation of backups. Archive the archives. We build digital libraries of our potential failures, vast catacombs of yesterday’s state, just in case. It feels prudent, responsible, safe. But I want to propose a heretical thought: what if this compulsive retention is itself a form of risk? What if the safest thing to do is to deliberately, and with clear intent, destroy what we have saved?

The common wisdom is that an old backup is a harmless insurance policy. It sits on a shelf, in a cloud vault, on a tape, inert and waiting. But it is not inert. Every backup is a snapshot not just of data, but of a context: the operating system of its time, the application dependencies, the security permissions, the very architecture of a moment since passed. Restoring from a five-year-old backup isn't retrieving a pristine document; it's attempting to reanimate a ghost into a world that has fundamentally changed. The software it needs to run may no longer exist, or may be riddled with vulnerabilities long since patched in the living system. You get your data back, only to immediately expose it to a hostile environment it was never designed to face.

The Weight of What We Keep

Beyond the technical debt, there is the sheer cognitive weight of the archive. Each retained backup is a decision we might have to make later. In a crisis, under the duress of an outage, the last thing a team needs is to be confronted with a dozen subtly different restoration points from the last half-decade. Which one is correct? Which one is safe? The paradox of choice becomes a paralysis, and the safety net becomes a snare. The mental model of the system becomes cluttered with relics, making it harder to understand what the system is versus what it was.

I am not arguing against backups. I am arguing for their intentional mortality. A backup should have a defined and valuable lifespan—long enough to recover from operational errors and short-term crises, but not so long that it becomes a historical artifact. A rigorous, even aggressive, deletion policy forces a crucial discipline: it demands that your recovery process be tested regularly and that your data be migrated forward into contemporary formats. It ensures that your restoration scripts are never so old that they become un-runnable mysteries themselves.

By willingly deleting what is old, we are not being reckless. We are making a conscious choice to invest our trust not in the brittle artifacts of the past, but in the robust, tested, and understood processes of the present. We are choosing a known, current recovery path over a multitude of decaying, unknown ones. It is an act of hygiene, a declaration that our confidence lies in our ability to rebuild correctly today, not in our ability to resurrect the ghosts of yesterday.

Notes & further reading

A few pages I came back to while writing this: