Snapshot lifecycle — create, verify, restore

Snapshot lifecycle — create, verify, restore A lifecycle diagram generated by Archify. 01 / Snapshot rail 02 / Verify + Recovery 03 / Outcomes Clean · DBs at rest, generation G · Snapshot rail 01 Clean DBs at rest, generation G Creating · pools + zstd twins · Snapshot rail 02 Creating pools + zstd twins Created · stamped generation G+1 · Snapshot rail 03 Created stamped generation G+1 Verified · snapshot-check green · Snapshot rail 04 Verified snapshot-check green Trusted · recovery point · Snapshot rail 05 Trusted recovery point Drift Flagged · DBs moved since stamp · Verify Drift Flagged DBs moved since stamp Restore · make snapshot-restore · Recovery Restore make snapshot-restore Superseded · rotated by next create · Outcomes Superseded rotated by next create tamper or drift snapshot-restore next create Legend start active state waiting decision terminal success failure / exit neutral

Evidence origin/main e37eb7db

  • • snapshot_db.py:102 create · :139 verify · :946 restore
  • • Makefile:119 snapshot · :123 snapshot-check · :126 snapshot-restore

What a create stamps (snapshot_db.py)

  • • pools: research.db, graph.duckdb, embed_store, corpus.db
  • • parquet exports + binary snapshots, zstd twins in db-backup/
  • • embed matrix excluded by design — zstd twins are the recovery points

Verify gates (A3 suite)

  • • a tampered snapshot with a dropped table FAILS verify
  • • generation drift is flagged against db_meta
  • • tampered snapshots are dropped — they never become recovery points

Restore

  • • make snapshot-restore, then reconnect query parity is proven
  • • embed cache rebuilds cold after restore (excluded from snapshots)
  • • executable spec: tests/test_integration_snapshot_cycle.py