Backup restore checks

Implementation

The runner verifies a backup manifest, restores the database with SQLite's backup API, extracts permitted archive members, and probes the recovered application data.

Database checks cover integrity, foreign keys, snapshot identity, visit count, and valid record fields. Attachment checks compare the manifest, database references, restored paths, byte sizes, and hashes.

Each run owns a fresh temporary directory and removes it after success or failure. It accepts no destination database path, and tests confirm source bytes and unrelated files remain unchanged.

An operational runner kills disposable restore processes, verifies supervised cleanup and retry, captures a live WAL snapshot, and evaluates PostgreSQL recovery control flow and transfer budgets as explicit theoretical models.

Inputs and assumptions

• The supplied backup set contains 24 synthetic service visits and 24 text attachments.
• Inputs are local and remain unchanged while checking. A manifest binds database and archive hashes to the expected snapshot and files.
• Archives contain regular files only and remain within the documented file-count and size limits.

Results

Report figures (1)

Open the full report ↗

Verification

13 regression tests and four fixture outcomes passed, plus 11 operational acceptance checks covering real process death, parallel restores, online snapshots, size limits, storage faults, and modeled PostgreSQL recovery.

python verify.py

Project files

The ZIP contains the source, inputs, results, and instructions. These files are also available individually.

• Recovery runner and application probesrestore_check.py · 9 KB
• Synthetic backup fixture generatormake_fixtures.py · 3 KB
• Valid backup manifestfixtures/good/manifest.json · 4 KB
• Synthetic database backupfixtures/good/database.sqlite · 24 KB
• Synthetic attachment archivefixtures/good/files.tar · 30 KB
• Executed fixture outcomesresults/summary.csv · 1 KB
• Mixed-snapshot failure recordresults/mixed-snapshot.json · 1 KB
• Failure and isolation teststest_restore.py · 5 KB
• Crash, operations and theoretical deployment reportoperations-report.html · 11 KB
• Executable operational rehearsaloperations.py · 16 KB
• Operational acceptance and source hashescompletion.json · 10 KB
• Expected and observed outcomesresults/operations/acceptance.csv · 3 KB
• Operating runbook and PostgreSQL analysisOPERATIONS.md · 7 KB

Run locally

Python 3.10 or newer with SQLite / Python standard library / Linux for the subprocess SIGKILL operational drills

Extract the ZIP and open a terminal in the backup-restore-checks folder. The README includes setup and usage details.

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

Limits

• SQLite restoration, subprocess crashes and data/file probes are executed. PostgreSQL and remote transfer are modeled; no PostgreSQL server or network transfer performance is claimed.
• The unsigned manifest detects accidental changes but does not establish authenticity.
• SIGKILL tests retain normal host storage behavior. ENOSPC is injected; neither qualifies power loss or physical disk failure.
• Local and modeled timings use small declared fixtures or assumed rates. They are not production recovery guarantees.