Recoverable system state
A backup is a protected copy of data, configuration, software, metadata, keys, and recovery information needed after loss or corruption. Restore is the verified process that reconstructs service from selected copies. A successful backup job does not prove recoverability.
Scope and isolation
Inventory databases, files, object versions, identity and policy configuration, certificates, keys, schemas, software artifacts, infrastructure definitions, dependency versions, deletion state, and recovery instructions. Define consistency across related stores.
Protect backup credentials and consoles separately from production. Use offline, immutable, or logically isolated copies where the threat needs them. Encrypt, authenticate, inventory, monitor, and test access.
Restore and validation
Restore into an isolated clean environment. Verify integrity, schema, keys, permissions, retention and deletion state, policy, identity lifecycle, routes, and application behavior. Write new data only with current formats and keys. Reconcile transactions after the recovery point.
Prove that old sessions, credentials, removed accounts, revoked keys, vulnerable artifacts, and attacker persistence do not return.
Failure and residual risk
Replicas copy corruption and are not independent backups. Encryption without key recovery makes data unavailable. Broad backup operators can read all data. Long retention can resurrect expired personal information. Testing against production can overwrite current state. Clean data can restore onto compromised infrastructure.
Backups do not replace rebuildable artifacts, dependency inventory, or recovery authority.
Pomerium boundary
Pomerium configuration, keys, certificates, and deployment state follow the selected deployment and secret-management model. Operators must back up only what recovery needs, protect access, and test clean rebuild and policy restoration. Application data and identity-provider state have separate owners.
Evaluation checklist
- Does the backup include consistent data, schema, policy, keys, artifacts, infrastructure, deletion state, and recovery instructions?
- Can a compromised production identity alter or delete every backup copy?
- Has restore run in isolation with current identities, policy, keys, retention, and negative access tests?
- Can old compromise, revoked authority, vulnerable code, or expired data return through the copy?
- Do measured recovery time and data loss meet the stated service objectives?
