The backup report is green. The laptop is gone. Someone asks how long it will take to get the business running again, and the room goes quiet.
The missing information is usually ordinary: which copy contains the right files, who has the credentials, whether the application can read them, and which device will be used for recovery. A backup job cannot answer all of that on its own.
You can learn a great deal from a small, controlled restore exercise. It should take place in an isolated environment, with an agreed owner, and without overwriting production data.
Decide what you need back
“Back up the server” is too broad to test usefully. Choose a business activity: opening a customer order, finding an invoice, recovering a shared project folder. List the pieces that activity depends on.
A database copy may be insufficient if the documents live elsewhere. Application settings, software versions, encryption keys, access permissions and integration credentials can all affect whether the restored system works. Keep secrets in an approved credential system, not a general recovery document.
PostgreSQL, for example, documents several backup approaches with different properties. Its SQL-dump guidance also distinguishes an individual database from cluster-wide objects such as roles. The wider lesson is to verify the coverage of the method you actually use. PostgreSQL backup documentation, SQL dump details.
Make two business decisions
First, decide how much recent work the business could tolerate losing. Second, decide how long the activity could be unavailable. These are separate questions.
A daily copy might be acceptable for a small document archive. It might be a poor fit for a system recording orders throughout the day. Recovering yesterday's data in ten minutes and recovering current data in ten hours are very different outcomes.
Use those decisions to discuss an appropriate arrangement with the people responsible for recovery. Avoid choosing a sophisticated backup product before anyone has agreed what recovery needs to achieve.
Run a bounded exercise
Choose an agreed recovery point and an isolated destination. Ensure the restored application cannot accidentally send customer emails, process live payments or synchronize old records into production. If there is any uncertainty, have the responsible technical team set up the exercise.
Record when the request begins, when the copy is found, when it is restored, and when a business user confirms the chosen task works. The last timestamp is especially useful. “Files copied” and “work resumed” can be a long way apart.
Ask the user to check a known record, open an associated attachment, and confirm the permissions are appropriate. Do not stop at a successful login page.
Write down what surprised you
| Observation | A useful follow-up |
|---|---|
| Only one person could access the backup | Establish an approved recovery-access process |
| Files restored but the application would not start | Document versions and dependencies |
| The copy was older than expected | Investigate scheduling and failure notifications |
| A folder was missing | Revisit the coverage list |
| Restoring took longer than the business could tolerate | Revisit the architecture or the recovery target |
Do not edit the result to make the test look successful. A discovered gap is the point of the exercise. Assign an owner and a date to each correction, then repeat the relevant part of the test.
Keep the evidence small and usable
Your recovery record needs the date, the system, the selected copy, the task tested, the elapsed time, the result and the unresolved actions. It does not need customer data or passwords.
Schedule another test when the system changes materially. A migration, new storage location or change in access can invalidate an old assumption. Choose an ongoing test frequency based on how important and changeable the system is.
Ask your provider a straightforward question: “Can you show me the last successful restore test for the activity we depend on?” If the answer is a screenshot of a completed backup job, you still have a test to arrange.
Have a version of this problem?
Let’s talk it through.