Backups are a recovery system.

Start with what cannot be replaced

Application databases, household files, configuration, and host setup each need explicit coverage. A directory being on a server does not automatically mean it is backed up. The backup inventory records the protected paths and the recovery procedure for each layer.

The bulk storage pool is non-redundant. That makes the distinction between availability and recoverability especially important: a backup can enable recovery without keeping a failed storage system online.

flowchart TD
  accTitle: Layers of data protection
  accDescr: Consistent application data and configuration feed local recovery copies and encrypted off-site copies. Restore verification checks the usable recovery artifacts, not just job completion.
  Data["Application data + configuration"] --> Consistent["Consistent dumps / snapshots"]
  Consistent --> Local["Local recovery copies"]
  Consistent --> Offsite["Encrypted off-site copies"]
  Local --> Verify["Scoped restore verification"]
  Offsite --> Verify

This is the protection model. Verification coverage is recorded per system and artifact; the diagram does not imply every copy is restored on every run.

Database consistency

Workbench uses SQLite in WAL mode. Its scheduled backup uses SQLite’s online-backup API and checks integrity, rather than assuming a copy of the main database file contains every committed change.

Fed Forager uses PostgreSQL dumps and a separate scheduled restore test. The restore result has its own timestamp and scope. A successful compression check is useful, but it is not equivalent to successfully restoring the database.

Independent layers, explicit limits

The lab combines restic-based protection, other existing encrypted off-host backup paths, guest backups, and host configuration capture. These overlap deliberately. Retention and placement must also respect the storage underneath the repositories.

That last point is easy to miss: a backup can threaten the workload it is protecting if its repository fills a shared thin pool. The capacity incident is a worked example.

What I verify

• Execution: did the expected job run and report its result?
• Freshness: does the repository contain a recent artifact, rather than merely a successful timer status?
• Consistency: was the data captured through an appropriate database or snapshot mechanism?
• Recoverability: what restore was performed, with which artifact, and what checks passed?
• Instructions: can another operator follow the recovery runbook under pressure?

Current evidence

The October 3 documentation reconciliation checked timers, recent results, repository metadata, and selected storage state. It was not a new full-estate restore exercise. Historical restore tests retain their own dates and scope.

I prefer a precise statement of what was verified to a broad “backups are working” claim. It makes the next recovery check much easier to choose.