Your first restore test
A backup you've never restored from is a hope, not a plan. VaultGuard Backup takes that seriously enough to run a restore test for you every week. This article shows you how to run one yourself right now, what it does, and how to read the result.
What a restore test is
Before a backup runs, VaultGuard picks about fifty of your real files from the folders where your own things live: Documents, Desktop, Pictures, Downloads, Videos, Music. It prefers documents, photos, video and audio, and it deliberately includes a few awkward ones (long names, unusual characters, large files) because those are the ones that break restores. It records exactly what each file looks like.
After the backup, it pulls those same files back out of the backup, puts the copies in a separate folder, and compares each one to the original. If they match, the backup works. Not "the backup ran." Works.
Running one yourself
Open VaultGuard Backup and go to the Dashboard tab.
Click Restore Test.
A dialog asks which backup to test: Primary (the backup on your backup drive), Copy (your second copy), or Both. Pick one. If you only have a backup and no second copy yet, Primary is the one.
Let it run. It mounts the backup, pulls the files out, compares them, and writes a report. A few minutes on most computers; longer if the backup drive is slow or the copy is in a cloud-synced folder.
When it finishes, the console names the report, and the summary dialog offers to open it. Say yes.
Where things land
Everything goes in C:\RestoredFiles.
The restored copies of your files are there, so you can open one yourself. That's the point of leaving them: you don't have to take the report's word for it. Open a document, open a photo. If it opens and looks right, you've just done the thing most people never do.
The report is an HTML file in the same folder, named for the test and the date, for example:
C:\RestoredFiles\VaultGuard Backup - Primary Restore Test - 2026-10-03.html
Reports are kept, so you build a record over time. If anyone ever asks "how do you know your backup works," that folder is the answer.
Reading the report
Each file gets one of three results.
Matched. The restored copy is identical to the original. This is what you want to see, and on a healthy backup it's all fifty.
Did not match. The file came back out of the backup, but it's different from the original. One or two of these can be harmless: a file you edited between the backup and the test will show up this way, because the original changed, not the backup. Several of these, especially on files you haven't touched, mean the backup didn't store them correctly, and that's a backup you shouldn't trust until the next one runs clean.
Not found. The file wasn't in the backup at all. Usually this is a file that was created or moved after the backup ran. If files you've had for months come up Not found, the backup isn't covering the folder they live in, and that's worth an email to me.
The report also shows the backup version that was tested and when, so you know which backup the result applies to.
What happens on its own
You don't have to do this by hand after today. The restore test is the last link in the weekly backup chain: backup, fingerprint, check for changes, restore test. It runs on the schedule you set, and its result shows on the Backup Restore Test card on the Dashboard. If you keep a second copy, the copy chain does the same thing to the copy and shows it on the Copy Restore Test card.
A passing restore test is the single biggest thing in the Safety Score, because it's the only part that proves the backup works instead of assuming it. A score that won't climb usually means the test hasn't run yet on the current backup. Running one now, the way this article describes, is the fastest way to move the number.
If the test fails
If VaultGuard can't pull files out at all, the report says why, and the card on the Dashboard turns red with the reason. The common ones: the backup drive isn't plugged in, the backup is still being written, or the backup failed its fingerprint check (in which case the restore test won't run, because a backup that's changed since it was made shouldn't be trusted). Fix the cause and run the test again; it doesn't need a new backup to re-run.