Backup restore testing means actually restoring data or a whole system from backup and confirming it comes back complete, consistent and within the time you need. A "backup succeeded" notification does not prove a backup can be restored. A proper test covers files, databases and full servers, follows a written scenario, runs on a schedule and is recorded.
You have backups — but can you actually come back from them?
In most companies backup works like this: a job runs overnight, a "successful" email arrives in the morning, and nobody ever opens that backup again. The problem surfaces the day a server fails or ransomware encrypts the file share. The backup file will not open, the database comes back inconsistent, nobody has the encryption key, or the restore takes days rather than hours.
The gap between a successful backup and a successful restore opens up for many reasons. The list of folders being backed up was written years ago and a newer application sits outside it. A database was copied at file level while it was running, or the licence for the backup software has since lapsed. None of this is visible until you actually try to restore.
We explained the 3-2-1 rule and immutable copies against ransomware in ransomware protection and 3-2-1 backup. This article focuses on the last and most often skipped part of that strategy: the test itself.
What happens if you never test? The cost in numbers
The gap between confidence and reality shows up in the numbers. According to the Data Trust and Resilience Report 2026 from backup software vendor Veeam, based on a survey of more than 900 senior IT, security and risk leaders:
90% of organisations surveyed said they were confident they could recover from a cyber incident, yet only 28% of respondents hit by ransomware fully recovered all affected data; on average just 72% of affected data was recovered.
Plans are weak on testing, too. Veeam's 2025 Ransomware Trends and Proactive Strategies Report survey of 1,300 organisations found that although 98% of respondents had a ransomware playbook, only 44% included backup verification and frequency in it.
Attackers go after backups deliberately. According to Sophos: The impact of compromised backups on ransomware outcomes, based on the security vendor's State of Ransomware 2024 survey of 2,974 IT professionals, 94% of surveyed organisations hit by ransomware said the attackers tried to compromise their backups, and 57% of those attempts succeeded. Median recovery costs for organisations whose backups were compromised were eight times higher than for those whose backups were untouched. A test must show not only that the backup exists but that it would survive an attack.
Set the target before you test: RPO and RTO
A test that does not know what it is measuring produces no result. Write down two targets for every critical system:
- RPO (Recovery Point Objective): how much data loss can you accept? "The last four hours" for accounting, "end of yesterday" for the file server.
- RTO (Recovery Time Objective): how quickly must the system be running again? "The same working day" for ERP, "a few hours" for the website.
Agree these figures with the business units; targets chosen by IT alone tend to be either expensive or inadequate. You then compare each test result with the targets: if the backup shows six hours of lost data and the RPO is four hours, the test has failed.
| Test type | What you do | What it proves |
|---|---|---|
| File-level restore | Randomly chosen files and folders are restored to a separate location | The backup is readable and its scope is right |
| Database / application restore | The ERP, accounting or CRM database is restored to a test server and the application connected | The data is consistent and the application runs |
| Full system restore | A server or virtual machine is rebuilt from scratch in an isolated environment | The RTO is realistic |
| Disaster recovery drill | A scenario is played out with the business as if the primary system were gone | People, credentials and procedures are ready |
How to test backups: an eight-step restore plan
- Map the scope. List critical systems: the file server, ERP and accounting databases, email, the website and, in production, SCADA projects and recipe data. Note where each backup lives and how often it is taken.
- Write RPO and RTO targets. Agree them system by system with the relevant business unit.
- Prepare an isolated test environment. Never restore over the live system. Use a separate virtual machine, a separate network segment or a temporary cloud environment.
- Write the scenario. For example: "Restore the accounting database from yesterday's backup, connect the application and check the last five invoices." Make it clear who does which step with which tool.
- Restore and time it. Start the clock when you begin retrieving the backup and stop it when the system is usable. Time spent hunting for passwords, encryption keys or licences counts.
- Verify the result through business eyes. Do the file counts match, does the database open, are the latest records there? Ideally the check is done by someone who uses the system every day.
- Record it. Date, system, restore point, elapsed time, issues found and owner. This record is your most valuable document both at audit and during a real incident.
- Close the findings and schedule the next test. Give every issue an owner and a deadline, and put the next test date in the calendar now.
The problems tests uncover most often
- Systems outside the scope: a newly installed application, critical spreadsheets on someone's desktop, data held in a cloud service.
- Inconsistent database backups: databases copied at file level while the application was running fail to open or open incomplete.
- Lost keys: the backup is encrypted, but the key sits on the same server as the backup, or on a leaver's laptop.
- Unrealistic timings: the backup is held off site and downloading it over the internet takes days.
A common misconception among companies moving from a file server to the cloud is to confuse sync with backup. A synced cloud folder faithfully syncs deleted or encrypted files too. Version history protects against accidental overwrites, as we explain in document version control, but it is no substitute for an independent, separately held backup.
How often should you run each test?
Frequency depends on how critical a system is and how quickly it changes. A sensible starting framework:
| Test | Suggested frequency |
|---|---|
| Check backup jobs for success or failure | Daily, with automatic alerts |
| Random file restore | Monthly |
| Critical database and application restore | Quarterly |
| Full system restore and disaster recovery drill | At least annually, and after every major infrastructure change |
Major changes — moving servers, a cloud migration or switching to a new ERP — call for an extra test regardless of the calendar. In factories, backups of the SCADA server and PLC programs need separate attention; we cover the specific OT risks in OT security for SCADA.
Well-kept restore test records are also among the most concrete evidence in an ISO 27001 audit that backups are genuinely being tested.
Backups contain personal data as well, so data past its retention period should not live on indefinitely in them; we discuss that balance for email in email archiving and data protection. If a backup containing personal data falls into unauthorised hands, that may itself count as a personal data breach and trigger the notification process described in KVKK data breach notification within 72 hours; losing access to backups should also be logged as an incident and assessed from that angle.
How we handle backup testing at Digital Bridge
We do not start a backup project with "are backups being taken?" but with "if this system failed tomorrow morning, how many hours would it take to come back, and how much data would we lose?":
- Discovery and needs analysis. Through our cloud migration and infrastructure consultancy, we map your critical systems, existing backup jobs and where the backups physically sit, and write RPO and RTO targets with your business units.
- Resilience against attack. As part of our cyber security consultancy, we review who can access the backup system, MFA for administrators and whether you hold an immutable or offline copy.
- Pilot test. We run the first restore test with your team on the single most critical system — usually the ERP or accounting database — time it and report the findings.
- Integration and continuity. We document test scenarios, the record template and the schedule, and include project and recipe backups for SCADA and HMI systems in production. If you run a reporting platform, we also bring the recoverability of your data warehouse sources into scope.
In our own product family, Smart360, SmartFiles provides the first line of defence against accidental deletion and overwriting: every file uploaded under the same name becomes a new version, earlier versions can be restored, and folders as well as files come back from the recycle bin. Even so, we recommend placing these features alongside your organisation's independent backup and testing plan, not in place of it.
Next step
Run one test this month: pick your most critical system, restore yesterday's backup into an isolated environment and time it. The elapsed time and the gaps you find will show the true state of your backup strategy. To plan the test together, get in touch. For the remaining basics, see our SME cyber security checklist and the Cyber Security & Compliance hub.