Backup and Restore Service  ·  View 11 of 26  ·  4 · Data

Catalogue Data Model

One append-only event table and the projections built from it, including the field the platform is judged on.

Editable source SVG draw.io All views
datastore datastore_id PK engine · engine_version owner_team tier 1 | 2 | 3 classification group_id FK nullable artefact artefact_id PK (ULID) datastore_id FK type full | diff | incr | log chain_parent FK tool_version consistency_level checksum_sha256 key_ref custody_copy artefact_id + location PK location A | B | tape retain_until legal_hold bool verified_at recovery_range datastore_id + from_ts PK to_ts base_artefact FK log_from · log_to gap bool catalogue_event seq PK subject_id type captured | copied | verified | expired actor_spiffe_id payload jsonb recorded_at restore_run run_id PK form in-place | side | isolated | partial purpose drill | emergency requester · authoriser recovery_point duration_s proof run_id PK FK datastore_id FK depth_achieved 1–4 assertions_passed / total measured_rto_s custody_location protection_status datastore_id PK (projection) state UNPROTECTED … PROVEN last_capture_at last_proven_restore rpo_at_risk bool 1 : N 1 : N 1 : N 1 : N 1 : 0..1 projects projects Catalogue Data Model Only catalogue_event is written. Every other table is a projection that can be dropped and replayed. v 1.0 · owner Backup Platform · date 2026-09

Decisions

  • catalogue_event is the only table written to. Status, recovery ranges and custody copies are projections, so a correction appends an event and the history of what was once claimed survives.
  • protection_status holds last_proven_restore and not last_backup_succeeded. The second field is deliberately absent from the status projection, so no dashboard can be built on it by accident.
  • recovery_range records gaps explicitly. A WAL segment that never arrived is a hole in PITR coverage, and it is reported as one rather than smoothed over by the nearest base copy.

Numbers

  • About 30 million artefacts at the retention horizon, most of them WAL and binlog batches. Recovery-point lookup is an index range scan on (datastore_id, from_ts), with a p95 target of 500 ms.
  • Events are partitioned by month and kept for the life of the artefact plus 12 months.

Assumptions

  • ULIDs as artefact ids, so ids sort by time and the envelope key prefix can be derived from them without a lookup.
◀  Four Stores, Separated by What May Be Lost All views Capture Data Flow — From Source to Three Custodians  ▶
Solution Architecture v1.0 · Platform Architecture · 2026-09 · 26 views · open source, fully on-premises11-data-model