Set measurable recovery objectives
Agree on the maximum acceptable data loss, or recovery point objective, and maximum restoration time, or recovery time objective. Choose backup frequency and storage protection from these objectives. Include the time to obtain credentials, restore objects, validate data, and reconnect senders. For an initial open source deployment, prefer the supported standalone topology. Splitting roles introduces additional coordination and does not itself establish high availability. Require a demonstrated capacity need and a tested failure plan before adopting a role-split deployment.Protect a complete recovery set
Plan database and object backup consistency together. Confirm that object deletion and garbage collection cannot remove files needed by the database snapshot before the object backup completes. Use the timing and versioning considerations in Backup and restore to choose the backup method.
Rehearse in an isolated environment
Restore into a separate PostgreSQL database and object-storage location. Keep production senders pointed at production. Prevent the restored environment from sending real notifications or running external side effects before starting it. Use the saved image version and matching secrets. Record each stage’s duration and failures. Test historical intervals around the backup boundary, not only the most recent records. Check a known log event, a trace, and any other signal required by the incident response process. Then send controlled new data and query it back. Verify that the restored environment can both read history and accept new writes. Destroy the rehearsal environment only after retaining the evidence needed to evaluate the recovery objectives.Evaluate durability tradeoffs
A more durable WAL policy may increase write latency and storage activity. Measure the tradeoff under representative load and failure conditions before changing it. A persistent volume does not replace database and object-storage backups. Do not treat a successful health check as the end of recovery. Check catalog and object consistency, known data, access permissions, and the controlled write path. Resolve missing-object reports before declaring the restored dataset complete.Acceptance criteria
- Measured restoration time and recovered data boundaries meet the agreed objectives.
- Recovery uses the backed-up key and configuration without exposing secret values.
- Historical queries and controlled new writes both succeed.
- The rehearsal produces no production notifications or external writes.
- A named team owns follow-up actions and repeats the exercise after material storage, version, or topology changes.