Backups That Have Never Been Restored Aren't Backups

Most leadership teams believe their data is protected because a report says so. Every morning an email arrives, or a dashboard turns green, and the word "successful" appears next to the backup job. Nobody has opened a backup file in a year, and nobody has timed how long a full recovery would take.

That gap is where the damage happens. A backup is a promise to recover, and a promise nobody has tested is only a hope. The first real restore attempt should not happen during a ransomware incident, a failed server, or an accidental deletion of the shared drive.

Why a Successful Job Proves Very Little

A backup job reports success when it finishes copying the data it was pointed at. That is a narrow claim. It does not tell you whether the right data was selected, whether the copy can be read, or whether anyone can bring it back in a usable state within a time the business can tolerate.

Backups fail quietly in predictable ways:

• The scope is wrong. A new file share, a new SaaS application, or a new server was added after the backup was configured, and nobody added it to the job.
• The data is corrupt. The job copied a damaged file or an incomplete database, and the error only appears when the file is opened.
• The credentials are gone. The encryption key, the backup console password, or the administrator account that holds them belongs to a person who left.
• The backups are reachable by an attacker. Backups sitting on the same network, under the same administrator login, can be encrypted or deleted along with everything else.
• The restore takes too long. The data is intact, but pulling several terabytes over a standard internet connection takes days, not hours.
• Nobody knows the order. Applications depend on each other, and restoring them in the wrong sequence produces a system that starts and does not work.

None of these shows up as a failed job. All of them show up on the first real restore.

What the Data Says

The published evidence points the same way. Backblaze's 2024 State of the Backup survey, which polled 300 IT decision-makers in the United States, reported that only 61 percent of restore attempts met the desired outcome. That is a vendor survey and a modest sample, so read it as a direction rather than a precise rate. The direction is uncomfortable: roughly four in ten restores in that sample did not fully succeed.

Government guidance treats testing as a core requirement, not an extra. The joint CISA and MS-ISAC #StopRansomware Guide recommends maintaining offline, encrypted backups of critical data and regularly testing the availability and integrity of those backups in a disaster recovery scenario. It also notes that most ransomware actors try to find and delete or encrypt accessible backups, which is why offline copies matter. NIST's Contingency Planning Guide for Federal Information Systems (SP 800-34 Rev. 1) says backup media should be tested regularly to confirm data is stored correctly and can be retrieved without error, and it calls for exercises where personnel actually recover a system from backup media.

Neither document is written for a 60-person company. The principle still scales down: you do not know a backup works until you restore from it.

What an Untested Backup Costs at Your Size

Take an illustrative company with 80 employees, each carrying a loaded cost of $60 per hour. If a failed recovery leaves the team unable to work effectively for three business days, the payroll cost of the idle time is 80 people times 8 hours times 3 days times $60, or $115,200. That figure ignores lost revenue, missed client deadlines, overtime to catch up, and any ransom or forensic fees. It is an illustration, not a measured result for any company, so replace the inputs with your own headcount and rates.

Now compare the cost of prevention. A quarterly restore test of a few critical systems typically takes a technician a few hours per cycle. The exact figure depends on your environment, but the order of magnitude is hours, not days, and it is a predictable line item instead of an emergency.

Define the Target Before You Test

A restore test needs a pass mark. Two numbers set it, and both should come from the business, not from the technician.

• Recovery point objective (RPO): how much recent data you can afford to lose. If the answer is "no more than a day of work," backups must run at least daily.
• Recovery time objective (RTO): how long each system can be unavailable before the cost becomes unacceptable. Email might tolerate a few hours. The system that issues invoices might not.

Most growth-stage companies have never written these down. Without them, "the restore worked" has no definition. The test either meets the target or it does not.

A Restore Test You Can Run This Quarter

The sequence below works for a company with a handful of critical systems and no dedicated recovery team.

1. List the systems that matter. Rank the top five by business impact: file storage, email, line-of-business applications, the accounting system, and the identity directory are typical. Test in that order.
2. Write the RPO and RTO beside each one. Get the number from the executive who owns the process, not from IT.
3. Check what is actually protected. Compare the backup scope to a current inventory of servers, file shares, and SaaS applications. Anything missing from the backup is your first finding.
4. Run a file-level restore. Pick several files of different ages and sizes, restore them to a separate location, and open them. This catches corruption and permission problems.
5. Run a full-system or application restore. Rebuild one critical system in an isolated environment. Record the start time, the end time, every manual step, and every problem.
6. Compare the result to the target. Did the recovered data match the RPO? Did the recovery finish inside the RTO? If either answer is no, you have a documented gap and a basis for a decision.
7. Write the runbook as you go. Capture the exact steps, the credentials location, and the restore order so that a person who did not run the test could repeat it.
8. Fix the findings and schedule the next test. Assign an owner and a date to each gap, then put the next test on the calendar before closing this one.

