Green Ticks Are Not Evidence: Finishing a Real Backup Restore Drill

Most backup systems are judged by a reassuring panel of green ticks. The software reports that a job completed, the repository shows recent activity and the retention policy looks sensible. None of that proves that a file can be found, opened or returned to the right people. Until a restore has been carried out and checked, the backup is little more than a rumour supported by a dashboard.

For a UK SME, the purpose of a restore drill is not to satisfy an auditor or to produce a certificate. It is to answer a plain operational question: if a folder disappeared this afternoon, how long would it take to bring it back, and would the result be usable? The drill below is deliberately narrow. It tests one real target end to end, in an isolated location, and records what actually happened.

Start with one real target, not a sample file

Choose a dataset that matters to the business and that staff would notice if it vanished. A finance folder containing the current year’s ledgers, a project directory with live client work, or a SaaS workspace such as a shared document library are all suitable. Avoid a synthetic test file created solely for the exercise. It will restore quickly and teach you very little.

Define the scope before touching the backup console. For a file share, select a folder with a known number of files and subfolders, including permissions and at least one recently changed document. For a SaaS service, choose a workspace or site with realistic content, sharing settings and ownership. Write down what “complete” means: file count, folder structure, key documents, access rights and metadata. This definition becomes the checklist for verification.

It is also worth identifying who owns the data. A restore drill conducted entirely by IT can miss the person who knows that a particular spreadsheet should be in a certain subfolder or that a client group must retain access. Involve one business user for verification, but keep them out of the technical steps so the test remains realistic.

Restore to an isolated place

Never restore over the live dataset as a first test. The safest approach is to restore to a separate location: a staging file share, an isolated virtual machine, a temporary SaaS site or a dedicated folder with restricted access. The location should be disconnected from normal staff workflows and clearly labelled as a test. This prevents a failed restore from becoming an outage and makes it easier to compare the restored copy with the original.

Record the start time when the restore is initiated, not when the data begins to appear. Note any prompts, credentials, approval steps or supplier interventions required. If the backup platform asks for a decryption key, an administrator account or a support ticket, that is part of the real restore time and should be captured. A restore that takes twenty minutes after a two-hour approval process is not a twenty-minute recovery.

Where the backup is delivered by a managed service provider or SaaS vendor, confirm in advance whether the SME can perform a self-service restore or must raise a request. The drill should follow the same route that would be used in a real incident. Testing a shortcut available only to the provider’s support team would give a misleading result.

Verify completeness, permissions and usability

Once the restore completes, compare the result against the checklist. Count files and folders, inspect the folder hierarchy and open a sample of documents from different dates. Check that the most recent changes are present and that older versions have not replaced them. For SaaS data, confirm that sharing links, group membership and ownership have been restored appropriately, not merely that documents exist.

Permissions deserve particular attention. A restore that returns every file but grants access to the wrong group is not a successful recovery. Check that sensitive folders remain restricted and that business users can reach what they need. If the restored copy is isolated, permissions may need to be adjusted for the test itself; record any changes so they are not mistaken for production settings.

Usability matters as much as completeness. A database may restore without error but fail to start. A document library may contain files that cannot be opened because of encryption or missing dependencies. Test the data in the way the business would use it, even if only on a small scale. The aim is to find inconvenient truths now rather than during a live disruption.

Measure the time honestly

Record the total elapsed time from decision to verified restore. Break it down into request, approval, data transfer, configuration and verification. This breakdown is more useful than a single figure because it shows where delay actually sits. A backup may copy data quickly while the surrounding process remains slow.

Set a restore-time target that reflects business tolerance, not the backup vendor’s marketing. For a finance folder needed to process payroll, the acceptable time may be measured in hours. For a project archive, a day may be tolerable. The target should be agreed with the business owner and written into the runbook. If the drill exceeds it, the gap is a finding, not a failure of the exercise.

Fix the runbook and the contract afterwards

A drill that produces no changes is rarely a thorough drill. Update the runbook with the actual steps, named contacts, credentials location and verification checklist. Remove assumptions that proved false, such as an expectation that a particular administrator would always be available. If the restore required a supplier ticket, note the response time and the escalation route.

Review supplier terms where the drill exposed friction. Backup retention periods, restore request procedures, support hours, egress charges and responsibilities during a recovery should be clear before an incident. If the contract promises backups but not a workable restore process, that distinction matters. The same applies to SaaS services: confirm what the vendor protects, what the customer must export and how long deleted data remains recoverable.

Finally, schedule the next drill. A single successful restore is a snapshot, not a permanent guarantee. Rotating the target dataset and repeating the exercise at least annually, or more often for critical systems, keeps the runbook honest. The green ticks can remain on the dashboard, but they should no longer be the only evidence that the business can recover.