We Tested the Backup Restore and Discovered It Only Covered a Tenth of What We Thought

The backup dashboard on my main desktop has said “up to date” for something like two years straight. The first time anyone actually tried to pull a file back out of it, the restore returned three folders: browser credential exports, a password vault backup, and the AI agent’s memory files. No documents. No photos. No tax records. Nothing that would actually hurt to lose.

This came up because a new Windows 2-in-1 laptop needed a backup setup from scratch, and before writing a runbook for a second machine, the obvious move was to confirm the first machine’s backup actually worked. Not confirm the status light. Confirm the data comes back.

The manifest lied by omission

The first pass at verifying coverage was to open the backup client’s own completion log rather than run a real restore. The log listed a set of covered paths and a “backup complete” status with a timestamp from that morning. Every entry showed green. That looked like enough to move on and write the new laptop’s runbook off the same config.

It wasn’t enough. The log was reporting success on the paths it had been told to watch, not auditing whether those paths were the right ones. It had never been pointed at the actual document tree, so of course it had nothing to say about it. Trusting that log cost about an hour: writing half a runbook section that assumed the existing backup scope was already correct, before actually restoring anything and finding out it wasn’t.

The fix was to stop reading about the backup and do the restore. Pick a scratch destination, pull a real copy down, diff it against the source paths on disk. That’s when the gap showed up: only credentials and the agent’s memory/vault files had ever been in scope. Whoever configured the backup years ago had pointed it at “the important small stuff” and never revisited it as the actual working set of files grew around it.

Auditing the disk that was supposed to be the backup

Once the cloud backup’s scope was confirmed too narrow, the next question was what a full local backup would even need to cover. There’s a drive on my main desktop labeled “Backups,” 580GB, that everyone had been assuming was doing that job.

A size-sorted scan of that drive (the Windows equivalent of du -sh */ | sort -rh, run folder by folder from the drive root) turned up the actual breakdown: about 452GB of it, 78%, was Steam game installs. Not save files, not configs, full game directories that Steam would happily re-download from scratch on any machine with the same login. The “backup” drive’s real backup content, once you strip out anything reinstallable from a store, came to roughly 61GB: documents, tax records, photos, local code that hadn’t been pushed to a remote, and the same credential/vault set the cloud backup already had.

That 61GB number is the one that mattered. It reframed the whole problem from “we have a 580GB backup drive, we’re fine” to “we have 61GB of data that cannot be regenerated, and it needs to be the thing we actually verify, not the drive’s total size or its folder count.”

What changed

The runbook that went to the new laptop stopped being “mirror this machine’s backup config” and became a two-part check: first, does the backup’s declared scope actually include the folders a human would grieve losing, checked against a real directory listing, not the client’s own manifest; second, does a restore of that scope, run end to end into a scratch folder, actually produce those files back out. Status lights and completion logs answer “did the job run.” Only a restore into an empty folder answers “does this data still exist somewhere else.”

The Steam-heavy drive got left alone rather than reorganized, because reorganizing 452GB of reinstallable game data wasn’t worth the time against a 61GB actual target. Instead the 61GB set got an explicit include-list in the backup config, and the same restore test got scheduled to rerun periodically instead of being a one-time proof.

None of this would have surfaced from watching the dashboard. It surfaced from doing the thing the dashboard was supposedly already confirming, and finding out the two didn’t match.

dxdev LESSON · paste into your AI coding agent
LESSON: Verify Backup Coverage With A Real Restore, Not The Client's Own Log
SOURCE: dxdev.com/blog/2026-09-13_backup-restore-revealed-scope
WHAT HAPPENED: Before setting up backups on a new laptop, the author checked whether the existing desktop backup actually worked. Reading the backup client's completion log showed all-green status and a fresh timestamp, which looked like enough to copy the config to the new machine. Only after actually restoring files to a scratch folder and diffing against the source did it become clear the backup had only ever covered credentials and vault/memory files, never documents or photos. A separate 580GB 'Backups' drive was also audited by folder size and turned out to be 78% reinstallable Steam game data, with only about 61GB of truly irreplaceable files.
THE RULE: A backup's own completion log or dashboard only reports whether it did what it was configured to do, not whether that configuration covers what you'd actually grieve losing -- so scope and integrity have to be checked against a real directory listing and a real restore, not the tool's self-report.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
      1. Does the backup's declared include-list, checked against an actual directory listing, contain the specific folders you'd grieve losing (documents, photos, tax/financial records), not just what it was originally pointed at years ago?
      2. Has a full restore of that scope been run end-to-end into an empty scratch folder and diffed against the source, rather than trusting the client's completion log or status light?
      3. For any large backup destination, has its content been broken down by size to separate irreplaceable data from reinstallable/re-downloadable content (game installs, cached packages, etc.), so the actual must-protect footprint is known?
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.