A backup job that succeeded every night and preserved almost nothing

# A backup job that succeeded every night and preserved almost nothing Every log line said success. Every scheduled run completed without error, on time, for months. And when someone finally opened the backed-up files to actually use one, most of them were empty. Zero bytes. This is a real finding from a technical audit, and it's worth walking through because the failure mode is invisible to exactly the kind of check most teams rely on. ## What the Job Was Supposed to Do A shared drive held the organization's working documents — the usual mix of text documents, spreadsheets, and presentations, synced locally through a cloud storage client. A scheduled job copied everything in that folder to object storage on a nightly cadence, as a straightforward disaster-recovery backup. Simple design. Copy the folder, land it in storage, done. The job's own success signal was exactly what you'd expect: did the copy operation complete without throwing an error. Every night, it did. The backup dashboard, if anyone had built one, would have shown a clean streak going back as far as the job had existed. ## Why "No Error" Didn't Mean "Backed Up" Here's the mechanism, and it's worth being precise about it because it's not a bug in the copy tool — the copy tool did exactly what it was told. Cloud-native documents — the kind created and edited directly in a browser-based office suite rather than saved as a traditional file — don't necessarily exist as real files on disk at all. What sits in the locally-synced folder is often a small pointer file: a stub referencing the actual document, which lives entirely in the cloud service's own storage. That stub can be a few bytes. Sometimes effectively zero. A generic file-copy operation doesn't know the difference between a real file and a pointer stub. It sees a file system entry, reads however many bytes are actually present on disk, and copies exactly that. For a real file, that's the content. For a pointer stub, that's next to nothing — and the copy still succeeds, because from the file system's point of view, nothing went wrong. The operation did precisely what a file copy is supposed to do. It just wasn't copying what anyone assumed it was copying. So the job reported success because it was true, in the narrowest possible sense. It copied every file. It just so happened that "every file," for the documents that mattered most, meant a stub instead of the content. ## What Made This Hard to Catch The failure sits in exactly the gap most verification processes don't check. A backup audit typically asks: did the job run, did it complete, does the destination have roughly the expected file count. This job passed all three. File count matched. No errors. Every scheduled run present in the log. None of those questions ask what's actually inside the files. A directory listing that matches the source directory's file count looks like proof the backup worked. It's proof the copy operation touched the right number of entries. Those are different claims, and the gap between them is exactly where a stub file hides — indistinguishable from a real backup unless someone opens the actual content. ## The Fix The mechanical fix is straightforward once the failure mode is named: cloud-native documents need to be explicitly exported to a real file format — the kind that actually contains the document's content on disk — before the copy step runs, not copied as whatever the sync client happens to have materialized locally. That turns the backup from "copy whatever's in the folder" into "export the real content, then copy that," which closes the gap entirely. The verification fix is just as important as the mechanical one: a backup audit has to check content, not just presence. That means periodically opening a sample of backed-up files and confirming they contain what they're supposed to — not just confirming the file exists and has a plausible-looking name in the right place. ## The Diligence Point This is the finding worth generalizing beyond this one backup job: a success signal that only checks "did the operation complete without erroring" is not the same claim as "did the operation produce a correct result." Those two claims look identical from a dashboard. They are not identical in practice, and the gap between them is exactly where silent data loss lives — the kind that only surfaces the day someone actually needs the thing that was supposedly backed up, which is the worst possible time to discover it wasn't. When auditing any backup, sync, or migration process, the question to ask isn't "does this complete successfully." It's "if I open five of the resulting files right now, at random, do they contain what I expect." That one check would have caught this in five minutes, at any point during the months it was quietly failing. Nobody asked it, because the dashboard already said everything was fine.