We’ve watched this morning happen more than once. A shared folder, years of records in it, and overnight it’s gone: from the laptop, from the phone, from the web version. Nobody broke anything. A colleague tidied up a shared area, and sync did exactly what it was built to do, quickly and everywhere.
So, no. OneDrive isn’t a backup. It’s sync, and sync is replication, not preservation. It copies a deletion as faithfully as it copies an edit, because to the software those are the same event: a change, propagated everywhere. That’s not a flaw in Microsoft’s product. That’s the product working.
What does sync actually do?
Sync keeps a set of files identical across several places. Change a spreadsheet on the office desktop and the change appears on the laptop at home and on the phone in a coat pocket. Genuinely useful, and it’s why nobody emails themselves attachments any more.
The part that catches people out is that it works in every direction, for every kind of change. Delete a file on one device and it deletes everywhere. Overwrite a document with a bad version and the bad version is now the version, everywhere. Sync has no opinion about whether a change was a good idea. It has no concept of “correct”, only “current”.
Doesn’t Microsoft 365 keep deleted files anyway?
It keeps quite a lot, and that deserves saying plainly rather than being talked down.
There’s a recycle bin, and a second-stage bin behind it, so deleted items sit somewhere recoverable for a while. There’s version history, which holds earlier copies of a file so a bad edit can be rolled back. SharePoint and Teams sites have retention settings that govern how long content survives after deletion.
The phrase doing the heavy lifting is “for a while”. Retention periods are defaults. Defaults vary by licence and by how the tenant was set up, and administrators can change them. If you inherited your Microsoft 365 tenant from a previous provider, or from a previous version of yourselves, assume nothing. Look the settings up in your own tenant rather than trusting a number from an article, including this one. That’s why there isn’t one here.
These features are recovery tools for small, recent mistakes. They’re good at that. They weren’t designed to be the thing standing between your business and a bad month.
What kinds of loss does sync not cover?
Deletion found late. A folder goes missing in March and nobody notices until the accountant asks in July. The recycle bin emptied itself on schedule, exactly as configured. The window closed before anyone knew it had opened.
The good version aged out. A quote gets edited eleven times in a fortnight by four people. Version history now holds eleven recent versions of an increasingly wrong document. The right one fell off the end of the list.
The account loses access to its own files. A staff member leaves and their licence is removed, which starts a clock on their OneDrive. Or an account is compromised, and content is encrypted or wiped by someone the system regards as a legitimate signed-in user. Sync obediently distributes the damage. If someone’s leaving, work through the IT checklist for when an employee leaves before that clock starts.
None of these are exotic. They’re ordinary Tuesdays.
What counts as an actual backup?
A backup is a separate copy, held independently of the live system, restorable to a chosen point in time.
Three parts, and each one earns its place. Separate, so whatever happens to the live data doesn’t happen to the copy. Independent, so one administrator account having a bad day can’t reach both. Point in time, so “what did this folder look like on the 3rd of March” has an answer rather than a shrug.
Version history gives you a shallow slice of the third property and none of the first two. That’s the whole difference, and it isn’t a small one.
For a cloud-only business the answer is a third-party backup service that connects to your Microsoft 365 tenant and keeps its own copy of mail, OneDrive, SharePoint and Teams on separate infrastructure, with a retention period you chose on purpose rather than inherited. Several established providers do this; picking and configuring one is bread-and-butter work for a managed IT provider, and the right choice depends on how much data you have, how far back you need to reach, and what your accountant or your insurer expects.
Doesn’t Microsoft back it up for us?
This isn’t a case of a vendor claiming one thing while reality says another. Microsoft publishes a shared responsibility model for Microsoft 365: Microsoft looks after the availability of the service, and the customer stays responsible for their own data, including deciding how long it needs to be recoverable. The platform’s job is keeping the service running. What happens to your content, over a timeframe you choose, is your call to make.
The terms put an edge on it: once an account is disabled, there’s a limited window (90 days at the time of writing) to get your data out. That’s a window, not a safety net, and it runs whether anyone’s watching or not. Read the current terms rather than taking our summary as gospel; the position has been consistent for years, but the wording is Microsoft’s to change.
The clearest signal isn’t in the terms at all. Microsoft sells its own separate backup product for Microsoft 365, extending recovery well beyond what the platform does natively. When the platform vendor charges extra for backup of their own platform, the question of whether the platform alone is a backup has been answered by the people who built it.
The someone’s-word test
Here’s the test we ask every business to run, and it settles the question better than any article can.
Pick something genuinely unimportant: a file nobody needs, in a folder nobody watches. Delete it. Wait a week, long enough that recovering it isn’t just lifting it out of a bin you watched it fall into. Then try to get it back, and write down two numbers: how long the whole thing took, and how far back version history actually reached.
We’ll be straight about what to expect, because we’ve sat through the real thing: a full restore of a big shared drive runs to days, not hours, and most of that time isn’t the technology working. It’s people trying to remember what the folder looked like before, because you can’t tell a restore is finished if you don’t know what “restored” should contain.
Do the same test for a SharePoint file and a mailbox item, because the behaviour differs and assuming otherwise is where the surprises live. Keep the notes. One page of evidence beats any amount of reading about retention policy.
If you’ve never checked it, you don’t have it. You’ve got someone’s word for it. That’s the rule this whole question comes down to, and it applies just as well to your domain’s email records as it does to your files.
Quick answers
Is SharePoint covered differently from OneDrive? The recovery behaviour differs between OneDrive, SharePoint and Exchange mailboxes, which is exactly why the test above says to try all three. A restore that’s easy in one can be slow or shallow in another, and the differences depend on your licence and settings rather than on anything an article can promise.
How often should we re-run the restore test? Once a year as a habit, and additionally after anything that changes the ground: a new IT provider, a licence change, or moving data between sites. The point isn’t ritual. It’s that settings drift, and the test is how drift gets noticed.
Isn’t a third-party backup just one more thing to manage? Yes, honestly. It’s another supplier, another bill, another thing to check. The alternative is being your own last line of recovery with tools that were designed for small, recent mistakes. Most businesses decide the trade is worth it the first time they need a file from four months ago.
If you would like any help or advice, get in touch today!
