Are you sure OneDrive has got your back(up)?

My laptop battery was dying faster than it should have been. I expected a memory leak, some process slowly eating RAM until the machine swapped itself to death. That is the boring shape these things usually take. What I found was worse, and quieter, and had nothing to do with memory.

OneDrive was trying to sync 2.46 million files.

Microsoft’s own documented recommendation is no more than 300,000. I was at roughly 8x that. Their restrictions and limitations page says performance issues can occur once you pass 300,000 items, even if you are not actively syncing all of them (there is a newer 1,000,000 cap, with caveats). Past that line the client starts losing. It lags, it throws errors, it silently gives up, and it does all of this without telling you in any way you would notice.

It was not my only backup

“OneDrive ate my backup” is a much weaker story if OneDrive was my only backup. It was not. I have a NAS as my primary, running RAID 1 so one dead disk takes nothing with it, replicated to a second location so a fire or a burglary does not either. That is the actual safety net and it was never at risk.

OneDrive was the layer on top, doing two jobs. It caught the recent stuff, whatever I had changed since the last NAS sync, so today’s work never existed only on the laptop. And it was a second independent offsite copy, the offsite for my offsite.

That is the layer that quietly stopped working, while showing me a tick the whole time. And the more I sit with it, the more I think that is the worse failure. A backup that has obviously broken is a job on your to-do list. A backup that lies to you with a little cloud icon is a disaster scheduled for the worst possible day.

How I got here without trying

I did not do anything exotic to land 8x over a limit I had never heard of. I fell into a default.

Windows pushes Known Folder Move hard. It is the friendly prompt offering to “back up your Desktop and Documents to OneDrive,” and it shows up the moment you sign in with a Microsoft account. Say yes once, or let a managed M365 setup say yes for you, and your Desktop and Documents now live inside the sync folder.

Now think about where developers keep code. Visual Studio defaults new projects to Documents\Visual Studio. Arduino, MPLAB, Unity, and the firmware toolchains I use scatter their working trees through Documents too. And a working tree is not a handful of source files. It is node_modules with tens of thousands of entries, the .git object store, build and bin and obj and venv and pycache, all regenerable junk that has no business in a cloud backup but is now sitting right in the sync path.

When I counted, the shape was almost comic:

Desktop and Documents alone were 99% of it, both redirected into OneDrive by Known Folder Move. A Desktop with 1.5 million files is not documents. It is build artifacts and dependency trees, sitting in the one place guaranteed to get synced.

”Who even has 300,000 files?”

Fair question. That number sounds like a hoarder with a decade of files. This laptop is around 2 years old.

The worst offender turned out to be a single folder on my Desktop: a clone of nxpSDK, a public NXP microcontroller SDK. One repo. Not my code, not unique data. 28 GB and 900,000 files, fully re-clonable from GitHub in an afternoon, quietly contributing most of my overrun the whole time. Removing it knocked 900k files off the count in a single delete.

That is the shape of the problem. One SDK clone, one Unity project, one node_modules from a side project you started six months ago, lands you in the failure zone before you notice. A single npm install adds 30,000 to 150,000 files to a client that starts losing the plot at 300,000.

But here is the part that matters more than the anomaly. My Projects folder has 145 projects in it. Strip out nxpSDK and the remaining 144 still total around 1.56 million files. The limit was always going to get crossed. The clone just made it happen faster.

That is what the failure mode looks like. Not one catastrophic project. Just a normal developer’s working history, where each individual project seemed fine and the aggregate quietly crossed a line nobody told you existed. The count went up, the sync client fell behind, the tick kept showing we’re good, and nothing told you.

How many other people are quietly in this hole

I love a Fermi estimate, and I figured I am not special. The trap is a stack of defaults, and the same stack is under a lot of machines.

Central guess, about 1.2 million developers in this state. Low end maybe 0.3 million, high end maybe 3 million, with most of the uncertainty in two soft fractions: how many actually have the sync running, and how many keep code in the synced folders. The trap is platform-agnostic, Windows just pushes Known Folder Move hardest by default.

