Steam Installs Filled 452GB of the Drive Called Backups

The backup dashboard on our 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 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.

The log said green, and it was only describing itself

Our first pass at verifying coverage was to open the backup client’s own completion log instead of running 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, so we started writing the new laptop’s runbook off the same config.

It wasn’t enough. The log reported success on the paths it had been told to watch, and it never audited whether those were the right paths. It had never been pointed at the actual document tree, so it had nothing to say about it. Trusting that log cost us about an hour: half a runbook section that assumed the existing backup scope was correct, written before we restored anything and found out it wasn’t.

So we stopped reading about the backup and did the restore. We picked a scratch destination, pulled a real copy down, and diffed it against the source paths on disk. That’s when the gap showed up. Only credentials and the agent’s memory 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 working set of files grew around it.

The “Backups” drive that mostly wasn’t

With the cloud backup’s scope confirmed too narrow, the next question was what a full local backup would need to cover. There’s a drive on our 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) gave us the real breakdown. About 452GB of it, 78%, was Steam game installs. Those aren’t save files or configs. They’re full game directories that Steam will re-download from scratch on any machine with the same login. Once we stripped out anything reinstallable from a store, the drive’s real backup content came to roughly 61GB: documents, tax records, photos, local code that hadn’t been pushed to a remote, and the same credential set the cloud backup already had.

That 61GB is the number that mattered. It turned “we have a 580GB backup drive, we’re fine” into “we have 61GB of data that cannot be regenerated, and that is what we need to verify, not the drive’s total size or its folder count.”

What the runbook became

The runbook for the new laptop stopped being “mirror this machine’s backup config.” It became a two-part check. First, does the backup’s declared scope include the folders a human would grieve losing, checked against a real directory listing instead of the client’s own manifest? Second, does a restore of that scope, run end to end into a scratch folder, actually produce those files? 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.”

We left the Steam-heavy drive alone. Reorganizing 452GB of reinstallable game data wasn’t worth the time against a 61GB target. Instead the 61GB set got an explicit include-list in the backup config, and we scheduled the same restore test to rerun periodically so it isn’t a one-time proof.

A green dashboard or completion log tells you the job ran. It doesn’t tell you the data is recoverable. Here the dashboard and the restore disagreed, and only the restore showed it. Restore into an empty folder, look at the files that come back, and check the declared scope against a real directory listing.

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/backup-restore-revealed-scope
WHAT HAPPENED: Before setting up backups on a new laptop, we 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 password backup and agent 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.