How do you know if your backup actually works?

Why doesn't a successful backup job prove you can recover?

Because a backup job and a recovery are two different things. The job confirms data was copied to the backup target. A recovery needs that copy to be complete, uncorrupted and usable, and it needs a process people can follow under pressure.

Picture it: every night the dashboard shows green ticks. Then a server fails, and the restore stalls because the encryption key isn't where anyone expected, or the database comes back without the configuration the application needs. The backup was fine. The recovery wasn't. That's why any backup as a service worth paying for is judged on restores, not ticks.

Surveys show how common that gap is. In the Unitrends State of Backup and Recovery Report 2025, more than 60% of organisations believed they could recover from a downtime event within hours; only 35% could. Veeam's Data Trust and Resilience Report 2026 found that 90% of organisations were confident they could recover from a cyber incident, yet only 28% of ransomware victims fully recovered all affected data.

Recovery failures usually come down to three causes:

1. Incomplete scope: a system, database or configuration was never in the backup.
2. Corrupt data: the job succeeded, but the copy was damaged by storage faults or interrupted writes.
3. Missing dependencies: the restore needs software, licences, encryption keys or identity settings that aren't available.

Automated checks catch the first two. The third only shows up when you actually restore.

What are the levels of a backup recovery test, and how often should you run them?

There are three levels, each proving more than the last. Test critical systems at all three, and less critical systems at the first two.

Treat these as a starting point, not a rule. Also test after every significant change: a migration, a new system, a software upgrade or a change to the backup configuration.

Official guidance points the same way. The CISA #StopRansomware Guide tells organisations to "regularly test the availability and integrity of backups in a disaster recovery scenario". The NCSC UK small organisations guide says that once you've made a backup, you need to know how to restore it and check it contains all your important data. Many organisations still test rarely: Unitrends found that 25% test disaster recovery once a year or less.

For a level 3 test, see how a structured disaster recovery service runs failovers on standby infrastructure.

How do you run a backup restore test, step by step?

Pick a scenario, restore it into an isolated environment exactly as documented, then check and time the result. The goal is to find problems while nothing is on fire.

1. Choose the scenario: a file from last month, a database, or a complete server.
2. Use an isolated environment: a separate network so the restored system can't clash with production.
3. Follow the written procedure: no shortcuts and no help from the one person who knows it by heart.
4. Time every step: from the decision to restore to users being able to work.
5. Validate the data: open the files, query the database, log into the application.
6. Check the recovery point: how recent is the newest restored data?
7. Record the result: what worked, what failed, what took longer than planned.
8. Fix and retest: update the scope, configuration or runbook, then repeat.

Step 5 is where many tests stop short. The AWS Well-Architected reliability guidance (REL09-BP04) lists "restoring without validation" as an anti-pattern, alongside assuming that recovery time and data loss meet your targets without measuring them.

What if the test fails?

A failed test is useful information; a failed recovery during a real incident is the disaster. Find the cause (configuration, missing scope, corrupt backup or missing documentation), fix it and run the same test again until it passes.

With Mindtime, you can boot a backed-up VM instantly in an isolated recovery environment on a separate, clean network, which makes level 2 tests far less disruptive.

How do you check your backup is complete?

Make a recovery inventory, a list of everything you'd need to restore after a total loss, and compare it with what's actually in the backup. Anything on the list but not in the backup is a gap.

Completeness means more than the data itself. For each type of system, check:

• Servers and VMs: operating system, applications, configuration, data and licence information.
• Microsoft 365: Exchange mailboxes, OneDrive, SharePoint sites and Teams. Leavers' accounts count too.
• Databases: the data plus the schema, stored procedures, views and the jobs that depend on them.
• Endpoints and NAS: the files people keep outside central systems.
• Recovery essentials: encryption keys, admin credentials, runbooks and supplier contacts, stored where you can reach them when production is down.

Review the inventory whenever you add a system. New SaaS apps and shadow databases are where gaps usually appear. See what's involved for Microsoft 365 backup and SQL Server database backup.

Which metrics show your backup and recovery strategy is effective?

Measure outcomes, not activity. The key numbers are how often restores succeed, how much data you'd lose and how long recovery takes, compared with targets you've agreed with the business.

Two targets anchor everything. RPO (recovery point objective) is how much work you can afford to lose, measured in time. RTO (recovery time objective) is how long a system can be down. Set both per system, then measure against them. Our guide to RTO and RPO explains how to choose them.

The last row matters more than it looks. Veeam's 2025 Ransomware Trends report, as reported by Intelligent CISO, found that only 10% of attacked organisations recovered more than 90% of their data. Restore tests prove the process works; an immutable copy that follows the 3-2-1-1-0 rule makes sure there's something left to restore.

What evidence do NIS2, GDPR and auditors expect?

Regulators and auditors want proof that you can restore, not a statement that you back up. That means dated test records, results against your targets and a trail of what you fixed.

GDPR Article 32(1) requires "the ability to restore the availability and access to personal data in a timely manner" (point c) and "a process for regularly testing, assessing and evaluating the effectiveness" of security measures (point d). NIS2 Article 21(2)(c) requires "business continuity, such as backup management and disaster recovery, and crisis management" for essential and important entities. Read more about what Article 21 asks for.

A useful evidence file per system holds:

• The agreed RPO and RTO, and who signed them off.
• Backup job reports and how failures were handled.
• Restore test records: date, scope, duration, result and fixes.
• Proof that at least one copy is immutable and stored separately.

This is where automation helps. At Mindtime every backup job is checked automatically and monitored 24/7. With our disaster recovery service, a certified engineer validates the first test failover, typically within 10 days, and automated DR tests run every quarter with evidence for your auditors.

What to do next

An untested backup is an assumption. Start small this week: restore one file from a month ago and time it. Next month, restore a whole server into an isolated network. Then write down your RPO and RTO per system and track the metrics above against them.

If you'd rather not run all of this yourself, see how backup as a service handles checks, immutability and restores, or read why cloud storage isn't the same as backup.

Want to see a test restore and the evidence it produces? Book a free 15-minute demo, in Dutch, German or English.

This article is information, not legal advice.