Backups Are Not Recovery: How to Prove You Can Restore Before Ransomware

You prove a backup works by restoring real business data from it and writing down what came back: which system, which backup date, who ran the restore, how long it took, and what failed.

A backup is a copy; recovery is a capability. Until the files, application or system your business depends on has been restored, a backup product can tell you only that a job completed.

That distinction matters for operations, cyber insurance, and leadership trust.

CISA's ransomware guidance tells organizations to maintain offline or separate backups and test them, while the FTC's small-business guidance tells companies to back up important files and keep copies offline or in the cloud.

The missing word in many real environments is restore.

Sources: CISA StopRansomware Guide, FTC Cybersecurity for Small Business

This guide is the small-business version: how to prove that backups can become recovery before ransomware, a hardware failure, or an underwriter forces the question.

The direct answer: what proves you can recover?

You prove recovery by restoring a meaningful sample of business-critical data, documenting the result, and fixing whatever fails.

At minimum, the test record should show:

• What system or data was restored
• The backup date used
• Who performed the restore
• Where the restored copy was placed
• Whether permissions and application access worked
• How long the restore took
• What follow-up work is needed

That record becomes operational evidence and cyber insurance evidence. More important, it teaches the business what recovery would actually feel like under pressure.

Why "backup successful" is not enough

Backup consoles are good at reporting jobs. They are not always good at reporting whether the business can operate from the result.

Common failures include:

• The wrong folder was never included
• The backup captured encrypted or corrupted files
• The person with restore access is unavailable
• The backup console itself requires a password nobody has
• File permissions do not restore correctly
• The database restores, but the application cannot use it
• The internet connection cannot move the data back fast enough
• The only copy is connected to the same environment ransomware hit

None of those problems are theoretical. They are exactly the kind of practical failure that appears only when someone tries to recover.

What to test first

Start with what would stop the business.

For a small business, that may be:

• Finance and accounting records
• Client files
• Practice-management data
• Legal documents
• Payroll data
• Shared drive folders
• Point-of-sale or order data
• Identity and email administration records

Do not test the easiest folder first unless it is also important. The goal is not to produce a pretty screenshot. The goal is to find out whether the business can keep moving.

If you are renewing cyber insurance, this restore test pairs naturally with the cyber insurance renewal calendar. Backups are one of the easiest controls to overstate and one of the hardest to fake when someone asks for evidence.

The one-hour restore test

Here is a useful starter exercise.

Step 1: Pick one critical dataset

Choose something specific:

• "June accounts receivable folder"
• "Sample client matter folder"
• "Dentrix export from last backup"
• "QuickBooks company file"
• "HR policy and payroll folder"

The narrower the sample, the easier it is to complete and document.

Step 2: Restore to a safe location

Do not overwrite production. Restore to a separate test folder or isolated system.

Record:

• Backup date
• Restore location
• Person performing the restore
• Start time
• End time

Step 3: Open the restored data

This is where many backup checks stop too early. Do not just confirm the file exists.

Open it. Check whether it is readable. Confirm permissions. If it is an application file, test whether the application can use it.

Step 4: Record the result

Write the result in plain English:

On 2026-06-29, restored the QuickBooks company file from the 2026-06-28 backup to a test folder. Restore completed in 37 minutes. File opened successfully. Follow-up: confirm monthly offsite retention policy and document who can approve full restore.

That note is more useful than a vague policy statement.

Step 5: Fix one issue

Every restore test should produce at least one improvement:

• Add MFA to the backup console
• Remove stale admin access
• Include a missing folder
• Document the restore steps
• Add a second recovery contact
• Test a larger dataset next month

The test is not a pass/fail ritual. It is a learning loop.

Backup settings that matter in ransomware

Ransomware changes the backup question. The business does not only need a copy. It needs a copy the attacker cannot easily encrypt, delete, or poison.

Prioritize these controls:

Separation

Keep backups separate from the systems they protect. That may mean offline, immutable, MFA-protected, or stored in a different administrative boundary.

Retention

Keep enough history to recover from an attack that started before anyone noticed. If clean copies disappear too quickly, the backup window may not help.

Restore access

Know who can restore, who can approve a restore, and what happens if the primary admin is unavailable.

Console security

Protect the backup admin console with MFA. If the attacker takes over the console, the backup system may become part of the incident.

Malware-aware recovery

Do not blindly restore compromised files into production. Recovery should include a containment decision: what is clean, what is suspicious, and what must be rebuilt.

CISA's ransomware guidance emphasizes preparation, backups, and response planning because these decisions are much harder during the incident.

Source: CISA StopRansomware Guide

Why cloud sync is not the same thing

OneDrive, Google Drive, Dropbox, and similar tools are useful. They are not automatically a complete backup strategy.

The issue is sync. If a file is encrypted, deleted, or changed, that change may sync quickly. Version history can help, but the business still needs to know:

• How far back versions go
• Who can restore them
• Whether admin access is protected
• Whether ransomware can touch the synced location
• Whether the recovery process has been tested

Cloud storage can be part of recovery. It should not be assumed to be recovery.

The evidence pack for cyber insurance

If an underwriter, broker, or client asks whether backups are tested, the strongest answer is short:

Yes. Here is the restore-test record from this date, the system tested, the person who performed it, and the result.

Keep these artifacts:

• Backup configuration screenshot
• Restore-test log
• Backup schedule
• Retention settings
• MFA screenshot for backup admin access
• List of systems covered
• List of systems not covered, with rationale
• Follow-up notes from failed or partial tests

Evidence does not need to be fancy. It needs to be real.

How often to test

For a small business, use this rhythm:

• Annually for every critical system
• Quarterly for the top revenue-critical or compliance-critical systems
• After major system changes
• Before cyber insurance renewal
• After changing backup vendors or MSPs

If the business cannot tolerate a system being down for a day, annual testing is probably not enough.

What to ask your MSP

Ask:

1. Which systems are backed up?
2. Which systems are not backed up?
3. Who can delete backups?
4. Is the backup console protected by MFA?
5. When was the last restore test?
6. What was restored?
7. How long did it take?
8. What failed?
9. Where is the restore procedure documented?
10. Can I have the evidence pack for insurance?

If the answer to question five is "we monitor backups every day," ask again. Monitoring backup jobs is not the same as proving recovery.

Where Obsidian Ridge fits

Obsidian Ridge is not a backup reseller pretending backup equals recovery. The work is operational: identify the business-critical systems, confirm coverage, test a restore path, document evidence, and connect the result to incident response and cyber insurance.

If your renewal is coming up, start with the Cyber Insurance Readiness Questionnaire. If the restore evidence is missing or the backup design is unclear, the Cyber Insurance Readiness Sprint is the faster path to a signed evidence pack.

FAQ

What is the difference between backup and recovery?

A backup is the copy. Recovery is the proven ability to use that copy to restore business operations. A backup that has never been restored is unproven.

How often should small businesses test backups?

At least annually for critical data, and more often for systems that stop revenue, patient care, legal deadlines, payroll, or financial operations.

Is cloud sync a backup?

Cloud sync can help, but it is not automatically a recovery plan. If bad changes sync quickly, the clean copy may be harder to find than expected.

What is a restore-test log?

It is a short record showing what was restored, from which backup date, by whom, where it was restored, whether it opened or worked, how long it took, and what needs follow-up.

Why do cyber insurers care about backup restore tests?

Because backup claims are easy to make and hard to trust without proof. Tested backups reduce uncertainty around ransomware recovery and business interruption.

Sources and references

• CISA StopRansomware Guide
• FTC Cybersecurity for Small Business
• NIST Small Business Cybersecurity Corner