An Untested Backup Is a Hope, Not a Control: Five Recovery Drills for UK SMEs

The backup console is a reassuring place to visit. Green ticks, a completion timestamp, a total measured in terabytes. None of it answers the only question that matters when a server fails at eight o'clock on a Monday: can we get the business working again, and how long will it take?

An untested backup is not a control. It is a hope with a dashboard attached. The distance between the two is closed by deliberately breaking things in a controlled way and observing the result. The five drills below are ordered by effort, and each one can be run by a UK SME without a dedicated disaster recovery team.

1. File-level recovery: small test, loud signal

Pick a random folder from a live department, not a sample chosen by IT. Restore it to a scratch location and ask the folder's owner to open the files, check the version dates and confirm nothing is missing. Time the whole exercise from request to usable file.

What the result tells you: file restoration should be measured in minutes. If it takes half a day, the problem is usually not the backup engine but the surrounding plumbing, such as an overloaded storage target, a restore path that requires a ticket, or nobody who knows which console holds which data. This test also reveals whether staff know how to ask for a restore, which is a training issue as much as a technical one.

2. Full server restore: the honest one

Choose a representative server, ideally one that matters but is not the finance ledger, and rebuild it from bare metal or image into an isolated network segment. Do not use the production network; the point is to prove the server can return without colliding with live services.

Record the actual recovery time objective achieved and compare it with the figure in the business impact analysis. The most common outcome of this drill is a gap: a four-hour target written in a document, and a fourteen-hour reality that includes locating licences, rejoining the domain and chasing a line-of-business application vendor.

Dependencies are what catch people out. A restored application server is useless without DNS, a domain controller, a licence server or a database that must be brought back in a specific order. Write the order down and keep it with the runbook.

3. Ransomware simulation: restore into a hostile room

A ransomware incident is not a hardware failure, and restoring as though it were is how organisations get encrypted twice. Assume credentials were stolen, assume the attacker had administrative access, and test accordingly.

Ask three questions. Can the backup copy be reached or deleted using a compromised domain account? Is at least one copy immutable or offline, so that a deletion instruction is refused rather than obeyed? And can restored data be scanned in a clean environment before reintroduction, rather than poured straight back onto the network?

This drill usually exposes the weakest link in an SME estate: the backup service account, saved somewhere convenient, with more privilege than it needs. Fixing that is worth more than any additional storage capacity.

4. Offsite and cloud fallback: the test that involves other people

Now assume the office is unavailable. Flooding, a break-in, a failed leased line or a building that cannot be entered will all produce the same requirement: work from somewhere else.

Restore a working set of data through the cloud or secondary site and attempt genuine tasks from a laptop on a domestic connection. Two numbers emerge, and both matter. The first is bandwidth reality: half a terabyte over a contended business line takes far longer than the sales brochure implies, whatever the egress allowance. The second is the cost of getting data out, which some providers charge for generously.

Also test the no-virtual-private-network scenario. If every recovery route depends on a firewall appliance sitting in the flooded building, the resilience is theoretical.

5. Documented ownership: the test of people

Technology rarely fails alone. Someone has to declare a disaster, authorise spending, call the supplier and tell staff what to do. Name that person, then check what happens when they are on annual leave.

Run a ninety-minute tabletop exercise with the operations director, finance and the IT lead. Walk through a realistic scenario: a Friday evening encryption event, a supplier helpline that closes at five, an insurer asking for evidence. The output should be a short list of named roles, contact routes, spending limits and a decision on who speaks to clients.

Turning results into something the board can use

Every drill should produce a one-page record: date, scope, recovery point achieved, recovery time achieved, defects found, owner and due date. Three or four of these pages, collected over a year, are far more persuasive than a supplier assurance statement.

They also have a commercial use. Cyber insurers increasingly ask for evidence of restore testing rather than a description of backup arrangements, and clients completing supplier due diligence ask similar questions. Under UK GDPR, a personal data breach must be notified to the Information Commissioner's Office within seventy-two hours of awareness, which is difficult to do credibly without knowing what data survived.

A cadence that fits an SME

Quarterly file-level restores. A full server restore twice a year. An annual ransomware and offsite exercise, combined with the tabletop session. Rotate the servers chosen so that coverage accumulates rather than repeating the easiest target.

The result worth aiming for is modest and specific: a documented, evidenced recovery capability, tested by people who will actually be in the room, with the gaps known in advance. That is a very different asset from a green tick.