Recovery tooling / SQLite

Backup restore checks

A database backup and file archive were restored into disposable resources. Record counts, snapshot identity, attachment references, and file hashes were checked before cleanup.

13 automated tests passed. 4/4 fixture outcomes matched their expectations. These are local synthetic fixtures; the timings do not estimate production recovery time.

Recorded fixture outcomes from the executed verification run
Results generated from the included verification records.

Executed cases

FixtureOutcomeDatabase restoredFindingSeconds
goodPassYes24 visits and 24 attachment references verified0.006279
corruptRejected as expectedNoCheckError: Checksum mismatch: database.sqlite0.000215
mixed-snapshotRejected as expectedYesCheckError: Database/manifest snapshot mismatch0.006219
missing-fileRejected as expectedNoCheckError: Archive is missing manifest files: visits/001.txt0.003904

The mixed-snapshot case reaches a successful database restore, then fails the application probes. Restoring bytes alone is insufficient for this record-and-file contract. Every run removed its owned temporary directory.

Checks exercised

Run it

python restore_check.py fixtures/good --report results/manual-good.json
python verify.py

Operational verification

The additional process-failure, concurrency, capacity and theoretical deployment checks are recorded in the operations report. The overall verification includes those outcomes.

Scope

Python standard library and SQLite. The runner checks one service-record schema and a local regular-file archive. PostgreSQL recovery stages and remote-transfer budgets are modeled separately; those are theoretical outcomes, not PostgreSQL or network measurements. Secrets and full application startup depend on the deployed application. The manifest is unsigned. Inputs must remain stable while the runner reads them.

Runtime: Python 3.12.14; SQLite 3.53.1. Generated 2026-10-27T23:43:08.228015+00:00.

Verification JSON · Case CSV · Test log · Run instructions