The Redundant Gardener: An Argument for the Unnecessary Backup
There is a sacred mantra in our world, repeated so often it has become a reflex: "Test your backups." And of course, this is wise. The horror story of the pristine, untested backup that fails at the moment of absolute need is a classic for a reason. We are taught to be diligent, to schedule regular fire drills for our data, to ensure that the lifeboat is not only present but seaworthy. But I want to propose a small, heretical act. I want to argue for the value of the unnecessary backup.
Consider the gardener who, having planted a row of tomatoes, immediately plants a second, identical row right beside it. Not as a contingency—the first row is healthy and strong—but simply because they can. There is no immediate need. The forecast is clear. The soil is rich. This second row is, by all practical measures, redundant. A waste of seed and soil. And yet, this superfluous act changes the gardener’s relationship to the first row. A sudden hailstorm that flattens the primary plants is no longer a catastrophe; it is an observation. The gnawing anxiety that accompanies a single point of failure evaporates. The second row, planted without cause, grants a kind of spiritual freedom.
We are conditioned to see our systems in terms of risk and necessity. A backup is a scheduled, justifiable expense against a quantifiable threat. It is a transaction. But what if we occasionally performed this act outside the bounds of transaction? What if, on a quiet Tuesday afternoon with all systems green, you meticulously took a full backup of a non-critical, yet complex, development database? Not because you were about to run a dangerous migration, not because of a patch Tuesday, but for no reason at all. You are the redundant gardener, watering a plant that does not yet thirst.
The benefit is not in the act itself, but in the mindset it cultivates. When recovery is a quarterly drill, it carries the weight of performance. There is a pass or a fail. When you restore from an "unnecessary" backup, you are simply exploring. There are no stakeholders waiting. No heartbeat conference calls. You are free to stumble, to discover a quirk in the restore process you never knew existed, to familiarize yourself with the terrain of recovery without the pressure of a ticking clock. This is a form of play, and play is a powerful teacher.
This practice also inoculates against the rigidity of procedure. Our necessary backups tend to follow the same well-worn scripts. They are automated, validated by checksums, and filed away. The unnecessary backup, however, invites experimentation. Maybe you try a new tool to take the snapshot. Perhaps you restore it to a different subnet, just to see what happens. This casual tinkering builds a deeper, more intuitive understanding of your systems than any runbook ever could. It transforms recovery from a scripted incantation into a fluent language you can speak, not just recite.
I am not arguing for profligacy or the wasteful consumption of storage. This is a deliberate, small-scale indulgence. The goal is not to fill your archives with pointless copies, but to occasionally perform the act of preservation as an end in itself. It is a ritual that reinforces competence over compliance, and confidence over mere checklist completion. So, next time you find yourself with a moment of quiet, consider making a copy of something for no good reason. You might find that the most reliable system is not the one with the most rigorously tested backups, but the one whose caretaker is not afraid to break it, because they have already, quietly, practiced putting it back together again.
Notes & further reading
A few pages I came back to while writing this: