Two questions, two limits
Ask the business owner how much recent work could be lost and how long the workflow could remain unavailable. Record these as objectives, not promises. A twelve-hour copy schedule cannot by itself support a requirement to lose at most a few minutes of changes. Fast downloading does not establish fast application recovery.
Build the time budget
Include incident detection, permission recovery, finding a suitable copy, download, decryption, database restoration, application validation and the decision to reconnect users. Assign an owner to each stage. Use measured rehearsal times when available; otherwise write unknown rather than squeezing every stage into a reassuring total.
Escalate an architecture mismatch
When the required recovery point falls between scheduled copies, examine point-in-time recovery and its complete log chain. When the service must stay available through a failure, examine replication and failover separately. Neither a marketing label nor a frequent schedule proves those properties.
Fictional planning example
An operations team wants yesterday’s records back within two hours. A rehearsal takes forty minutes to retrieve and ninety minutes to restore, before application checks. The plan misses the time objective even though the backup file is intact. Change the architecture or the agreed objective; do not relabel the failed rehearsal as a pass.
Write a recoverable service objective
Fictional brief: the order-entry workflow may lose at most yesterday’s work and must become usable within four hours. A reporting warehouse can remain unavailable longer. Treat these as two workflows instead of imposing the same expensive target on everything. Record who approved the trade-off and what happens to orders created after the selected recovery point. A technically restored database does not reconstruct missing business activity automatically. Include that reconciliation task in the time budget, and review the objective when the cost of lost work changes.
Sources used for this page
These records support the facts and comparisons above. Merchant-controlled records are labelled so you can separate product claims from independent evidence.
- PostgreSQL: backup and restore — Platform documentation · postgresql.org · Merchant-controlled · checked 2026-10-01
- PostgreSQL: continuous archiving — Platform documentation · postgresql.org · Merchant-controlled · checked 2026-10-01