A backup file is not a recovered service
Your dashboard says the backup completed. Then a customer record is deleted, an upload becomes unavailable, or a server fails. Can the team recover the information and resume useful work?
Test a business task, not just a database import. A restored order table is incomplete if staff cannot open the attached delivery document, sign in, or tell which orders were already fulfilled.
This is a recovery exercise for an existing application. It complements the software handoff checklist, which asks whether another team can run the system. Here the question is whether that team can recover it from saved data under an agreed failure scenario.
Set the scenario and recovery goals first
Choose a concrete event: accidental deletion, loss of the application server, or loss of the primary data store. A test for one event does not prove readiness for all of them. A full-environment disaster test can follow once the smaller recovery path works.
Name the workflow that must return first. For a hypothetical delivery operation, that might be viewing current orders and their delivery details. Reporting could wait. The business owner should decide that order of priority.
Record two targets:
- Recovery point objective (RPO): how much recent data the business can afford to lose, expressed as time.
- Recovery time objective (RTO): how long the business can wait for the agreed service to return.
These are targets, not measured results. Backup frequency alone does not establish the actual recovery point: a recent backup may be incomplete or unusable. Record the latest recoverable business record and compare it with the incident reference time.
Tie the targets to a concrete business consequence: orders that cannot ship, staff unable to serve customers, or records that must be rebuilt manually. Use your own operating data to estimate disruption, and distinguish delayed revenue from revenue actually lost. If a customer agreement or launch review requires recovery evidence, schedule the test before that decision. Do not invent an incident probability to make a cost formula look precise.
Build an isolated test environment
Use an environment separated from production. Restrict access to restored customer data and agree how long the test copy may remain. Confirm storage and encryption-key access before the test, with an authorized backup operator available if the usual engineer is absent.
Block outbound customer email, SMS, payment calls, and live webhooks. Disable scheduled tasks and queue workers until their destinations and behavior are safe. A restored queue can contain work that production has already completed; replaying it can create duplicate messages or transactions.
Do not point test credentials at production merely to make a test pass. If an external service cannot be exercised safely, record that boundary and plan a controlled separate check.
Restore the parts that belong together
| Part | What to prove |
|---|---|
| Database | Backup imports successfully and required records are present |
| Uploaded files | Referenced attachments exist and can be opened |
| Application version | Restored data works with the chosen code and schema version |
| Configuration and keys | Authorized staff can recover required settings without exposing secrets |
| Background work | Pending work is reconciled before any replay |
| External systems | Recovered state can be compared with the current system of record |
A database and file backup from different times can leave records pointing to missing files. Record their timestamps and check a sample across the relevant period. Count records where useful, but also open actual records and attachments; matching totals can hide mismatches.
Do not blindly run the latest database migrations against the only restored copy. Establish which application version belongs with the backup and preserve a recovery point before testing an upgrade path.
Walk through a real task
Have an authorized user sign in, find a known record, open an attachment, and perform a safe test action. Compare the result with expected data recorded before the exercise. Check permissions as well as visibility: restoring access must not grant every user administrative rights.
For the delivery example, confirm that the order, address, delivery status, and supporting document agree. If production continued after the backup, identify the gap and how staff would reconcile it. The restored database cannot know about later actions recorded only in another system.
Measure time from the agreed incident start point through detection, access, restoration, validation, and readiness to resume work. If you measure only file import time, label it as that component rather than claiming end-to-end recovery time.
Uptime is not recoverability
Multiple application servers and monitoring can reduce some outages while leaving data recovery untested. Somnio’s SaaS availability case study reports 100% measured uptime over a full year after that kind of work, and lists backup and disaster recovery procedures among its technical highlights. It does not publish restore-test timings or a measured recovery point, so treat it as evidence for reliability work, not as a recovery-time benchmark for your application.
Leave a result the next operator can use
Record the scenario, backup timestamps, code version, operator, elapsed times, validation results, missing dependencies, and follow-up owner. Mark the test failed or incomplete when a required business task cannot be completed. A successful import is not a partial substitute for that task.
Record the measured recovery time and data-loss interval beside the agreed RTO and RPO. If either target is missed, record that result even when the application task succeeds, and assign an owner to the follow-up work.
Remove the test data through the agreed cleanup process and retain the test evidence without customer records or secrets. Re-test the failed part after a fix. Set the next exercise date based on business impact and expected changes.
Start by asking your team to show the last completed restore-test record. If there is none, scope one critical workflow with an authorized engineer. For help, bring that workflow to Somnio’s architecture consulting service and ask for a scoped recovery assessment. Agree the deliverable before commissioning it: recovery goals, a dependency list, one test scenario, and a gap list with owners and next checks. The environment and access requirements determine effort and price; confirm those in the proposal.
