SharePoint version history: how far back it really goes

SharePoint version history keeps earlier copies of a file so you can view, compare or restore one — and Microsoft positions it as an integral part of the built-in data protection in SharePoint and OneDrive, useful for undoing changes that were accidental "or due to malicious activities like ransomware". How far back it goes is not a fixed number. It depends on a version limit that can be set at organisation, site, library or individual OneDrive level, and it defaults to whatever your tenant was configured with. Two documented behaviours decide whether it will actually save you: versions trimmed for exceeding a limit bypass the recycle bin entirely, and folders have no version history at all. Here is how each part really works.

Where to find it, and what restoring does

On any file in a SharePoint document library or OneDrive, the Version history option appears in the right-click menu and in the file's detail pane. It shows each version with the date and the user who made the change. From there you can:

• View an earlier version without touching the current one. In Word and Excel files you can compare versions to see what changed.
• Restore an earlier version, which replaces the current file. Importantly, the restored version becomes the new current version — the intervening versions are not deleted, so a restore is a roll-forward rather than an erasure.
• Track who changed what and when, which is the audit use rather than the recovery one.

That last point matters more than it sounds. Because restoring adds a version rather than removing them, restoring a file consumes a version slot — which becomes relevant as soon as you are near a limit.

How far back SharePoint version history actually goes

Version limits can be applied at four levels — organisation, site, library, and individual OneDrive account — with the narrower level breaking inheritance from the broader one. A site owner can override the organisation default for their site; a library can override the site. Which means the honest answer to "how many versions do we keep" is it depends on which library you are asking about, and that is worth checking rather than assuming.

Microsoft offers two settings:

Automatic. Microsoft's recommended option, which manages version storage for you rather than making an administrator guess at a count. It is applied to new libraries when it is set as the organisation default.

Manual. An explicit count of major versions, optionally paired with an expiration period. Microsoft's own documentation uses the example of a library set to store 500 major versions with a 365-day expiration: no more than 500 versions are kept, and any version older than a year is deleted automatically. You can also set a count with no expiry at all.

There is a floor worth knowing about. The admin UI will not accept a value below 100 major versions or a 30-day expiration, but the public APIs will — and Microsoft warns plainly that going lower is not recommended and "can result in the user activity causing an inadvertent data loss". If someone once scripted a tighter limit to reclaim storage, that setting is still in force and no longer visible as unusual in the interface.

Folders do not have version history

This is the single most common surprise, and it is not a bug or a licensing gap: versioning in SharePoint applies to files and list items, not to folders. Open a folder's context menu and there is no Version history option, because there is nothing to version — a folder has no content of its own, only the items inside it.

The practical consequences are the ones that bite:

• If someone renames or moves a folder, there is no folder version to roll back to. You are looking at the recycle bin or a manual reconstruction.
• If a folder's structure is reorganised — fifty files redistributed across new subfolders — each file keeps its own version history, but the arrangement itself was never recorded anywhere.
• Restoring the files does not restore the layout. Version history is per-item by design, so it can return every file's contents and none of the organisation around them.

For folder-level damage, the tools that do help are the 93-day recycle bin and the 30-day OneDrive rollback, not version history.

Trimmed versions do not go to the recycle bin

This is the behaviour most likely to catch out anyone who has assumed the recycle bin is a backstop. Microsoft documents three different fates for a deleted version, and only one of them is recoverable:

How the version was deleted	Where it goes
A user deletes it from the file's version history	The site recycle bin, recoverable for a period
It exceeds the library's version limit	Marked for permanent deletion — bypasses the recycle bin
An admin runs a scheduled job to trim existing versions	Permanently deleted — bypasses the recycle bin

Microsoft's wording on the automatic cases is unambiguous: the version deletion workflow bypasses the normal recycle bin and the deleted versions cannot be recovered from it. So the versions most likely to disappear — the old ones, pushed out by new activity — are precisely the ones with no second chance.

What this means when ransomware is the scenario

Put the two documented behaviours together and the failure mode writes itself. Ransomware reaching SharePoint or OneDrive through a sync client does not delete files; it writes them. Every encrypted file is a new version on top of a clean one, which is exactly why version history is a genuine first-line recovery tool: for a modest incident caught quickly, rolling files back to the last clean version works.

But each encrypted write consumes a version slot. Where a library has a manual count limit, an attacker who writes repeatedly — or a process that runs for hours before anyone notices — pushes the clean versions past that limit. Those versions are then trimmed as over-limit versions, and per Microsoft's own table, over-limit trimming bypasses the recycle bin. The safety net is not merely exhausted; it is permanently gone, and nothing in the interface announces it happened.

This is the same structural point we made about whether cloud backup protects against ransomware: the native mechanisms are time- and count-boxed undo features, built for accidents rather than for an adversary who is authenticated and patient. Detection lag, not the existence of version history, is what decides the outcome.

Two things that do protect versions

Microsoft documents two exemptions, and both are worth knowing because they are the only native ways to stop trimming:

• Retention policies and eDiscovery holds override version limits. For an item subject to a retention policy or on an eDiscovery hold, the library's versioning limits are ignored until the retention period is reached or the hold is released. If a trim job encounters a held version, it stamps an expiration date on it rather than deleting it.
• Versions of documents marked as records cannot be deleted. Version deletion is blocked outright on records.

Neither of these is a backup. They protect versions of files that still exist, inside the tenant that holds them, under settings a sufficiently privileged administrator manages. But if there are libraries where the version history genuinely is your recovery plan, bringing them into scope of a retention policy is the native lever that exists.

Microsoft also logs version-history activity to the Purview audit log — changes to limits at every level, queued trim jobs, bulk version deletions and individual version deletions. If you want to know whether someone tightened a limit, that is where the answer lives.

Getting the answer for your own tenant

The questions worth resolving are short, and none of them require a product decision first: which of your Microsoft 365 libraries are on automatic limits and which are on manual counts, whether any were ever set below the UI floor through the API, and which libraries hold content where losing the version history would actually hurt.

If you would like that mapped against your real recovery requirement — how far back you must be able to go, which workloads carry the risk, and where the native ceilings sit today — a recovery assessment walks your tenant and shows you where version history stops being enough. We help you choose the right fit for your stack and get it deployed; you own and run it from there.