What the system promises
A backup is a candidate recovery source until someone proves it can restore useful service. Begin by deciding what loss the business can tolerate: how much recent work may need re-entry and how long the service may remain unavailable. These are operational choices to agree with the owner, not promises created by a backup schedule.
Compare the practical options
List everything required for recovery: database, uploaded files, configuration, secrets access and a compatible application version. A database copy alone may not recreate the product. Use a backup method appropriate to the database's active-write behaviour. SQLite documents an Online Backup API for consistent snapshots; copying a live database file without understanding its journal state is not an adequate recovery procedure.
Test the whole journey
Imagine an order application restored into an isolated environment. Check integrity, open representative orders and reconcile their attachments. Start the application with outbound integrations disabled so the rehearsal does not resend real notifications or charge anyone. Measure time from obtaining the backup to completing an ordinary task. Record missing permissions and configuration as recovery defects, even when the database itself opens.
Make recovery visible
Do not rehearse by overwriting the only production copy. Keep the current system protected, identify the exact restore target and require a deliberate destructive step when replacing data. A same-disk backup does not cover loss of that disk. Test access to the separate copy and any required keys; a file nobody can decrypt or retrieve is not available recovery.
Write the recovery sequence before the incident
Begin the recovery note with its purpose and target. Is the team restoring an isolated rehearsal environment, recovering a failed host or replacing damaged production data? Those actions have different consequences. Record where the chosen backup came from, when it was created, its integrity result and which application version is compatible. Keep access instructions separate from the secret values themselves so the procedure can be shared with authorized operators without spreading credentials.
For a production replacement, the procedure should establish a controlled point at which writes stop. Account for the web application, workers, scheduled jobs and any other writer, not just the visible website. Preserve the current state before replacement when that is possible and useful for investigation. Restore to the intended location, check ownership and permissions, and validate the database and related files before admitting ordinary traffic. Bring components back in an order that avoids processing queued work against an incomplete or mismatched dataset. These are steps to rehearse with the actual deployment arrangement, not commands to improvise during an outage.
Define the business checks that follow technical recovery. In the order example, reconcile the latest known orders, attachments and payment references against the chosen recovery point. Identify work that occurred after that point and give it a recovery owner. Do not automatically repeat charges, shipments or messages merely because their local records were restored to an earlier state. The external world did not roll back with the database. Keep unresolved differences visible until reconciled, and communicate the practical impact to the people handling customers. After the exercise, update the procedure with measured elapsed time, access failures and missing dependencies. Test retention and access to a separate backup location too; a flawless restore from a convenient local file does not prove readiness after loss of the host.
Recovery acceptance evidence
| Stage | What must be demonstrated |
|---|---|
| Select the recovery source | The backup identity, creation time, integrity result and intended restore target are unambiguous. |
| Stop writes safely | All known writers are controlled and the existing state is preserved before deliberate replacement where feasible. |
| Reopen useful service | The application can complete a representative authorized task with its related files and configuration, not merely open the database. |
| Reconcile the outside world | Post-backup work and external actions are reviewed before retry, preventing the restore from silently repeating completed business activity. |
Take these examples to review
Who can restore when the usual operator is absent? What data will be lost and how will it be reconciled? Which event triggers rollback rather than continued repair? Bring the last actual restore result to a software-rescue review, including elapsed time and unresolved gaps, instead of relying on a green backup job.