Stop treating version history as your backup. It is a genuinely useful feature. It is also, on its own, a poor substitute for the thing most admins assume it covers, and Microsoft's own recent push toward Full Workload Backup rolling out now is an implicit admission that the assumption needed correcting.
We hear a version of this sentence often enough that it is worth addressing head-on: "we don't need a separate backup, SharePoint keeps every version." That statement is technically true and practically misleading, and the gap between the two matters more than most tenants realize until the day they need to close it.
Three layers, one job, different jobs
SharePoint Online actually gives you three separate protection mechanisms, and they overlap far less than their reputations suggest. Version history preserves prior states of a file that still exists in its library. The recycle bin preserves items a user has deleted, for a fixed retention window, recoverable by the user or an admin. Microsoft 365 Backup, the newest of the three, is a wholly separate, admin-managed system with its own retention policy and its own restore workflow, sitting outside the ordinary SharePoint content model entirely.
| Layer | What it protects against | What it does not cover | Who controls it |
|---|---|---|---|
| Version history | Bad edits to a file that still exists | Deleted files, deleted sites, deleted libraries | Library owner (version limit setting) |
| Recycle bin | Accidental deletion, within retention | Anything past the retention window; permanently emptied items | End user, then site admin, then tenant admin |
| Microsoft 365 Backup | Point-in-time restore of a workload, ransomware, corruption | Real-time undo of a single accidental edit | Tenant admin, via its own policy engine |
Where the assumption breaks down
Version history has no answer for a deleted site collection, a deleted library, or a tenant-wide event like a compromised account running a mass-delete script. It also has no answer for the more mundane case where a library's version limit was set low, or never set at all in the wrong direction, and the specific revision someone needs has already aged out. None of these are edge cases. They are the normal shape of the incidents that get escalated to IT.
Version history answers "what did this file look like last Tuesday." Backup answers "what did this entire site look like before the ransomware event." Neither question substitutes for the other.
Why the confusion persists
Part of the problem is naming. Microsoft's own documentation uses the word "version" for file revisions and, informally, the word "backup" gets applied loosely by IT teams to describe whatever recovery mechanism happens to be available, whether or not it is actually a backup in any formal sense. A recycle bin item feels like a backed-up file to the person who deleted it and got it back. That lived experience quietly reinforces the wrong mental model for the rarer, larger event where the recycle bin and version history both fall short simultaneously.
The other part of the problem is cost. A proper backup product is a line item someone has to justify, while version history and the recycle bin are already switched on by default and feel free. It is an easy trap: the free layers get treated as sufficient because nobody wants to be the one who asks for budget for a third layer that, most weeks, does nothing visible at all.
See how Space Master keeps version history lean
What a sane setup actually looks like
None of this is an argument against version history or the recycle bin. Both remain the right tool for the vast majority of day-to-day recovery requests, and reaching for a full workload restore over a single accidentally overwritten paragraph would be absurd. The argument is narrower: know which layer you are actually relying on for which failure mode, and don't let the presence of the first two convince anyone that the third is optional.
A reasonable baseline: keep version limits sized to genuine editorial need rather than left uncapped, since uncapped version history mostly just becomes an expensive, unmanaged shadow of the same data. Keep the recycle bin as the fast, self-service front line. Then decide, deliberately, whether Microsoft 365 Backup or an equivalent third-party product covers the scenarios where the first two structurally cannot help, and budget for it as a real line item rather than an afterthought. For a closer look at how the recycle bin specifically stacks up against Microsoft 365 Backup's coverage, see this comparison of the two.
The uncomfortable truth is that most tenants only discover which layer they were missing after the incident that needed it. Deciding the answer in advance, on a quiet Tuesday, is considerably cheaper than deciding it during a live restore.