How to test your backups, and how often to do it

Why a green tick is not proof

Backup software reports success when it has copied data to its destination. It cannot tell whether that data will be usable when you need it. A database backed up mid-write may restore in a corrupted state. A server image may be missing a driver needed to boot on different hardware. An encryption key may have been lost when the person who set it up left. None of those show up as an error in a nightly report.

The only reliable way to know a backup works is to restore from it and check the result. That sounds obvious, yet many small businesses have never done it. The first time they try is during an emergency, which is the worst moment to discover a missing password or a step nobody wrote down.

Monthly: quick spot checks

Once a month, restore a handful of individual items chosen at random: a document from a shared folder, an email from a few weeks ago, a file from a staff laptop. Restore them to a separate location rather than over the originals, open each one and confirm it is the right version. This takes about twenty minutes and proves that the basic chain of backup and restore still works.

Vary what you pick. If you always restore the same test file, you only prove that one file is protected. Choosing at random across different systems is more likely to reveal that a new shared drive, a recently added user or a moved folder has fallen outside the backup. Note the result of each check, even when everything works.

Quarterly: a whole system or account

Every three months, restore something larger: an entire user's mailbox and OneDrive into a test account, or a full server image into an isolated virtual machine. Check that it starts, that the key application opens, and that recent data is present. For an accounting or practice management system, log in to the restored copy and run a report you know the answer to.

Time the whole process from starting the restore to being able to work. That number is your real recovery time, and it is often much longer than people expect, especially if the data has to download from the cloud over an ordinary business fibre connection. If the time is longer than the business could tolerate, that is a finding to act on, perhaps by adding a local copy for faster restores or by moving the system to a cloud service.

Yearly: a disaster rehearsal

Once a year, walk through a full scenario. Pretend the office is inaccessible and every on-site device is gone. Using only the offsite backups and the written plan, work out how you would get key staff working again: which systems come back first, on what hardware, from which location. You do not need to rebuild everything for real, but you should restore at least the critical systems to prove it can be done.

These rehearsals almost always find something: a licence key that only exists on the old server, a supplier contact that has changed, a step that assumes access to a building. Finding those gaps on a calm Tuesday is far better than finding them after a fire. Update the written plan straight after the rehearsal while the details are fresh, and share the changes with everyone who has a role in it.

Doing it safely

Never test by restoring over live data. Use a separate folder, a test user account or an isolated virtual network so a restored server cannot clash with the real one. Restored systems should not be able to send email, sync to the cloud or connect to the live database, or you risk confusing staff and customers with duplicate messages or overwritten records.

If you use a managed IT provider, ask them to run these tests and send you the evidence. If you manage it yourself, schedule the tests in a shared calendar with a named owner so they survive busy months and staff changes. A test that depends on one person remembering will lapse the first time that person is busy or away.

What to record

Keep a simple restore log: date, what was restored, from which backup copy, how long it took, whether it worked, and any issues found and fixed. Add the name of the person who did it. Over a year, the log shows that your backups genuinely work and gives you a realistic idea of how long recovery takes.

That record is useful beyond your own peace of mind. Cyber insurers, auditors and larger clients increasingly ask for evidence that restores are tested, not just that backups exist. A dated log answers the question in seconds. It also helps a new IT provider or staff member understand quickly how recovery works in your business.