The Mason and the Herder: Building With Stone Versus Tending the Flock
In the quiet work of keeping systems running, there’s a fundamental divide in philosophy that rarely gets spoken about. It isn’t about which tools to use, but about the very nature of the problem we’re solving. On one side, we have the Masons. On the other, the Herders. The tools might sometimes overlap, but the mindset, the goal, and the daily rhythm are worlds apart.
The Mason sees a system as something to be built. Their primary material is stone: solid, immutable, predictable. Their ideal backup is a perfect, timestamped snapshot of a system’s block storage—a monolithic slab of data, quarried and laid precisely in an archive. They work with filesystem-level tools that capture the entire state at a single moment, believing that true reliability comes from a definitive, atomic copy. For the Mason, the system *is* its state at time T, and restoration is the act of fitting that carved stone back into the foundation. It’s a grand, deliberate, and often infrequent act of preservation. The appeal is its conceptual purity. When you restore, you get exactly what was there, down to the last byte. There is no ambiguity.
The Herder, in contrast, sees a system as something alive, a flock that is always in motion. Their medium is not stone but the flock itself—individual entities (files, database records, configuration details) that need to be guided and tended. Their backup is not a single slab but a continuous, incremental stream. They use tools that watch the flock, noting when a single ewe wanders off or a new lamb is born, meticulously recording every change in a ledger. For the Herder, the system is a flowing process, and reliability is achieved not by periodic freezing but by a meticulous, ongoing narrative of its life.
This difference dictates the entire rhythm of operations. The Mason’s work is episodic. There is the quiet period of normal operation, followed by the planned, resource-intensive event of taking the snapshot. It can be disruptive, like closing a museum to make a catalog. The Herder’s work is ceaseless, a low hum of activity in the background. The flock is always moving, and the herder is always watching, with backups accumulating as a natural byproduct of the system’s existence. Restoration for a Herder is rarely about going back to a single point in time, but about replaying the ledger from a known good state, guiding the flock back to a safe pasture.
So, which is better? The answer, frustratingly, is that you are likely both a Mason and a Herder. The Mason’s approach is unbeatable for catastrophic recovery—when the entire pasture has been swept away by a flood, you need to rebuild the walls from solid stone. But for the common aches and pains—the accidental deletion of a critical file, the corrupted database record—the Herder’s granular, incremental ledger is a lifesaver. The true art of our unglamorous craft lies not in choosing one over the other, but in understanding the character of your systems. Which parts are foundational stone, and which are living flocks? The most resilient setups I’ve seen use the Mason’s snapshots as a bedrock, a long-term guarantee, while the Herder’s continuous logs handle the day-to-day realities of a world in motion.
Notes & further reading
A few pages I came back to while writing this: