Your backup says it succeeded. Can it actually restore?

Reviewed August 2026.

The short answer

A successful backup job proves that a process ran. A restore test proves that the saved data is usable, that the required systems and credentials are available, and that somebody knows how to put the business back together.

Those are different claims.

The Cybersecurity and Infrastructure Security Agency recommends maintaining protected backups and regularly testing their availability and integrity in a recovery scenario. The practical reason is simple: the first complete restore should not happen while the business is already down. See CISA’s #StopRansomware Guide.

Four questions hidden inside “Do we have backups?”

Is the right information being copied?

A backup may protect the shared drive and miss the cloud application that now holds the real business record. It may copy Microsoft 365 files but not the line-of-business database, device configuration, accounting attachment, or encryption key required to use them.

Start with the business services, not the backup product. For each critical activity, identify the data, application, configuration, identity system, and outside provider it depends on.

Is a clean copy protected from the same failure?

A copy that is always reachable from the ordinary administrator account may be exposed to the same mistake, compromise, deletion, or ransomware event as the original. Ask what prevents an attacker—or a well-intentioned administrator—from changing or deleting every available copy.

“Cloud” does not answer that question. Isolation, separate administration, retention, and deletion protection do.

Can it be restored into something usable?

Recovering files is not the same as recovering a working service. The business may also need software installers, licenses, encryption keys, network settings, service accounts, DNS records, vendor access, and a clean place to restore into.

The restore test should reveal those dependencies while there is still time to obtain them.

Can it be restored soon enough?

Ten hours may be excellent for an archive and unacceptable for the system that schedules patients, takes orders, or produces payroll. The business must decide how much data it can afford to lose and how long each service can be unavailable. Only then can a provider say whether the backup design meets the need.

A useful first restore test

Do not begin with an elaborate disaster exercise. Choose one representative recovery that matters and can be performed safely.

Name the business service. “Shared files” is better than “the server”; “customer scheduling” is better than “the database.”
State the expected result. Identify the date or recovery point, what must open or run, and the maximum useful recovery time.
Choose an isolated destination. Do not overwrite current production data to prove that yesterday’s copy exists.
Have the normal operator perform the work. A test that only the backup vendor’s senior engineer can complete reveals a real dependency.
Open and use the result. Check representative documents, permissions, application functions, and required integrations—not merely that files appeared.
Record the evidence. Note the recovery point selected, start and finish time, people involved, failures, missing credentials, vendor calls, and corrective actions.
Fix the test, then repeat it. A failed exercise is useful when it produces a correction and a successful retest.

Test more than one layer

Over time, recovery exercises should cover the different shapes of loss the business actually faces:

One file or mailbox item: Proves that ordinary accidental deletion can be handled quickly without turning it into a broad outage.
A folder or user account: Checks permissions, ownership, retention, and whether related information returns together.
A critical application: Tests the database, configuration, licenses, service accounts, and vendor dependencies required for real operation.
A complete system: Shows whether the organization can rebuild onto clean infrastructure when the original device or environment cannot be trusted.
A provider or location outage: Tests how people will work when the normal office, internet connection, cloud tenant, or service provider is unavailable.

Not every test belongs on the same schedule. The frequency should follow the rate of change, the importance of the service, the business’s tolerance for loss, and the obligations that apply to its data.

Warning signs worth resolving

The provider can show successful jobs but no recent restore evidence.
Nobody at the business knows which systems are included or excluded.
All backup administration uses the same accounts and identity system as production.
Retention is described only as “daily” without explaining how many recovery points remain.
The plan assumes the original server, tenant, office, or provider will still be available.
Recovery depends on credentials, encryption keys, licenses, or documentation the business does not control.
The contract says backup is included but does not say who performs restore tests or what recovery work costs.

None of these automatically means the backup product is bad. They mean the recovery claim has not yet been demonstrated.

What to ask your provider

Ask for plain answers and evidence:

Which business services and data sources are protected?
What is intentionally excluded?
How many usable recovery points exist, and who can delete them?
What copy remains if ordinary production accounts are compromised?
When was each critical service last restored and used successfully?
Where could a complete system be recovered if the original hardware or tenant were unavailable?
Who initiates recovery, who performs it, and what support or after-hours charges apply?
What recovery time has actually been demonstrated rather than estimated?

A good provider should welcome a bounded restore test. It is easier to fix a missing permission, expired license, or incomplete runbook on an ordinary Tuesday than during the worst Friday of the year.

Bottom line

A backup is an input. Recovery is the business outcome.

Choose a representative service, state what successful recovery means, restore it somewhere safe, use the result, and record what happened. The test does not need to be theatrical. It needs to be real enough to replace confidence with evidence.