Restore completes but application state is inconsistent

Understand the likely causes

• Backups may cover different consistency points, required metadata or keys may be missing, the application version may assume a different schema, or external confirmations may outlive restored records. Replication or byte checks alone cannot establish that application-level invariants and side-effect relationships remain valid.

Preserve the recovery boundary and evidence

Record the incident time, latest usable recovery point, restored artifact identities, schema and application revisions, included stores, and omitted dependencies. Preserve tool logs according to access and privacy policy. Do not rerun destructive restoration against a live system merely to investigate a mismatch. Establish who can authorize further changes and whether writes should remain restricted under the actual recovery plan. A success message establishes only the tool’s stated completion condition; read that condition before expanding the claim to full service restoration.

Compare identifiers and relationships

The offline fixture compares synthetic confirmed reservation IDs with restored record IDs. It finds a missing record and an extra record despite equal set sizes. That demonstrates why matching counts is insufficient. Real reconciliation may require version, amount, state transition, ownership, and ordering checks as well. Use approved minimized evidence rather than exporting customer tables into a general document. Name the authoritative source for each invariant; otherwise two restored copies can disagree with no shared rule for deciding which state should win.

confirmed = {"r1", "r2", "r3"}
restored = {"r1", "r2", "r4"}
print("counts_equal", len(confirmed) == len(restored))
print("missing", sorted(confirmed - restored))
print("unexpected", sorted(restored - confirmed))

counts_equal True
missing ['r3']
unexpected ['r4']

Align recovery points across dependent state

Check whether database, event log, object metadata, index, and external acknowledgement evidence refer to compatible points. Rebuilding a derived index from an authoritative store may be valid in one design and unsafe in another if required events were lost. Review message replay and idempotency before processing backlog, because a consumer may repeat already completed effects. Missing keys or schema metadata can make an artifact unusable even when its bytes are intact. Escalate uncertain authority or irreversible side effects instead of choosing the newest-looking file.

Plan a reviewed reconciliation rather than silent edits

Define the affected population, intended invariant, proposed correction, authorization, audit evidence, reversibility, and user communication before any real repair. Prefer a dry-run diff in an approved isolated workflow. Separate restoring missing authoritative data from rebuilding derived views or resolving duplicate external effects. A manual edit can hide the symptom while breaking a different relationship. Keep the incident’s remaining correctness work owned even if availability has recovered. This guide supplies only a local set comparison; it executes no reconciliation, data mutation, restore, or administrative action.

Keep it from recurring

• Include cross-store consistency, required keys and metadata, version compatibility, and external-effect reconciliation in the recovery contract. Rehearse the full authorized isolated path and retain tested-version limitations. Keep invariant fixtures with the application so changes to the data model also update recovery acceptance criteria.