Backups & the DR drill
Recovery objectives and the one-command point-in-time-restore drill.
By the end you’ll be able to
- Read the RPO/RTO objectives per tier from the DR runbook.
- Understand what `verifyPitr` checks during a drill.
- Know how the audit-log hash chain participates in restore verification.
DataBridge commits to recovery objectives that depend on the customer's tier. `docs/DR_RUNBOOK.md` §1 is the single source of truth; the per-tier table is: free — 24 h RPO / 24 h RTO; pro — 1 h RPO / 4 h RTO; enterprise — 15 m RPO / 1 h RTO. Implementation differs by tier (daily `pg_dump` for free, hourly base + WAL archiving for pro, continuous WAL shipping with a warm standby for enterprise).
A PITR drill is run quarterly per production region (and after any change to backup tooling, Postgres major version, or tenant-schema layout). The drill exercises `@databridge/dr-verifier`'s `verifyPitr(provider, scope, expectations)`: restore the latest point into a `dr_scratch_<timestamp>` schema, then assert that row counts, audit-log chain head, chain integrity, and scratch cleanup all match the values captured at snapshot.
The verifier emits five named checks every drill must pass green: `restore` (the latest restore point was restored), `row-counts` (per-table counts in the restored copy equal the counts captured at snapshot), `chain-head` (restored audit-log chain head hash equals the head recorded at snapshot), `chain-integrity` (`verifyChain` passes end-to-end), and `scratch-dropped` (the scratch schema was dropped and verified absent). Any red check opens an incident and blocks the next release until root-caused.
The audit-log hash chain (`@databridge/audit-log`) is treated as part of every backup scope. A restore that loses or alters chain entries is treated as a failed restore even when the raw row counts match. That is what `chain-head` and `chain-integrity` are for — and that is the difference between an audit trail and an audit *proof*.
Every drill emits a `DrDrillReport` JSON file (`kind: "dr-drill"`, `version: 1`) with a `sha256` content hash computed by `@databridge/compliance-evidence`'s `hashValue` — the same fingerprint scheme the evidence bundles use. That report files into a CH5 evidence bundle unchanged and re-verifies at audit time via `verifyDrDrillReport(report)`.
Walkthrough
- Open admin console
1.Open the admin console
DR drills are run by an operator with `tenant:admin` (or `system:superadmin`). Start from the admin home.
- Open audit log
2.Open the audit log
The audit-log hash chain is what a restore must preserve. Skim a few entries — each one's content fingerprint is what the `chain-head` drill check pins against.
- Open tenant audit log
3.Skim the tenant-scoped view
Open the tenant audit log to see the same chain scoped to one tenant. The drill always runs against a tenant-scoped dataset (never pilot/customer data in a shared environment).
Your turn
Open the cross-tenant audit-log browser and look at the entries. This is the chain whose head a DR drill must reproduce exactly to pass the `chain-head` check.
Hint: Use the 'Open the audit log' step above.