A test that happens when someone remembers
Every contract says backups are monitored, and some promise periodic restore testing. In practice, a restore test happens when a client asks, or after a real restore went badly. An engineer restores a folder to a test location, checks it opens, and writes 'restore test OK' in a ticket note.
When a client's insurer asks for evidence of the last restore test, the account manager searches tickets for the word 'restore' and finds a mixture of real restores and tests, with little detail. Nobody can say when the last full server restore test was done for any client, or how long it took.
Why restore testing slips
Restore tests are important but never urgent. There is no alert when one is overdue, and no standard for what a test involves.
- No schedule per client, so tests happen at random.
- No standard steps, so each engineer tests differently.
- Results recorded as free text in tickets.
- Restore time not measured, so recovery expectations are guesses.
- Different backup products need different test methods.
What untested restores cost
| Untested area | Risk |
|---|---|
| Server image restore | A backup that cannot be booted when it matters |
| Microsoft 365 restore | Mailbox or site restore slower or less complete than expected |
| Application database | Data restored but application will not start |
| Restore time unknown | Recovery promises that cannot be kept |
| No evidence | Awkward answers to insurers and auditors |
What testing each client needs, and what recovery times are acceptable, is agreed between you and the client. The system records the tests against that agreement.
The restore test schedule we build
- A test plan per client: which items to test (file, mailbox, full server, application), how often, and the method for each backup product.
- Test tasks created automatically in your PSA on schedule, assigned to the right team.
- A guided test form: steps for that item and product, with fields for what was restored, where, whether it opened or booted, and how long it took.
- Screenshots or logs attached as evidence, stored in your documentation tool against the client.
- Failures raising a follow-up ticket, and the test repeated after the fix.
- An evidence report per client showing tests done, results and restore times over the past year.
A normal quarter with scheduled tests
Each month, the service desk sees a handful of restore test tasks spread across clients, each with its steps. An engineer restores a server image to an isolated host, confirms it boots and the line-of-business application opens, records the time and saves a screenshot. It takes a planned slot rather than an emergency.
When an insurer asks, the account manager exports the client's evidence report. When a test fails, the problem is found in a quiet week, not during a real incident. And you learn how long restores really take, which tightens what you promise in contracts.
A typical failed test looks like this. The server image boots on the isolated host, but the accounts application will not open because its licence server is tied to the old hardware identity. That is recorded, a follow-up ticket goes to the engineer who looks after the application, and the vendor's recovery steps are added to the client's documentation. The retest a fortnight later passes, and the evidence report shows both the failure and the fix, which is exactly what a careful insurer or client wants to see.
Test types can rotate so the load stays manageable: a file restore one month, a mailbox the next, a full server each quarter, spread across clients so no single week is swamped.
Checklist: your restore testing
- You cannot say when each client last had a restore test.
- Restore tests are recorded as 'OK' in a ticket note.
- You have never timed a full server restore for most clients.
- Insurers' questions about restore testing are hard to answer.
- Tests happen only after a real restore goes wrong.