Are you sure OneDrive has got your back(up)? | Michael Ayles<br>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)Microsoft says it recommends syncing no more than 300,000 items total for good performance, and warns that problems can show up beyond that even if you are not syncing all of them. A higher 1,000,000 items per device ceiling exists, but only just: roll-out started 22 April 2026 , a month or two ago. It is a public preview, not the default. To get it you need a preview build of Windows (Windows 11 or Server 2022 via the OneDrive Insider programme) and a mid-to-high-end machine : 16 GB RAM minimum (32 GB recommended), an SSD, and a recent i5 / Ryzen 5 or better. No VDI support. Anything that does not meet the bar stays on the old 300,000 limit.. 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:

FolderFilesDesktop1,524,695Documents902,687Firmware and old workspaces~27,000Everything else<br>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...