The point of step 5 is the stopwatch. Companies are often surprised to learn their recovery takes two days when they assumed two hours.

What to Test and How Often

Different tests prove different things. A simple schedule keeps the effort proportionate.

Test	What it proves	Suggested cadence
Backup scope review	New systems are covered	Quarterly
File-level restore	Data is readable and intact	Monthly or quarterly
Full application restore	The system comes back and works	At least twice a year
Full recovery exercise	People and process meet the RTO	Annually

NIST's guidance calls for annual testing of recovery capabilities and personnel for systems where the impact of an outage is significant. For most growth-stage companies, the file-level and scope checks are cheap enough to do more often, and the full exercise is the one that tends to get skipped.

Four Protections to Confirm While You Are Testing

A successful restore is necessary, not sufficient. While the test is under way, confirm these four things.

1. At least one copy is offline or immutable. If an attacker with administrator credentials can delete every copy, you have a single point of failure disguised as redundancy.
2. Backup credentials are separate and documented. The backup console should not share a login with the general administrator account, and the recovery keys should be stored somewhere more than one trusted person can reach.
3. SaaS data is in scope. Microsoft 365 and Google Workspace data is not automatically covered by a traditional server backup. Confirm who protects email, files, and calendars, and for how long.
4. Alerts reach a person. A failed job that sends an email to an inbox nobody reads is the same as no alert.

What to Ask Whoever Runs Your Backups

You do not need technical depth to run this review. You need five questions and written answers.

• What is in scope, and what is not?
• When was the last full restore test, and where is the record?
• How long did it take compared with our target?
• Where do the recovery credentials and keys live, and who can access them?
• What happens if the backups themselves are attacked?

A confident provider answers these with documents. A hesitant one answers with reassurance. Either answer is useful information.

Where This Fits in Leadership

Backup testing sits in the gap between operations and strategy. Your managed service provider or internal team usually runs the jobs and monitors the results. Deciding how much data loss is acceptable, how long an outage the business can absorb, and how much to spend closing the difference is a leadership decision, and it rarely has an owner.

Elevaire Systems works as Fractional IT Leadership alongside your existing managed service provider or internal team. The provider keeps the environment running. The leadership layer sets the recovery targets with the executive team, owns the restore-test schedule, reviews the results, and brings the gaps to a budget conversation before an incident forces one. It connects the Infrastructure Modernization work already in place to a recovery outcome you have actually seen.

Frequently Asked Questions

How often should we test restoring from backups?

Review backup scope and restore a sample of files every quarter, run a full application restore at least twice a year, and hold a full recovery exercise annually. Increase the frequency after any major change, such as a migration, an acquisition, or a new line-of-business system.

How much does restore testing cost?

For a company with a handful of critical systems, a quarterly test usually takes a technician a few hours, plus a short review with leadership. Costs vary with environment size and whether you need a temporary recovery environment. The expense is small and predictable compared with the cost of a failed recovery.

How does this work alongside our existing MSP or IT team?

Your provider or internal team continues to run the backups and perform the technical restore. A Fractional IT Leadership role defines the recovery targets, schedules the tests, reviews the evidence, and escalates gaps to the executive team. The two roles are complementary, and the provider's work gets a clear, measurable standard to meet.

Does Microsoft 365 or Google Workspace back up our data for us?

Not in the way most people assume. Both platforms protect against their own infrastructure failures, but retention and recovery of deleted or overwritten content is limited and governed by your plan and settings. Confirm in writing what is retained, for how long, and whether you can restore a single mailbox or file to a point in time.

What is the difference between a backup and disaster recovery?

A backup is a copy of data. Disaster recovery is the plan, systems, and people that turn those copies back into a working business within a target time. You can have backups without a recovery capability, which is why testing the full process matters more than testing the copy alone.

How do we get started?

Pick your single most important system and run one full restore in an isolated environment with a stopwatch. Record how long it takes, what broke, and what steps were undocumented. That one test produces a concrete list of gaps and shows leadership what the real recovery time is, which is the basis for deciding what to fix first.