The parts that don't rebuild themselves

A laptop dies, or a server gets rebuilt from nothing, and the question that actually matters is narrower than it sounds. Not "how do I back this up" — "which of these files does the engine actually need me to protect, because nothing else here can make them again on its own."

Most of an installation doesn't qualify. The engine itself is a git clone; pull it again and it's the same engine. Everything the build writes comes back with one rebuild, given what's left.

The instinct is to back up the site itself — the folder a browser actually sees. That's precisely the one thing this list leaves out. public.nosync, the build's own output, is exactly as disposable as the engine that made it: one rebuild reproduces it byte for byte, so keeping a copy of it would just be storing the same information twice, under two different names, and trusting the older copy by accident.

What's left, once the engine and the site it builds are both set aside, is a short list.

What's actually irreplaceable

The posts themselves, first — the one thing on this whole list that a rebuild, a re-clone or a redeploy cannot get back under any circumstance.

Beside them, and easy to leave out by accident: the version history each edit keeps. It sits next to the posts rather than inside them, so a backup of the posts alone keeps the archive and quietly loses the undo — the difference between a restored site and a restored site that can still answer "what did this say before I broke it."

The media is its own case since 1.6: a published picture is a hardlink back to the original file, not a second copy, so backing it up costs exactly what storing it once costs — even though the same picture may be referenced from a dozen places in the archive.

Then the smaller, easier-to-forget pieces: config/site.yml for the site's own identity and integrations, env.sh for the tokens that make it post anywhere at all, and the banner and favicon images — gitignored on purpose, which means a fresh clone hands back the engine's own defaults instead of yours, silently, if nothing kept a copy of the real ones.

Beyond that, only a couple of conveniences remain: the trash, in case a delete needs undoing later, and a hand-built palette, if the site's colours were ever anything other than what it shipped with. Neither is precious the way the rest of this list is.

What restoring actually is

A fresh clone, those few paths copied back, one rebuild. That's the whole procedure — and it's also, unchanged, what moving an installation to a different machine entirely looks like. A backup and a migration are the same short list, read on two different kinds of bad day.

Everything left off it — the build's own output, the deploy manifests, the build cache, the markers a scheduled publish leaves for itself between steps — either regenerates for free on the next run or costs exactly one operation to rebuild. None of it is a record of anything; all of it is a record of what the last run already knew how to redo.

Not a backup — an export

It's worth keeping the two apart, because they answer different questions. A backup is those paths exactly as they already are, meant to come back exact. An export converts — what markdown can't represent comes out as HTML instead — because it's built for leaving, not for returning. Restoring from an export works, but restoring from the archive itself is the one that loses nothing on the way. An export preserves the site. A backup preserves the project.