Backups Are Not Recovery Until You Have Restored One

A dashboard showing successful backups is reassuring, but it does not prove that the application can recover. The backup may be incomplete, the decryption key may be unavailable, or the team may not know which sequence of steps restores a usable system. Recovery planning begins with two business questions: how much recent data can be lost, and how long can the service remain unavailable? These are commonly expressed as recovery point and recovery time objectives. ## Match the method to the objective A daily logical database export may be adequate for some internal tools. A service with a much smaller acceptable data-loss window may need a different strategy, such as continuous log archiving and point-in-time recovery where supported. Database recovery is only part of the application. Uploaded files, configuration, encryption material, and dependent services also matter. A restored database containing file references is incomplete if the referenced objects were permanently deleted. Document retention and isolation. A backup stored under the same broadly privileged credentials as the primary data may be vulnerable to the same destructive action. Choose controls appropriate to the risk and verify what your provider actually offers. ## Rehearse in an isolated environment Restore into a separate target that cannot overwrite production. Confirm versions, required extensions, roles, and application connectivity. Keep restored sensitive data subject to the same privacy and access requirements as the original. Measure the entire operation, including finding the correct backup, provisioning capacity, restoring data, validating it, and reconnecting the application. A database command's duration alone understates recovery time. Perform functional checks: can a user sign in, read an important record, and complete a representative workflow? Verify counts and business invariants, not just that the database process starts. ## Plan the cutover and reconciliation Point-in-time recovery can restore data to before a bad change, but legitimate activity after that point may also be absent. Decide how the team identifies and reconciles those operations. Prevent restored background workers from accidentally sending old notifications or repeating payments during the test. Recovery environments should not automatically contact live external systems. Assign responsibility and keep instructions available outside the system that might be down. An incident is a poor time to discover that the recovery guide lives in the inaccessible database. Repeat exercises as the data grows and the architecture changes. A restore that met its target six months ago may take much longer now. A backup is a stored artifact. Recovery is a demonstrated capability involving data, software, people, and time. Test the capability you are depending on, not just the job that produces the artifact. ## Further reading - [PostgreSQL: Backup and restore](https://www.postgresql.org/docs/current/backup.html) - [PostgreSQL: Continuous archiving and point-in-time recovery](https://www.postgresql.org/docs/current/continuous-archiving.html)