---
"@type": Article
"@id": "https://helloloam.dev/principles/backups-as-a-snapshot"
"@source": "https://helloloam.dev/data/article/backups-as-a-snapshot.json"
"@stamp": "2026-10-22T21:53:55+00:00"
about:
  "@type": DefinedTerm
  "@id": "https://helloloam.dev/data/definedterm/backups-as-a-snapshot.json"
  name: Backups as a snapshot
  identifier: backups-as-a-snapshot
  inDefinedTermSet:
    "@type": DefinedTermSet
    "@id": "https://helloloam.dev/data/definedtermset/mechanics.json"
    name: Mechanics
    identifier: mechanics
author: {"@id":"https://helloloam.dev/#organization"}
datePublished: "2026-10-03"
description: Every fifteen minutes the site commits itself to its own private git mirror. Nobody has to remember to save.
headline: Backups as a snapshot
identifier: backups-as-a-snapshot
inLanguage: en
publisher: {"@id":"https://helloloam.dev/#organization"}
url: "https://helloloam.dev/principles/backups-as-a-snapshot"
---

# Backups as a snapshot

## What can still go wrong

A loam site is a folder that renders on request. There is [no database to corrupt](/principles/files-not-a-database), no build to fail, no cache that has to be warm.

| Event | Result |
| --- | --- |
| **The server restarts** | The site is read from disk on every request; it is exactly what it was. |
| **A change is bad** | It stays a draft until it passes the check before publishing. |
| **The cache is lost** | It is rebuilt from the files — a convenience, never the truth. |

What remains is what goes wrong with any server — a disk fails, a provider has an outage — or with any person: the wrong version published, a needed page removed. Both have the same answer: history.

## A snapshot every quarter of an hour

The whole folder — content, templates, images and the journal — is committed to git and pushed to a private mirror. Nobody has to remember to save, and nobody commits by hand. Each run records whether the site passed its own check at that moment, and leaves one line saying how it went, so a silent failure is noticed. Every version of every file exists, dated.

## A journal on top

Git keeps the versions; the journal says what they mean. Every change carries a line: what was done in plain language, which key did it, what was touched — and what you asked, in your words, when your agent passes that along. Ask “what changed this week” and your agent reads the journal back.

## Undo is a request

Recent mistakes are handled by [the draft layer](/principles/draft-and-live-lifecycle): a draft is dropped, a published page is taken back. Everything older is history: “put the pricing page back to how it was before Tuesday”, “what did the home page say in June”, “when did the phone number change” — your agent brings the older version back as a new draft, previewed and published like any change. The undo gets its own journal line. Nothing is silently rewritten.

## Recovery is copying

Restoring a site is putting the folder back on a server and pointing the domain at it. No database to import, no migration, no build. The engine is generic and sits in its own folder, so a restore is the site plus the engine — nothing only the original server knew. Moving a site is the same operation.

## What it costs

Two things stay out of the mirror on purpose. Drafts that were never published live on the server until they are published or dropped. And the form inbox holds personal data, so it does not travel to a code repository — the server's own backup covers it, and how long it is kept is yours to decide. The mirror itself must stay private: it holds the key fingerprints.