Backup restoration drills
Check what the backup does not include
A protection policy covers configured resources, not automatically the whole application. Review the missing dependencies before accepting the recovery plan.
In this article
Trace one stored business record
Choose a record with attachments, permissions and an external reference. Identify where each part lives and how it is protected.
A database row may point to an object that has a different retention policy. Its access may depend on an identity mapping stored elsewhere. The external reference may describe an effect that cannot be undone by restoring local data.
Use this trace to build the recovery dependency list. It is often more revealing than starting with a list of backup-enabled resources.
Inspect configuration and key recovery
Determine how the application configuration, secrets and encryption authority become available in the recovery environment. Not every backup mechanism includes them.
Check whether access depends on the environment assumed to be unavailable in the scenario. The recovery identity and key path need to survive that failure.
Keep the required application artefacts and compatible schema procedure discoverable. A data archive without runnable, compatible software may not meet the recovery objective.
Examine consistency across stores
If data stores are backed up at different times, explain how their restored states are reconciled. A database can reference a file created after the selected object-storage recovery point.
Define the application behaviour for such mismatches. Silent missing attachments or duplicated external actions should not be accepted merely because each individual restore job succeeded.
Review deletion and corruption scenarios as well as infrastructure loss. Replication may reproduce a damaging change quickly, so a current replica is not always a clean recovery source.
Require a demonstrated task
Ask for evidence that an authorised user completed the agreed workflow after restore. Include the selected recovery point, achieved time and missing work.
Review failures and manual interventions, especially those relying on undocumented access or personal knowledge. Assign fixes before presenting the result as a dependable procedure.
Approve the plan according to the scenario it actually demonstrates. Avoid broad claims of recoverability when the exercise only restored one resource and never connected it to the application.
Primary sources
PostgreSQL: continuous archiving and recoveryAWS Backup: restore testingReferences checked 11 September 2026.