On this page
You have backups running every night. Your dashboard shows green checkmarks. You sleep well knowing your data is safe.
Then something goes wrong. A ransomware attack encrypts your files, a server fails, or an employee accidentally deletes a critical folder. You go to restore and discover the backup is corrupted, incomplete, or restores to a format your current systems can no longer read.
This scenario plays out more often than you would expect. Industry surveys consistently find that a significant percentage of backup restores fail on the first attempt due to corruption, misconfiguration, or infrastructure changes. That should make every business owner sit up and pay attention.
Why Untested Backups Fail
A backup that has never been restored is just a file you hope works. Here are the most common reasons untested backups fail when you actually need them.
Corruption and Silent Failures
Backup jobs can report success even when the underlying data is corrupted. Storage media degrades over time. A backup file that was perfectly good six months ago might be unreadable today. Without testing, you will not discover this until the worst possible moment.
Misconfigured Backup Scope
Your business changes constantly. New applications get installed, new databases get created, new folders get shared. If your backup scope was configured two years ago and never revisited, there is a good chance critical data is not included. It is common for businesses to discover during a restore that critical data was never included in the backup scope — new databases, recently created shared folders, or application data that was added after the backup was originally configured.
Infrastructure Drift
The server you backed up six months ago was running Windows Server 2019. You have since upgraded to 2022. The database was on SQL Server 2017 and is now on 2022. Your backup image may not restore cleanly to hardware or software that has changed since the backup was taken. This is called infrastructure drift, and it is one of the sneakiest reasons restores fail.
Ransomware Encrypting Backup Files
Modern ransomware specifically targets backup files and backup infrastructure. Attackers know that if they can encrypt or delete your backups along with your production data, you have no choice but to pay. The Sophos State of Ransomware Report (2024) found that 94% of ransomware attacks attempted to compromise backups, and 57% of those attempts were successful.
If your backups sit on the same network as your production systems with no air gap or immutability, they are a target.
How Often to Test Your Backups
At minimum, you should be testing backups quarterly. Here is a realistic schedule based on what we implement for our managed IT clients across Thunder Bay and Northwestern Ontario.
Suggested Backup Test Schedule
| Test Type | Frequency | What You Are Validating |
|---|---|---|
| Full system restore | Quarterly | Can you rebuild a server from backup? |
| Individual file restore | Monthly | Can you pull a single file from a specific date? |
| Application-level restore | Quarterly | Does your accounting software, EHR, or CRM actually work after restore? |
| RTO/RPO validation | Semi-annually | Does the restore complete within your target recovery time? Is the data loss within your acceptable window? |
| Offsite/cloud backup verify | Monthly | Is your offsite copy current and accessible? |
Your Recovery Time Objective (RTO) is how long you can afford to be down. Your Recovery Point Objective (RPO) is how much data you can afford to lose, measured in time. If your RPO is four hours but your backup only runs nightly, you have a gap. Testing is where you discover these gaps before a real disaster forces the issue.
What to Test and How
Full System Restore
This is the gold standard. Spin up a test environment (virtual machine or isolated network segment) and restore an entire server image. Boot it up. Log in. Verify that applications launch, databases connect, and users can access what they need.
If you cannot do this successfully, your backup is not protecting you.
Individual File Restore
Pick a random file from a random date in the last 30 days and restore it. This tests the granularity and integrity of your backups. It also confirms that your backup retention policy is actually retaining data for as long as you think.
Application-Level Restore
Restoring files is one thing. Getting your line-of-business application to actually function after a restore is another. Databases need to be consistent. Configuration files need to match. Licensing may need to be re-validated. If you run practice management software, accounting systems, or any application with a database backend, test this specifically.
RTO/RPO Validation
Time the entire restore process from start to finish. If your business continuity plan says you will be back online in four hours, prove it. The IBM Cost of a Data Breach Report (2024) found that organizations with tested incident response plans saved an average of $2.66 million USD compared to those without.
How DVG Systems Tests Backups for Clients
When you work with us as your managed IT provider, backup testing is built into the service, not left as something you have to remember to do.
We use a layered backup stack:
- Image-based and file-level backup for servers and workstations, with automated verification built into every backup job
- Mailbox and Microsoft 365 backup covering Exchange, SharePoint, OneDrive, and Teams, held independently of Microsoft’s native retention policies
Every quarter, we perform full restore tests in isolated environments and document the results. Every month, we run file-level and application-level spot checks. If a test fails, we fix the issue and retest before the next cycle.
We also configure immutable backup copies that cannot be modified or deleted during their retention window, even by an account with administrative rights on your network. Immutability is the fallback when everything else is compromised; it protects the copy, and the restore tests above are what prove the copy is worth having.
Build Your Own Backup Testing Plan
If you are managing backups in-house, here is a simple template to get started:
- Document your backup scope — List every server, workstation, cloud service, and database that is being backed up. Identify anything that is missing.
- Define your RTO and RPO — For each critical system, decide how long you can be down and how much data you can lose. Write it down.
- Schedule your first full restore test — Block time this quarter to restore a full server image to a test environment. Time it.
- Assign ownership — Someone specific needs to own the backup testing process. If nobody owns it, nobody does it.
- Document and review — After every test, record what worked, what failed, and what changed. Review these records before your next test.
If you do not have a business continuity plan that covers backup and recovery, download our Business Continuity Planner to get started.
The Bottom Line
Backups are not a checkbox. They are a promise to your business, your employees, and your clients that you can recover from the worst day. But a promise you have never tested is just a hope.
Test your backups. Test them regularly. Test them realistically. And if you want a partner who builds testing into the process from day one, talk to us about disaster recovery.
Your future self will thank you.