Insights / Guide / Cybersecurity and IT resilience
GuideHow to test your backups properly
A backup you have never restored is an assumption. Regular, well-designed restore tests turn it into a fact, and show how long recovery really takes.
Most organisations can show that their backups run. Fewer can show that their backups restore. The daily report says the job completed successfully, and everyone moves on. Then, on the day a server fails or ransomware encrypts a file share, the team discovers that a database was excluded, that the restore takes three days rather than three hours or that nobody remembers the steps.
A backup you have never restored is an assumption. Regular tests turn it into a fact. This guide sets out how to design restore tests that tell you something useful, how to run them without disrupting live systems and how to turn the results into improvements.
What a restore test should prove
A good test answers four questions. Can we get the data back? Is it complete and usable? How long does it take? Can the people likely to be on duty actually do it, using the written procedure? A test that only checks the first question gives false comfort.
- Completeness: the restored data includes everything needed, such as databases, configurations, attachments and permissions.
- Integrity: files open, databases mount and applications run against the restored data.
- Time: the restore finishes within the recovery time the business has agreed for that system.
- Currency: the restored data is as recent as the agreed recovery point, meaning the maximum acceptable data loss.
- Repeatability: someone other than the usual expert can follow the procedure successfully.
Step 1: choose what to test
Pick critical systems and sample files. You cannot test everything every month, so plan a rotation that covers all critical services over the year and includes simpler checks in between.
Three levels of test
- File-level tests, monthly: restore a handful of files and folders from different systems and dates, including older backups, and check they open correctly.
- System-level tests, quarterly: restore a complete critical system, such as the finance application with its database, to an isolated environment and confirm it runs.
- Scenario tests, annually: simulate a realistic event, such as the loss of a site or a ransomware attack affecting several systems, and work through the recovery as a team.
Prioritise by business impact. Start the rotation with the systems whose loss would hurt most, then work outwards. Include data held in cloud services and software-as-a-service applications; these are often assumed to be protected by the provider when they are not, or not in the way you need.
Test in isolation
Restore into a separate environment, not over live systems. A restore that accidentally overwrites current data, or a restored server that starts sending emails or processing transactions, can cause a real incident during a test.
Step 2: time the restore
Record how long it takes and compare with what the business needs. Recovery time is where many plans quietly fail. Restoring several terabytes over a network link or from cloud storage can take far longer than people expect, and the procedure itself may include steps that take hours: rebuilding servers, reconfiguring integrations, re-entering licence keys.
- Start the clock when the decision to restore is made, not when the copy begins.
- Time each stage separately: locating the backup, provisioning infrastructure, copying data, configuring the application and user checks.
- Stop the clock when a business user confirms the system works, not when IT thinks the restore is finished.
- Compare the total with the agreed recovery time objective, and note the gap.
A worked example
Consider a typical mid-sized wholesaler whose business has agreed that the order processing system must be back within eight hours. Its first quarterly test restores the database successfully in two hours. But provisioning a replacement server takes three hours, because nobody had a template ready, and reconnecting the integration with the warehouse system takes another four, because the configuration was not documented. Total: nine hours, plus a long wait for a business user to check orders. The backup was fine. The recovery was not. Two actions follow: a pre-built server template and a documented integration procedure. The next test comes in at under six hours.
Step 3: verify with the business
IT can confirm that files restored and services started. Only users can confirm that the system is genuinely usable. Ask a business user to perform a short set of checks agreed in advance.
- Log in and open recent records, such as yesterday’s orders or invoices.
- Run a standard report and compare totals with a known figure.
- Check attachments, documents and images linked to records.
- Confirm that integrations with other systems are working, or note which ones would need reconnecting.
- Sign off the test, or record what was missing.
Step 4: fix and repeat
Correct problems and test again on a schedule. Every test should produce a short record and, usually, a few actions. The value of testing comes from closing those actions, then proving the fix in the next test.
- Record the date, system, backup used, people involved, time taken by stage, result and issues found.
- Assign each issue an owner and a date.
- Update the restore procedure with anything learned, so the next person benefits.
- Retest any system that failed within a month rather than waiting for its next turn in the rotation.
- Report results and open actions in the regular IT or risk review.
Our first restore test failed, and it was the most useful thing we did all year.
Operations director, logistics business
Common reasons restores fail
Restore tests tend to uncover the same handful of problems. Knowing them in advance helps you design tests that look in the right places, and fix some issues before the first test even runs.
- Missing pieces: the data was backed up, but the application configuration, encryption keys or licence files were not.
- Silent exclusions: a folder, mailbox or database was left out of the backup selection when the system changed.
- Lost credentials: the password for the backup console, the encryption key or the cloud storage account is held by one person, or nobody.
- Slow infrastructure: there is nowhere ready to restore to, so servers must be built from scratch before the restore can begin.
- Undocumented steps: the restore depends on knowledge that sits with one engineer, and the procedure assumes it.
- Compromised backups: backup copies sit on the same network and accounts as live systems, so an attacker could reach them too.
Several of these can be checked on paper before any test. Confirm that backup credentials and encryption keys are stored securely in more than one place, that backup selections were reviewed after the last significant change and that at least one copy is held where ordinary administrator accounts cannot delete it.
Getting started this month
Choose the one system your business could least afford to lose. Agree with its owner how quickly it must be back and how much data loss would be tolerable. Then schedule a restore to an isolated environment within the next four weeks, time every stage and ask a user to check the result. Whatever you learn, write it down and fix it. That single test will tell you more about your resilience than any backup report.
Once the first test is done, publish a simple twelve-month rotation so every critical system has a date, and treat a missed test with the same seriousness as a missed backup.
Source: Intelliversal analysis.
