The most dangerous backup failure is the one that does not look like a failure. The settings panel says everything is fine. The drive is plugged in. The status light is green. And then, six months from now, when you finally try to restore an old version of a file you deleted by accident, you discover that the version history is empty, and that the recent-looking timestamp stopped updating three months ago. That is the silent-failure pattern in backup software, and Microsoft shipped one of the worst examples of it this month with the September 2026 security updates.
I have written about backup bugs before, and the pattern is always the same. A critical piece of recovery infrastructure silently stalls, users do not get a clear warning, and the only signal is a tiny timestamp on a settings page that nobody ever checks. This time is no different. Here is what to actually check on your own machine tonight, what to do if the answer is bad, and why the broader category of failure is worth understanding even if you are not running Windows.
The pattern, generalised across backup software
Backup software has a structural incentive to look successful even when it is failing. The drive light blinks. The settings panel shows a recent timestamp. The notification tray says your files are protected. All of those signals can be true even when no actual backup is happening, because the most common failure mode is a stalled service, not a crashed one. A crashed service gives you a red error. A stalled service gives you silence.
This is not a Microsoft-only problem. Every backup product I have ever used has some flavour of this pattern. Time Machine on macOS will quietly skip files it cannot read. rsnapshot on Linux will exit zero if the disk is full but the snapshot directory still updates with empty snapshots. Duplicati, Backblaze, iDrive, Crashplan: all of them have stories where the UI says success and the actual restore reveals six months of nothing. The category is the same even when the code is different.
Microsoft’s September bug lands in the same category, but with a Microsoft-shaped twist. The service does not crash. The service stalls, the backup schedule stops firing, and the Last Backup timestamp freezes at whatever the last successful run was. The drive is fine. The feature is broken. You find out six months from now, when you actually need a restore and there is nothing to restore from.
What is actually broken on Windows right now
The affected surface is wider than Microsoft’s headline suggested. The list of affected versions spans more than half a decade of Windows releases. The exact details (the KB numbers, the Event Viewer crash signature, the specific menu paths to check) are less important than the pattern, which is that a routine monthly security patch can quietly disable the thing that protects you from ransomware, accidental deletion, and disk failure.
The bug signature, for the record, is that the backup service stops writing. The Last Backup timestamp freezes. The notification panel still says your files are protected. If you actually try to restore a previous version of a file you have edited recently, you see no previous versions available, even though the file has changed multiple times since the patch landed. Both signals together are the smoking gun.
A pair of optional preview updates later this month will carry the fix. There are two KB numbers and they map to different branches of the operating system, so make sure you install the right one. But the fix is not the story. The story is that backups broke silently, that most affected users will not realise until they need a restore, and that the recovery path requires a specific patch they may not know to install.
The five checks that take five minutes
I am not going to walk through the exact Windows menu paths in detail, because menus change and KB numbers rotate. What I am going to give you is the audit frame, which is the same on every backup product I have ever used. Five questions, in order of how often each one catches a real failure.
The first question is whether your backup software has run recently. Check the Last Backup timestamp and compare it to a date you know you edited an important file. If the timestamp is older than that edit, something is wrong. The second question is whether the backup medium is actually connected. Drives get unplugged. Network shares get disconnected. Cloud credentials expire. The most common silent failure is not a software bug at all, it is a disconnected drive. The third question is whether the restore function works. Pick a file you know you have edited recently, ask for a previous version, and see whether the system can produce one. If it cannot, your backups are not running even if the UI says they are. The fourth question is whether the backup medium has space. A full drive will silently skip new snapshots in some products and crash loudly in others. The fifth question is whether you can read the backup medium on a different machine. If your backup medium fails when you plug it into a different computer, it is a hardware problem masquerading as a software problem.
None of those checks is specific to Microsoft. All of them apply to Time Machine, to Duplicati, to rsnapshot, to anything else you might be running.
- Last Backup timestamp older than your last edit to an important file: investigate further
- Drive or share disconnected: reattach and re-run
- Restore returns no previous versions: backups are not running, regardless of UI
- Backup medium full: free space or rotate to a new medium
- Backup medium unreadable on a different machine: replace the hardware
What I would tell past me about silent backup failures
Three things, looking back at how many backup failures I have watched play out over the years:
- The UI is the last place to trust. Drive lights, status notifications, and timestamps can all lie. The actual test is whether you can restore a file you edited recently.
- Restore tests are the only real test. A backup you have never restored from is a backup you cannot prove works. Pick a file, ask for a previous version, see what comes back.
- A backup that has been silently failing for six months looks exactly like a backup that has been silently succeeding for six months. The only way to tell them apart is to test the restore function regularly, not the backup function.
Trade-offs
The five-minute audit is not free in time. It costs a few minutes, and it may surface a problem that requires a real fix (a new drive, a re-attached share, an installed patch). That is the whole point. The cost of discovering a broken backup when you need a restore is much higher than the cost of discovering it now. The decision is whether you want to spend five minutes tonight and find out, or whether you want to spend six months assuming everything is fine and discover the answer later.
For anyone reading the news cycle: do not let the headline “Microsoft broke File History” make you think this is a Microsoft-only story. The pattern is broader than one product or one operating system. The audit is the same on every backup product you own. The five minutes is the same on every product you own. The next time you need a restore is the only signal that matters, and that signal is too late to be useful.