Test Your Backup Restore: A Check That Proves Your Files Can Come Back

Backups · Published 2026-11-02 · Last updated 2026-11-02

When did a file last actually come back from your backup? Not when the backup last ran. When a restore last finished, with a file on screen, opened and readable. If the answer needs thinking about, the backup is currently a hope rather than a system. This guide turns it into a system in one short sitting.

The official guidance is blunt on this point. The US Cybersecurity and Infrastructure Security Agency, CISA, states that regularly backing up data and testing the ability to restore it is a critical part of a cybersecurity strategy, and its backup guidance tells readers to test backup procedures so data can be restored both fully and partially, with the ability to roll back data at least seven days. A home backup deserves the same test, at home scale.

What a green backup status actually proves

A completed job proves a copy operation ran. It does not prove the copy contains the folder you care about, that the files inside open, that an older backup date survived, or that you remember the password if the backup is encrypted. Each of those is a separate failure, and each has bitten people whose dashboards showed green the whole time.

A restore test checks the four layers separately:

• Reach: the backup drive or service can be opened at all, today, with the credentials on hand.
• Coverage: a file changed this week is present in a recent backup.
• Retention: a file is present in an older backup date, not only in the newest one.
• Usability: restored files open in the programs that created them, with content intact.

Pick the sample set before touching anything

A useful test restores a small, deliberate sample rather than whatever file happens to be nearby. A practical restore test set includes one recent file and one folder from a restore point at least 30 days old, restored to an isolated target, with each file opened in its native application and the time and result recorded. At home, adjust the older point to the oldest date your backup keeps if 30 days is beyond its retention, and say so in the log.

Four samples are enough. A test small enough to repeat beats a heroic full restore that happens once and never again.

The restore test, step by step

1. Create a test folder somewhere separate. A new folder on the desktop named Restore Test, with the date, works. Restores in this procedure go there, never over the originals, so a failed test cannot damage the live files.
2. On Windows, restore the recent document with File History. Microsoft documents the path: open File Explorer, go to the folder that contains the file, right click the folder name and select Restore previous versions, pick a version from the list, then expand Restore and select Restore to, choosing the test folder. Microsoft warns that plain Restore replaces the current version and the replacement cannot be undone, which is exactly why Restore to exists and why the test uses it.
3. Restore the older folder the same way, from the older date. In the Previous Versions list, choose a version from the older backup date rather than the newest one. If no older version is listed, retention is shorter than assumed. Log that as a finding, not a pass.
4. On a Mac, restore with Time Machine. Apple documents the path: open a window for the item to restore, for a deleted Documents file that means opening the Documents folder, open Time Machine, use the arrows and timeline to browse backups, select the item, and click Restore. Restored items return to their original location, so for a test, first copy or rename any current file with the same name, then open the restored copy and confirm it is the version expected.
5. Open every restored file in its own program. A document opens in its editor, a photo opens full size, a spreadsheet opens with its figures visible. A file that restores but will not open is a failed sample, however clean the copy progress bar looked.
6. Check the encrypted backup unlocks. If the backup drive is encrypted, the test is also the moment the password or recovery key gets used. Enter it from wherever it is stored. If nobody can produce it, the backup is locked storage, and that finding outranks every other result in the log.
7. Time the restore and write the log entry. Note how long the sample took. That number, scaled up, is the first honest estimate of how long a real recovery day would run.

What success looks like: every sample sits in the test folder or its checked location, every file opens in its native program with content intact, one sample came from an older backup date, the encryption password was produced without a hunt, and a dated log entry records all of it.

Scoring the result without flattering it

Score each layer separately. Reach, coverage, retention, usability: pass or fail, no partial credit blended into a single comforting word. A test that passes coverage and fails retention has found a real problem, a backup that only protects last week. A test that fails reach because the drive will not mount has found the biggest problem of all, early, on a quiet day, which is the entire point of testing.

Fix one failed layer, then retest only that layer within the week. The retest is part of the result. A failure that gets fixed and retested is the system working as designed.

The log entry to keep

Keep the log where the backup itself is described, a note file, a planner page, a notebook. Five lines per test are enough:

• Date of test, and backup dates sampled.
• Samples restored, and where they were restored to.
• Each file opened: yes or no, per file.
• Time taken, and any failure found, in plain words.
• Date chosen for the next test.

CISA describes the 3-2-1 rule as three copies of important files, on two different types of storage media, with one copy stored off site. The restore test is what keeps that structure honest. Copies that have never been opened are arithmetic. Copies that restored, opened, and got logged on 2026-11-02 are a backup.

— Dex Carter, Tech Writer

Back to all guides →