Backup and restore gate

There is no verified backup/restore drill in this repository. This document prevents an unsafe assumption from becoming an operational procedure.

Before a migration, destructive repair, or production restore

The accountable operator must attach an approval packet containing:

1. Exact environment and database branch/project identifiers.
2. Confirmed point-in-time recovery retention and the observed recovery-point timestamp.
3. A pre-change restore/snapshot reference and who can perform the restore.
4. The migration or repair SHA, expected schema/data effect, and validation queries.
5. A tested non-production restore result, including elapsed time and data-integrity checks.
6. A rollback decision: code-only revert, branch restore, or escalation if neither is safe.

Restore execution boundary

A restore changes provider/database state and is not executed from this repository or by this runbook. After an approved operator performs it, independently verify the restored branch, application configuration, health endpoint, and a read-only business-critical smoke path before any traffic or configuration change.

Evidence retention

Keep the approval, provider recovery record, before/after schema evidence, exact commit SHA, validation output, and verifier disposition with the release or incident ticket. Do not put connection strings, backup contents, or credentials in the ticket.