- A backup job can finish without proving that the files are complete, clean or quick to restore. A small restore test turns hope into evidence.
- Choose one useful service, restore a safe copy away from production, time each step and check that real work can continue with the recovered data.
- Record what failed, who owns the fix and when the next test will run. Keep protected copies offline or otherwise out of reach of normal admin accounts.
A green backup report can give a false sense of safety. It may show that a job ran, but it does not prove that every file is present, clean or easy to restore.
That gap matters during a cyberattack, cloud error or failed device because a team may find a missing password, damaged copy or very slow restore. The worst time to learn this is during the outage.
A restore test is a planned recovery of selected data into a safe test area. It proves that the backup can support real work, and a small team can run a useful first test in about an hour.
Why restore proof matters now
Recovery has become a business issue, not just an IT task. In July, the UK government formally launched a Cyber Resilience Pledge that makes cyber a board responsibility and asks firms to raise security standards across their supply chains.
US guidance points in the same direction. CISA tells organisations to keep protected backup copies and test restore steps on a regular basis. NIST places recovery beside protection and response in its Cybersecurity Framework. Its small business guide helps teams use that framework without a large security programme.
Competitor coverage often focuses on backup products or broad recovery plans. The missing step for many small teams is a narrow test with a result they can show. That is the focus here.
Start with one business service
Do not begin with every system. Choose one service that matters and is safe to test. Good first choices include a shared project folder, a customer document set, an accounting export or a small website database.
Name the person who owns the service and the person who runs the restore; they may be the same person in a small company. Add someone who uses the recovered data because that user can tell you if the files are useful, not just present.
Write one clear goal. For example: “Restore yesterday's customer documents into a separate folder within 45 minutes, then open five files and confirm their latest approved versions.”
Set two time targets
Two plain terms help define success. Recovery time objective, or RTO, is how long the service can be unavailable. Recovery point objective, or RPO, is how much recent data the business can afford to lose.
If a backup runs each night, the RPO may be up to 24 hours. If the team needs the service back within four hours, that is the RTO. These are business choices. A tool cannot set them on its own.
Use honest targets because a one-hour promise is weak if no one has timed the full restore. The first test gives you a measured starting point.
Run the 60-minute restore test
Keep the first exercise small. Restore away from the live service. Use a new folder, test account, spare device or isolated cloud space. Do not write recovered data over the current copy.
| Time | Action | Evidence to keep |
|---|---|---|
| 0–10 min | Confirm the data set, owner, target time and safe test location. | Scope, date, people and test limits. |
| 10–30 min | Find the backup, get the needed access and start the restore. | Backup date, copy location and start time. |
| 30–50 min | Open files, compare versions and check any linked settings or records. | Items checked, errors and screenshots without sensitive data. |
| 50–60 min | Record the end time, remove the test copy and assign each fix. | Result, owner, due date and next test. |
Do not use a single easy file as the whole test. Pick a small set with different sizes and types. Include one recent item and one older item. If the service depends on a key, licence, app version or database setting, check that too.
Watch the steps that need one person's memory. A restore guide should say where the copy lives, who can approve access and which order to follow. Keep the guide available when the normal systems are down.
Check that the data is safe and useful
A finished download is not enough. Open the recovered files with the normal app. Check dates, names and file sizes. For a database, run a few known queries and confirm that linked records still match.
Look for signs of damage or unwanted changes. CISA advises teams to use offline, encrypted backups because ransomware often tries to delete or encrypt reachable copies. Before a recovery after an attack, confirm that the backup and the test area are clean.
Do not reconnect a recovered system to production just because it starts. Check security updates, accounts and logs first. Use a separate admin profile for the recovery work, as explained in our admin browser profile guide.
Test cloud and SaaS backups too
A cloud service may protect its own platform without giving your team a simple way to recover a deleted record. Ask what the service backs up, how long it keeps copies and whether you can restore one user, one folder or only the whole account.
Ask the vendor to show restore evidence, not just a policy page. Our software vendor evidence checklist covers useful questions about incidents, updates and tested controls.
Check who can start a restore. That account needs strong sign-in protection and a tested recovery path of its own. The passkey readiness checklist can help during a renewal review.
Turn one test into a repeatable habit
Write the result in one page. Record the goal, backup date, start and finish times, items checked, problems found and next action. Do not mark a partial restore as a pass.
Give each problem an owner and a date. Common fixes include adding a missing password to an approved vault, changing backup retention, updating a restore guide or buying more recovery capacity.
Run a small sample restore each month. Test a wider service each quarter and after a major system change. Rotate the person who follows the guide. If only its author can use it, the guide is not ready.
The goal is not a perfect drill. It is a tested path back to useful work. One honest restore result is worth more than a dashboard full of green backup jobs.
Sources and further reading
- CISA: StopRansomware Guide
- NIST: Cybersecurity Framework 2.0 for Small Business
- UK NCSC: Backing up your data
- UK Government: Cyber Resilience Pledge
Frequently asked questions
How often should a small business test a backup restore?
Test a small sample each month and run a wider service restore at least every quarter. Critical systems or major changes may need more frequent tests.
What is the difference between a backup check and a restore test?
A backup check confirms that a job ran and files exist. A restore test proves that selected data can be recovered, opened and used within an acceptable time.
Can a restore test damage live data?
It should not. Restore into a separate test area, use read-only source access where possible and set clear limits before the test begins.