Restore testing
Open the backup dashboard and it is a wall of green. Every job completed, every client protected, every night. Now ask the team when they last restored a full server from that backup and timed it. The room goes quiet.
A successful job proves the software ran. It doesn't prove the data is complete, that the restore works, or that it finishes before the client's business stops. Most MSPs find out during an incident, which is the worst possible day to learn the number. The client has been told a recovery time in a proposal. Nobody has ever timed it.
Gather first: what each client's backups cover and the recovery times you have promised.
The prompt:
Build a restore-testing schedule for our clients, so the recovery times we promise come from real tests instead of the backup dashboard.
What experienced backup engineers know:
A green job status proves the software ran. It does not prove the data is complete, that it restores, or how long the restore takes.
Full-server and cloud workload restores fail in different ways from single-file restores, so a test plan that only restores files misses the failures that matter most.
The number clients care about is time to working again, which includes rebuild, configuration and testing, not only data transfer.
What our backup platform protects for each client: [details]
Recovery times we have promised in contracts or proposals: [details]
Who on the team has restore access and available hours: [details]
Any restores done in the last 12 months and how long they took: [details]
Do this:
Build a quarterly rotation that tests one restore per client, covering files, a full server and a cloud workload across the year.
Write a one-line test record format: what was restored, time to usable, problems found, fix.
Draft a short quarterly note to each client stating the tested recovery time in plain words, and flag any client where the tested time is longer than what we promised.
If a client has no restore history at all, put them first in the rotation and say why.