SharePoint version history isn’t a backup: what it does and what it doesn’t

SharePoint version history is useful. It has saved plenty of businesses from accidental overwrites and bad edits.

But it isn’t a backup. It’s a collaboration feature that happens to include a safety net.

If you treat it like backup, you usually find out the hard way, after someone deletes a library, a sync tool spreads corruption, or a compromised account wipes the recovery options.

If you’re trying to get Microsoft 365 set up properly for a small business, this is one of the gaps that causes nasty surprises later. See the Microsoft 365 Setup Guide for the broader structure and risk picture.

What SharePoint version history actually does

Version history keeps earlier copies of a file in the same document library. Each time the file changes, SharePoint can keep a previous version so you can view it or restore it.

When you “restore” a version, SharePoint doesn’t rewind time. It makes that older copy the new current version, while still keeping the newer versions available in history.

It’s configurable, and the limits matter

How many versions you keep, and how long you keep them, is a setting. It can be controlled at different levels, depending on how your Microsoft 365 tenant is configured.

Those limits exist for storage and performance reasons. When versions are trimmed, they can be removed permanently. That means you may not be able to recover a version that was deleted automatically by a version limit policy.

What version history is genuinely good for

If your team works in SharePoint day to day, version history is worth having turned on. It solves common, boring problems that cost time.

• Accidental overwrites: Someone saves over the wrong file or pastes the wrong figures into a spreadsheet.
• Bad edits: A document gets “tidied up” and important wording disappears.
• Collaboration mistakes: Multiple people edit, and you need to compare what changed or roll back a section.
• Quick recovery from minor incidents: A file gets corrupted or changed in a way you notice quickly.

The key phrase there is “notice quickly”. Version history helps when you spot the problem before the safety net has been cut away by time limits or trimming.

What version history does not protect you from

If you want a mental shortcut, use this one:

Version history helps you undo file changes. Backup helps you recover from loss.

It doesn’t cover “deleted” in the way people assume

If a file is deleted, version history isn’t what brings it back. That’s a different safety net, the Recycle Bin. Deleted items are only kept for a limited time.

If someone deletes a file and then empties the Recycle Bin, your recovery window can disappear fast.

It doesn’t protect you from a compromised account

If an attacker gets access to an account with enough permissions, they can delete files, delete libraries, and remove the recovery options.

Version history lives inside the same Microsoft 365 tenant, protected by the same identity and permissions model. If that model is breached, your “backup” is sitting in the same room as the fire.

It doesn’t give you an independent copy

A real backup gives you a separate copy, stored and controlled independently, with its own retention rules.

Version history is in-place. It’s still the same service, the same tenant, and the same underlying data boundary.

It doesn’t restore the bigger picture

Most real-world recoveries are not “one file went wrong”. They’re messy.

• A whole folder structure was reorganised incorrectly.
• Permissions were changed and confidential files were exposed.
• A synced device pushed thousands of changes in minutes.
• A site, library, or Team-connected SharePoint site was removed.

Version history is not designed as “put the whole system back the way it was at 9am yesterday”.

The built-in safety nets people confuse with backup

Microsoft 365 includes several recovery features. They’re helpful, but they are still not a replacement for a proper backup plan.

Recycle Bin

SharePoint Online keeps deleted items for a limited retention window. That window spans both the first-stage and second-stage Recycle Bin.

It’s a safety net for mistakes, not a long-term archive, and not a guarantee against deliberate deletion.

Restore your OneDrive

OneDrive has a “restore” feature that can roll an entire OneDrive back to an earlier point in time within a limited window. It’s designed for quick recovery from events like mass deletion or ransomware.

It’s still in-place recovery, within the same tenant. It also has a time window, so it’s not a substitute for long-retention backup.

Retention policies and holds

Retention policies are mainly about compliance and keeping data for legal or governance reasons. They can stop some types of deletion from being permanent.

That can help, but it’s not the same as backup. Backup is about clean, testable recovery. Retention is about keeping data available and defensible.

What a proper SharePoint backup gives you

A proper backup is built for the uncomfortable days, not the normal days.

• Independent copies: Your recovery data is stored separately from your live tenant.
• Longer retention: You can keep weeks, months, or years of restore points, based on your needs.
• Point-in-time recovery: Restore a site, library, or file set to a known-good time, not just a single file version.
• Cleaner ransomware recovery: You can recover from before the attack, even if the tenant was compromised.
• Testable restores: You can prove you can restore, before you need to.

A simple reality check for small businesses

If SharePoint contains anything you would panic about losing, your plan should not rely on version history alone.

At minimum, define:

• How far back you would need to restore (30 days, 90 days, a year).
• How quickly you need to be back up and running.
• Who is allowed to delete sites and libraries.
• How you will recover if an admin account is compromised.

If you want a sanity-check on the wider Microsoft 365 setup and what you should standardise early, start with the Microsoft 365 Starter Kit. If you’re comparing what you get across plans, the pricing page is the clean reference.

Summary

• Version history is a file change safety net, not an independent backup.
• It helps with accidental edits and quick rollbacks.
• It has limits, and versions can be trimmed permanently.
• Deleted files rely on the Recycle Bin, which has a limited retention window.
• A proper backup gives you independent copies, longer retention, and point-in-time recovery.

FAQ

Is SharePoint version history enough for ransomware?

It can help if you spot the problem quickly and you still have clean versions available. It’s not reliable as your only protection, because it’s in the same tenant and subject to retention limits and permissions.

How many versions does SharePoint keep?

It depends on your tenant and library settings. Your organisation can set version history limits, and older versions can be trimmed automatically once those limits are reached.

Does version history track folders and folder moves?

No. Version history is focused on files (and list items). If someone reorganises folders or moves large structures around, you usually can’t “restore the folder” back to a previous state using version history.

How long does SharePoint keep deleted files?

Deleted files are kept in the Recycle Bin for a limited retention window. After that, they’re gone unless you have a separate backup.

Can I recover versions that were trimmed by a version limit?

Usually not. If versions were deleted because of a version history limit or scheduled trimming, you should treat them as permanently removed.

Do retention policies replace backup?

No. Retention is about keeping data for compliance and legal reasons. Backup is about reliable recovery from mistakes, corruption, and attacks. You often want both, for different reasons.