Why a Backup You Have Never Restored Is Only a Hope

Published October 23, 2026 · Last reviewed October 23, 2026

The quiet failures

Backups rarely fail loudly. The software keeps sending a success message, and the only person who notices is the one who needs the data. The four failures below are common enough that they are worth checking before a crisis, whatever product you use.

1. The job covers the wrong things

A backup is configured once, and then the business changes. A new shared drive appears, a department keeps files on a laptop, a new application stores data in a folder nobody added. The job reports success because it backed up what it was told to. The data you care about is simply not in the set.

2. The key is only on the machine that was lost

Most backups are encrypted. If the encryption password, the recovery key or the vendor account that holds it lives only on the server that has been encrypted by ransomware, you hold a perfectly good backup that nobody can open. The same applies to the login for the backup service when it uses the same administrator account that an intruder has taken.

3. Cloud and SaaS data was never in scope

Many businesses assume that their email, files and customer records in an online service are backed up because they are “in the cloud”. Providers keep their service running and offer limited retention and recovery, but the terms differ and the responsibility for your data usually stays with you. Read your provider’s retention terms, and decide whether you need an independent copy. See the 3-2-1 rule.

4. It restores, but not fast enough

A backup that restores in four days is useless to a business that can survive for one. Restore time depends on the amount of data, the speed of the connection or media, and the order in which systems must come back. Estimate it with the restore-time tool and check it against a real test.

The thirty-minute test

Action

Pick one real item for each of three types: a file from a shared drive that changed last week, one mailbox, and one folder from a system used daily. Ask your IT provider to restore each to a separate test location.

Why it helps

Three small restores check coverage, access and the restore procedure without disrupting anyone.

Verification

Open each restored item and confirm it is the right version, complete and readable. Note the time each took from request to open.

Fallback if delayed

If the provider cannot do it this week, ask for a date in writing and diary it.

Action

Find where the encryption key and the backup login are stored, and confirm a second person can reach them without using the machines being backed up.

Why it helps

A restore needs the key. If the key is lost with the server, the backup is a locked box.

Verification

A named person other than your IT provider can show you where the key is kept, and it is off the production network.

Fallback if delayed

Store a sealed printed copy with the owner.

Action

Check that one copy cannot be changed or deleted with the main administrator account. See immutable and offline backups.

Why it helps

Attackers often delete backups first, because without them the victim has fewer options.

Verification

The provider shows the setting or the physical separation, and you see it.

Fallback if delayed

Rotate an external drive offline weekly until a better option is in place.

A hypothetical story

This example is invented to show the pattern. A 20-person firm has a backup job that has reported success every night for three years. After a server failure, the IT contractor tries to restore the accounts folder and finds that it was added to the server in the second year and never included in the job. The folder is gone. The firm recovers some of it from staff laptops and from email attachments, and spends a week rebuilding the rest. A restore test in the first month would have found the gap in a few minutes. After the incident the firm tests three items every month and reviews the job’s scope every quarter.

Make it a habit

Put the test in the calendar: monthly for a sample, and once a year for a full system. Record the date, what you restored and how long it took. The record is what your insurer, your auditor and your future self will want to see. For the planning side, read recovery-time planning. Public guidance such as the CISA ransomware guide and the Canadian Centre for Cyber Security ransomware guidance both stress tested, offline backups for the same reasons.