Now put a consequence on it. I had a NAS underneath, so my silent hole was in a spare layer. Most of these 1.2 million do not, and for them OneDrive is the only line between a dead disk and a year of lost work. Take the baseline rate at which a machine loses its local disk in a year, drive failure plus ransomware plus an unlucky rm -rf, call it 2 to 5%. Apply it to 1.2 million people who believe they are backed up and are not. That is 24,000 to 60,000 developers a year who lose real work they were certain was covered.

Why nobody sees it coming

Every layer hides it. OneDrive shows a tick that says you are synced. The 300,000 limit does not appear anywhere in the interface you actually look at. And the failure mode is silence, not a red banner, just sync that quietly stops keeping up while continuing to look healthy.

It also hides which process is the problem. When I opened Task Manager, the obvious suspect, OneDrive.exe, was barely registering. It is just the tray UI. The actual work happens in OneDrive.Sync.Service, and that was pinned at half a CPU core hour after hour, cooking the fan. Kill the client and the service keeps grinding. To confirm this is your heat source:

Get-Process OneDrive.Sync.Service | Select-Object CPU, @{N='RAM_MB';E={[math]::Round($_.WorkingSet/1MB)}}

If that CPU number is in the thousands, you have found your battery drain. And quitting the client will not stop it, the service relaunches from a Run registry key (HKCU\Software\Microsoft\Windows\CurrentVersion\Run\OneDrive) on every login.

If you work on the OneDrive clients at Microsoft: the fix here is small and it would make everyone a lot safer. When a folder crosses the 300,000-item limit you already document, just say so. A single warning, “you are over the recommended limit and sync may not keep up,” is the entire difference between a known problem and a silent one. Better still, turn the green tick orange, or anything other than the reassuring tick, the moment the client can no longer keep up. The data to do this is already on the machine. The only thing missing is telling the user. A backup that admits it is failing is a chore. A backup that lies with a green tick is the disaster scheduled for the worst possible day.

”Yeah, but my code is on GitHub”

Mostly true in my case, about 90% of what I care about is pushed to a remote. But GitHub only knows about files you have committed and pushed. That leaves out work in progress, ignored files, binary assets git handles badly, and scratch files and local configs. GitHub is a collaboration tool that happens to hold your source history. It is not a backup, and it would tell you the same.

And the files generating your 300k overrun, the node_modules, the .git stores, the build trees, are still in your sync path. OneDrive cannot keep up with them, so it falls behind on everything in the queue. Not just the regenerable junk. The work archive you made because it felt important, the photos that landed on your Desktop in a hurry, the half-finished invoice in Documents. None of those have a git repo, and for most people none have a NAS either. All of them are failing to sync behind two million files you would happily delete if you knew they were there.

What to actually do

The order matters. Do not start by cleaning up, because cleanup touches files and you cannot yet trust that the cloud has a copy. Backup first.

1. Get an independent copy now. An external drive is best, fully offline and immune to all of this. A zip of your real working folders to a second cloud works too. The goal is one known-good copy that does not depend on the client currently failing.
2. Then cut the file count. Exclude or move the regenerable junk: node_modules, .git, build, bin, obj, venv, pycache, toolchain caches. On a lot of machines that alone drops you back under 300,000. Or move Desktop and Documents out of the sync path entirely.
3. Then decide whether you even want OneDrive in the loop for dev work. That decision can wait. The backup cannot.

And before any of that, if you just want to know whether you are in the 1.2 million:

Windows (PowerShell):

(Get-ChildItem $env:OneDrive -Recurse -File -Force -ErrorAction SilentlyContinue | Measure-Object).Count

macOS / Linux / WSL (bash):

find "${1:-$HOME/OneDrive}" -type f 2>/dev/null | wc -l

These run for a few minutes on a large tree. If the number is anywhere near 300,000, the backup you think you have is not the backup you have. Go sort out an independent copy before you do anything clever with the rest of it.

The cloud icon will keep showing a tick the whole time. That tick is not a promise. It turns out it never was.