Verify your backups before you need them

A green backup job proves that a product completed a task. It does not prove that the right data was captured, the recovery credentials still work, or a usable file can be returned within the time the business expects.

CISA recommends keeping offline, encrypted backups of critical data and regularly testing their availability and integrity in a disaster-recovery scenario in its StopRansomware Guide. A small organization does not need to rebuild every server each month, but it does need a repeatable path from restore request to verified data.

This drill starts with one file because it is safe, fast, and revealing. It should sit inside a larger testing schedule that eventually covers applications, identity, servers, and full service recovery.

1. Open a real test ticket

Treat the drill like a recovery request, not an administrator browsing the console. Record:

• The system or workload being tested
• The business owner and technical owner
• The expected backup frequency and retention
• The restore point you plan to use
• The recovery-time and recovery-point expectations, if documented
• Who may approve and perform the restore
• A safe destination that will not overwrite production data

Use a normal support account and approval path. A test performed through an engineer’s undocumented emergency login proves the wrong workflow.

2. Pick a representative, non-destructive target

Choose a real object whose successful recovery can be checked without exposing unnecessary sensitive data:

• A spreadsheet from a department file share
• A PDF and its containing folder from a server backup
• A deleted test message from a protected mailbox
• A document from a protected SharePoint site or OneDrive account
• A small database restored to an isolated test instance, if the team has the expertise

Do not restore over the live copy for the first test. Use an alternate folder, recovery share, test mailbox, new site URL, or isolated network as the product allows. Clearly label restored data and limit access to the people running the drill.

3. Verify scope before clicking Restore

In the backup console, confirm the object appears under the expected policy and that usable restore points exist. Check the source name, tenant or server, last protected time, retention, exclusions, and job warnings.

This step catches a common failure: the job is green because it protected exactly what it was configured to protect, but a new share, mailbox, site, or device was never added to scope. If the source is absent, stop and record a failed test. Silently choosing an easier file hides the problem.

Also identify which copy you are testing. An immutable or offline copy can reduce the chance that an attacker alters recovery data, but isolation does not prove the copy is complete or easy to restore. Our comparison of air-gapped and immutable backups explains that distinction.

4. Run a timed single-file restore

Start the timer before authentication and approvals, not after the restore begins.

1. Sign in through the documented admin path and complete MFA.
2. Locate the source and the intended recovery point.
3. Select the alternate recovery destination.
4. Start the restore and capture the job or ticket identifier.
5. Record queue time, processing time, and completion time separately when possible.
6. Have the data owner confirm the result rather than relying only on the backup console.

The elapsed time should include human delay. If only one person can approve a restore and that person is unavailable after hours, that wait belongs in the recovery result.

5. Prove the data is usable

Do more than confirm that a file exists. Open it with the expected application, compare its date and size with the recovery point, and inspect several pages, rows, or records. For data where integrity is especially important, compare a known checksum or perform the application’s consistency check.

Check metadata that matters to the workflow: filename, timestamps, folder structure, permissions, ownership, labels, and links to dependent data. A restored accounting database that opens but cannot connect to its application is not a successful service recovery.

Record what the test did not prove. A single-file restore does not validate bare-metal recovery, directory services, application dependencies, or recovery at ransomware scale.

6. Clean up and close the loop

Remove or securely retain the test copy according to the organization’s data rules. Do not leave a second copy of payroll or client data in an open recovery share. Attach sanitized evidence to the ticket:

Field	Example result
Source	Finance file share
Restore point	Previous nightly job
Destination	Restricted recovery folder
Total elapsed time	18 minutes
Integrity check	File opened; owner confirmed content
Result	Pass with one documentation issue
Follow-up	Add backup-console access for second admin

Assign every gap an owner and due date. Useful failures include missing scope, expired credentials, unavailable MFA, unexpected retention, permissions errors, unreadable data, or a restore that takes longer than the business can tolerate.

7. Expand the test schedule by risk

Repeat the lightweight restore often enough to catch configuration drift, and rotate sources instead of proving the same file-share path every time. Schedule broader exercises for the systems that drive revenue or safety: a whole SharePoint site, a mailbox, a virtual machine, a database plus application, and eventually the recovery sequence for a major outage.

NIST’s Cybersecurity Framework treats recovery as more than copying data back; roles, plan execution, integrity checks, and stakeholder communication all matter. Its CSF 2.0 overview is a useful structure for moving from a file test to an organization-wide recovery exercise.

Bottom line

A timed single-file restore is the cheapest honest test of a backup program. It proves scope, credentials, approvals, timing, and data integrity without risking production. Record the result, fix what failed, and keep expanding the drill until the organization has tested the services it would actually need after an incident.