The Fallacy of Fidelity: Why Your Perfect Backup Is a Delusion
We are taught, from our first fumbled rsync to our intricate orchestration of immutable snapshots, that a backup’s highest virtue is fidelity. The perfect copy. The bit-for-bit mirror of a moment, pristine and untouched, waiting in cold storage for its moment of redemption. This is the holy grail we’re sold by vendors and internalized as doctrine. But I’d like to posit a heretical thought: this obsessive pursuit of perfect fidelity is not just a distraction; it is a dangerous delusion that undermines the very purpose of having backups at all.
Consider the analogy of a ship’s log. A captain doesn’t need a perfect, molecular-level recreation of the sea spray on the bridge window from last Tuesday. They need the navigational data, the course plotted, the weather observations—information structured for use in a crisis. Yet in our digital realm, we cling to the spray. We boast of checksums and cryptographic hashes that verify the sanctity of our terabytes, while quietly neglecting the more profound question: can we actually reassemble a working system from this sacred pile of bits? Fidelity to the source does not guarantee utility for the destination.
The Chasm Between Copy and Capability
The delusion manifests in the silent chasm between a backup’s existence and its restorability. We have all seen, or lived, the ritual: the backup job ticks green for 423 consecutive days. Then a drive fails, or ransomware strikes, and the scramble begins. The bits are there, faithful as ever. But the restore script is keyed to an OS version three releases ago. The database backup requires a specific patch level to be imported, a detail lost to time. The encryption keys for the backup itself are stored in the very system now in ashes. The fidelity of the data is perfect; the capability to use it is zero.
We spend cycles optimizing compression and deduplication, chasing the phantom of efficiency, while the messy, human, procedural work of recovery is relegated to a dusty runbook that no one has tested. The perfect backup becomes a trophy on a shelf, a comforting icon we point to during audits, its interior workings a mystery. It is reliable technology in the most boring and tragic sense—it reliably does nothing but occupy space until the moment it is needed, when it reliably fails to perform.
The counterintuitive path forward is to shift our core metric from fidelity to fitness. A backup’s value is not measured by its similarity to the original, but by its ability to create a functional successor. This demands a culture of purposeful, regular corruption. Not of the data, but of the state we seek to recover. We must intentionally kill systems and force a rebuild from our backups—not just the data restore, but the full service resurrection. The goal is not to confirm the bits are unchanged, but to discover that the playbook is wrong, that a dependency is missing, that the timeline to recovery is measured in business-ending days, not hours.
Embrace the imperfect, the lossy, the good enough backup that is built for a specific recovery objective, not for archival purity. Sometimes, a backup of just the customer data and a modern deployment script is infinitely more fit for purpose than a perfect image of a petrified server. Let go of the mirror. Build a lifeboat instead. It doesn’t need to look like the ship; it only needs to float, and it must be tested in rough water. That is the boring, reliable truth we’ve been avoiding.
Notes & further reading
A few pages I came back to while writing this: