Home-server backup and recovery — a small restore exercise

A successful backup exit code does not prove that a service can restart from the saved data. Separate file restoration, database readability and the application operations you need. Begin with an exercise that never accesses production data.

Try the restore checks in your browser

Open the backup and restore Lab. No local Python setup is needed. The Lab creates synthetic text and SQLite records in a fresh temporary browser filesystem, uses SQLite's backup API, writes a compressed ZIP, extracts the two known filenames, then performs real hash, integrity and SQL checks. It removes its temporary files after each completed run. These operations do not touch your server, host files, credentials or services.

Start with the intact preset and save A. Compare it with a missing text file, modified text, a truncated database, or an incorrect record introduced before the backup. The first three failures are introduced after ZIP extraction. Record count varies the fixture from 1 to 50 rows; it does not model a production dataset or recovery duration.

The wrong-record case is the important distinction: its captured and restored files match, and SQLite reports a healthy database, but the SQL value is not the expected restore-check. Hash equality proves equality with this run's captured copy, not that the captured data was correct or that all application components were consistent. The application check reads only notes.id=1; the separate row count does not validate every row's contents.

Results separate Pass, Mismatch, Error, and Not run. A truncated database gives a hash mismatch and a SQLite error; the dependent application query is not run. A missing text file does not prevent independent database checks. A dash is an unavailable SQL result, not zero rows. The stage diagram and result tables retain A/B outcomes; the file table and JSON download include each run's captured and restored SHA-256 values. SQLite serialization may differ between runtime versions, so compare each restore to its own manifest rather than treating a digest as a universal fixture.

This is temporary synthetic storage, not a durable backup, service restart, consistency proof, RPO/RTO measurement, or disaster-recovery test. Download the browser adapter for optional standalone reproduction; the unchanged original reference retains the baseline exercise. Unlike the original, the adapter cleans up its temporary files and returns the evidence as JSON. The real-service procedures below need service-specific validation.

Define successful recovery

Diagram 1 · Use the button to switch views

A photo service needs relationships between images and database records. Authentication may also depend on configuration and encryption keys. Define the acceptable data-loss window, RPO, separately from the acceptable recovery duration, RTO. Backup frequency and restore time are different measurements.

Optional: reproduce the original exercise locally

Save restore_lab.py and run python3 restore_lab.py. It uses the Python 3.12.3 standard library. Each run creates a fresh temporary directory, one text file and one SQLite record. It does not stop or delete an existing service or dataset.

The script uses SQLite's backup API to copy the database, packages it with the text file into ZIP, and restores into another empty directory. It checks SHA-256 hashes, PRAGMA integrity_check and a known SQL record. See SQLite's official backup API explanation.

file_hashes: pass
sqlite_integrity: pass
application_read: pass
scope: synthetic fixture only

All three checks passed on September 7, 2026. Here, application reading means the known SQL query, not starting Immich or Nextcloud. The printed directory contains the retained evidence. The ZIP in that temporary directory is an exercise artifact, not protection against losing the storage device.

Capture real services consistently

Ordinary copying of live database files may not preserve the consistency needed for recovery. For PostgreSQL, review the requirements of methods such as SQL dumps. Consistency between the database snapshot and referenced external files is a separate concern.

Matching hashes establish equality with the captured copy. They do not prove that the whole application was consistent at capture time.

Additional checks with restic

The following is a procedure for an environment where restic is already installed; restic was not executed in this exercise. Configure the repository and credentials separately and record restic version. Select a snapshot and restore into an empty destination.

restic snapshots
restic check --read-data
restic restore SNAPSHOT_ID --target /path/to/empty-restore

Replace the ID and path for your environment. Restoration and repository checking answer different questions. Allow for runtime and transfer costs when reading stored data with --read-data.

Keep a recovery record

Record capture time, recovery start and finish, data volume, versions, file-check results and application operations. Verify in an isolated environment before replacing production data, with outbound email and webhooks disabled. Authentication and file-reading checks turn this small exercise into a service-specific procedure for the home-server platform.