The backup dashboard says the job finished last night. That's encouraging. It doesn't yet tell you whether someone can recover the right version of a missing file and get back to work.
You can check that without deleting anything important. Start with a small, approved restore exercise in a separate location. The aim is to find awkward surprises while the original files are still safe.
The NCSC's backup guidance for small organisations says you should know how to restore your backup and check that it contains the information you need. The exercise below is our suggested way to make that check manageable.
Pick a question your test can answer
“Do our backups work?” is too broad for a first attempt. Try something smaller, such as: “Can we recover an earlier copy of an ordinary project folder and open its documents?”
Choose a person who understands the files and an authorised person who can operate the backup service. That might be two people, or you and your IT provider. Agree the scope before anyone presses a restore button.
For a first rehearsal, use a clearly labelled test folder containing fictional information. Include a short document, a spreadsheet with a simple calculation and a small image. Make sure the folder is covered by the actual backup job you're testing. A folder backed up through a different route won't answer the same question.
Write down what each file should contain. For example, a fictional stock sheet could contain three items whose quantities add up to 27. After the scheduled backup completes, you have something specific to compare against.
Keep the exercise away from live work
Ask the administrator to confirm that your product supports restoring to a separate, approved location. Follow its current instructions. Don't assume a button labelled “restore” will create a spare copy.
Check the destination, account, selected date and overwrite options before starting. If the product can only replace live data, stop and arrange a suitable test environment or a different approved method with the provider. Don't delete an original file to make the test feel realistic.
Some systems need more care than ordinary documents. Restoring an accounting database into a running application, for example, can affect current records or integrations. Leave application and whole-system recovery to a separately planned test with someone who understands that system.
Keep the destination private. A recovered file deserves the same protection as the original. If a later exercise needs genuine business information, get approval, choose the smallest useful sample and restrict access. Don't use customer records simply because they're easy to find.
Recover the version you intended
Ask the administrator to select the agreed backup date and restore the test folder. Note when you requested it, when the restore started and when the files became usable.
Those are different timings. A restore that takes five minutes after an hour spent finding the right account is an hour of waiting from the user's point of view.
Open the restored copies from the test destination and check:
- The folder contains every expected file.
- The document opens and includes the expected text.
- The spreadsheet opens, shows the expected values and calculates correctly.
- The image is readable.
- The recovered version matches the chosen backup date.
- The intended test user can open the files without giving everyone access.
For this fictional stock sheet, a total of 27 is a useful check. A file with the right name but different contents should prompt investigation, not a tick in the completed box.
Find out what the backup actually covers
While you have the provider's attention, ask which folders and services are included. Be specific about shared drives, email, online documents and information held inside business applications.
The NCSC's guidance on backing up cloud services cautions against relying solely on previous versions or deleted-file recovery. It recommends an independent copy in another safe place or service. Check what your own arrangement provides rather than assuming a cloud logo settles the question.
A useful conversation might reveal that shared project folders are protected but files on an employee's desktop aren't. Write down that gap and decide whether to move those files, extend the backup or change how the team works.
Also ask how long versions are kept. A successful recovery from yesterday doesn't establish that you can recover a mistake discovered six weeks later.
Leave a short record somebody can use
A small test doesn't need a long report. Record the date, what was tested, the chosen backup, the destination, the result and any follow-up owner. Keep account passwords and recovery secrets out of this note.
Be precise about the result. “Three fictional files restored and checked” is honest. “Business recovery proven” would claim much more than the exercise demonstrated.
If something fails, keep the original data and existing backups intact. Ask the provider to investigate the failed step, make an agreed change and repeat that part of the test. Don't solve a restore problem by casually changing retention or deleting old backups.
When the checks are complete, remove the extra test copies according to your agreed process. Leave any required evidence of the test without retaining unnecessary data.
Put another check in the diary and choose a different important data type next time. Repeat relevant checks after changing a provider, moving files or changing the people responsible. Over time, those modest exercises can give you a much clearer account of what you can recover, who can do it and where you still need help.