The only way to know: test it. Not assume it.
The backup runs every night. All the green checkmarks are there. The IT manager sleeps soundly. But has anyone ever actually tried to restore something?
This is the most common vulnerability in backup strategy: the difference between "the backup runs" and "we can recover." These are two fundamentally different things. And most organizations discover this difference at the worst possible moment — in the middle of an incident, under maximum pressure.
According to the State of SaaS Backup and Recovery Report 2025 by Spanning/Kaseya, more than 60% of organizations believe they can recover from an incident within hours. In reality, only 35% can. The gap isn't in the backup — that runs fine. The gap is in the recovery process that has never been practiced.
Key Takeways:
• An untested backup is an assumption — not a guarantee. Only 15% of businesses test daily.
• The only way to know whether a backup works is to perform an actual recovery test.
• A good recovery test measures three things: whether the data is there, whether recovery works, and how long it takes.
Why a successful backup is not the same as a successful recovery
A backup job that succeeds confirms that data has been copied to the backup location. That is a necessary but not sufficient condition for recovery.
There are multiple reasons why a backup that "succeeds" may still not be recoverable. Data can be corrupt — copying works fine, but the integrity of the copy isn't validated. The backup may depend on software, licenses, or configurations that aren't available during recovery. The recovery procedure may contain undocumented steps, or steps that work differently than expected.
According to the State of Backup and Recovery Report 2025 by Unitrends, based on research among over 3,000 IT professionals worldwide, only 15% of businesses tested their backups daily in 2025. The rest tested weekly, ad hoc, or not at all. For every organization that doesn't test regularly, there's a gap between assumed and actual recovery capability.
The result: when an incident occurs, recovery time isn't 4 hours as planned — it's 18 hours, because a dependency is missing. Or the backup turns out to be corrupt for exactly the most critical database. Or the recovery process takes twice as long because no one has ever practiced it.
The three most common causes of recovery failures
1. Incomplete backups: not all systems, databases, or configurations are included in the backup scope. This is only discovered during recovery.
2. Corrupt backup data: the backup job succeeds, but the data is damaged by software errors, storage problems, or incomplete writes.
3. Missing dependencies: recovery requires software, licenses, encryption keys, or configurations that weren't included in the backup or aren't available during recovery.
What is a recovery test and how do you run one?
A recovery test is actually performing a recovery operation — not simulating, but really restoring — to verify that both backup and recovery process work as expected.
There are three levels of recovery tests, increasing in completeness:
Level 1: Item-level restore. You restore one specific item — an email, a file, a database record. This verifies the backup contains data and that the recovery process works for small items. Recommended frequency: monthly.
Level 2: System-level restore. You restore a complete system or application into an isolated test environment. This verifies whether the system functions correctly after recovery, whether all dependencies are present, and how long it takes. Recommended frequency: quarterly.
Level 3: Full DR test. You simulate a complete incident: production environment is unavailable, everything must be restored from backup. This is the most complete test — and the only one that demonstrates actual recovery time. Recommended frequency: at minimum annually.
For more information on disaster recovery testing, see our Disaster Recovery page.
Step-by-step: how to run a recovery test
1. Choose a test scenario: what are you going to restore? (specific file, database, complete system)
2. Arrange an isolated test environment that doesn't affect the production environment.
3. Execute the recovery process exactly as documented — use no shortcuts.
4. Measure the time: how long does each step take?
5. Validate the restored data: is everything present, is the data intact, does the system work correctly?
6. Document the results: what worked, what didn't, what took more time than expected?
7. Improve the recovery plan based on the findings.
8. Repeat this process periodically — the test frequency should match the risk profile of the system.
How do you know if your backup is complete?
A backup is complete when it contains everything needed for recovery — not just the data, but also the context needed to use the data.
For a server this means: operating system, application software, configurations, data, and licenses. For Microsoft 365: email, calendar, contacts, files, Teams conversations, SharePoint sites, and Entra ID data. For a database: the data and the structure (schema, stored procedures, views).
A practical way to check completeness is to create a "recovery inventory": an overview of everything that needs to be restored in a complete incident, specified per system. Compare this inventory with what is actually in the backup.
Any system or data source in the recovery inventory that is not in the backup is a gap — a silent vulnerability that only becomes visible at the worst moment.
See our Backup as a Service page for an overview of what systems are included in a business backup solution. For further background, see ENISA Best Practices for Cyber Crisis Management.
What to do when a recovery test fails?
A failed recovery test is not a disaster — it is valuable information. The disaster is a failed recovery during a real incident.
When a recovery test reveals a problem, the next step is systematic: identify the cause, fix the problem, and test again. Common causes include:
Configuration error: the backup software is not correctly configured for the system in question. Solution: correct the configuration and verify with a retest.
Incomplete scope: certain data or systems are not included in the backup. Solution: expand the backup scope and verify completeness.
Corrupt backup: the backup data itself is damaged. Solution: investigate the cause (storage problems, network interruptions during backup), fix the cause, and create a new backup.
Missing documentation: the recovery process is not fully documented, causing steps to be skipped or executed in the wrong order. Solution: fully document the recovery process based on the test experience.
Every recovery test — successful or failed — yields information that improves the backup strategy.
How often should you test a backup?
There is no universal answer to how often a backup should be tested. It depends on how critical the system is, how often the data changes, and what the acceptable recovery time is.
As a rule of thumb for business environments:
Critical systems (financial, production, customer communication): monthly item-level test, quarterly system-level test, annual full DR test.
Important but non-critical systems: quarterly item-level test, annual system-level test.
Archive data: annual spot-check to verify that data is readable and intact.
Additionally, a test should always be run after any significant change to the IT environment: new systems, migrations, software upgrades, or changes to backup configuration.
For organizations subject to NIS2, documenting recovery tests is not just best practice — it is a compliance requirement. Regulators expect evidence that recovery mechanisms have been periodically tested and work
Conclusion
An untested backup is an assumption. The only way to know whether your backup works is to actually perform a recovery test — and repeat that periodically.
The statistic is stark: only 35% of organizations can actually recover within the timeframe they themselves estimate (Spanning/Kaseya). The difference lies in preparation: documented recovery processes, tested backups, and known recovery times.
A recovery test doesn't need to be large or complex. Start with restoring one file from a month ago. If that works, expand to a database, a system, and eventually a full scenario test. Each level of testing provides more certainty — and fewer surprises when it really matters.
Frequently asked questions
How do I know if my backup actually works? +
The only way to know whether a backup works is to perform a recovery test: actually restore data and verify it is complete and correct. Also check whether the recovery process takes the time you expect. A backup job showing 'green' only proves that data was copied — not that recovery will succeed.
How often should I test my backup? +
Test frequency depends on how critical the system is. As a rule of thumb: critical systems (financial, production) need a monthly item-level test and a quarterly more complete test. Less critical systems at minimum annually. Always run a test after significant changes to the IT environment, such as migrations or software upgrades.
What should a good recovery test demonstrate? +
A good recovery test demonstrates three things: that the backup contains the requested data, that the recovery process works correctly and results in a functioning system or file, and how long the recovery process takes. That recovery time is essential: a backup that works but takes 48 hours to restore may not meet business continuity requirements.