“We have backups” is not yet a recovery capability. A useful backup has a known scope, a known freshness, a verification step, and a restore procedure that someone has actually run.

Define the recovery unit

For a static site, the source repository and the generated artifact have different purposes. The repository is the authoritative input; the artifact is the quickest way to restore the last published version. Keep both distinctions clear.

At minimum, record:

  • the source commit or archive identifier;
  • the generator and theme versions;
  • the list of files included in the artifact;
  • the checksum of important downloads;
  • the retention period and storage location.

Do not include credentials, private keys, cookies, or access tokens in a website backup. Those belong in a separate secret-management process.

Verify before storing

An archive that cannot be opened is not a backup. A minimal verification loop looks like this:

tar -czf site-2026-08-22.tar.gz public/
tar -tzf site-2026-08-22.tar.gz >/dev/null
sha256sum site-2026-08-22.tar.gz > site-2026-08-22.tar.gz.sha256

The checksum verifies the file that was stored; it does not prove that every application-level assumption is correct. That is why a restore rehearsal is still required.

Restore somewhere disposable

Extract the archive to a temporary directory or an isolated host, then check the entry points and a representative resource. Do not test a restore by overwriting the only live copy.

restore_dir=$(mktemp -d)
tar -xzf site-2026-08-22.tar.gz -C "$restore_dir"
test -s "$restore_dir/public/index.html"
test -s "$restore_dir/public/404.html"

The command is intentionally boring. A rehearsal should reveal missing files, wrong permissions, or undocumented dependencies before an incident does.

Measure freshness honestly

A backup schedule is meaningful only relative to the amount of work that can be lost. If the source changes once a month, daily snapshots may be unnecessary. If a resource is updated every hour, a monthly archive is not enough.

Write down the target recovery point and recovery time, then choose storage and checks that can meet those targets. Avoid claiming “continuous protection” when the last verified restore is old.

Sources