How to Backup Sharepoint: A Guide

Backing up Microsoft SharePoint is as important as safeguarding your data for other Microsoft 365 services. In this article, we’ll show several ways to back up SharePoint data using native and third-party tools.

How Do You Back Up SharePoint with Native Tools?

Microsoft 365 has several built-in SharePoint Online backup tools and restore options: eDiscovery, Files Restore, and OneDrive Sync.

1. Log in to your Microsoft 365 account and select SharePoint.
2. Select the site you need to back up.
3. Click DocumentsName.
4. Click Sync.
5. Open Microsoft OneDrive.

Done! Remember that you’ll need the desktop versions of OneDrive. However, backing up SharePoint using OneDrive is not the best option. After all, neither OneDrive nor other Microsoft 365 apps are backups. They have some limitations.

Another interesting way to backup with native options would entail using SharePoint Admin Center Backup. You can login to the SharePoint Central Administration site. Look for the Backup and Restore link on the left menu bar. Under Granular Backup options, there’s a Perform a site collection backup feature. 

Pick which site collection you need to backup and point it to a network location you control for storing the file. Hit Start Backup and let it run through. That’s pretty much it!But do remember, the Perform a site collection backup option exists in SharePoint Server (on-premises), not SharePoint Online. For SharePoint Online, admins use PowerShell, retention policies, or third-party tools.

Why Does SharePoint Backup Actually Matter?

Microsoft runs genuinely resilient infrastructure. Datacenters go down rarely, and when something fails at the infrastructure level, Microsoft has the recovery handled as well. What Microsoft cannot protect you from is what happens inside your own tenant. 

Things like a user incorrectly deleting a document library or a bulk content move going wrong and wiping metadata across hundreds of files. Ransomware is another challenge.

Imagine, someone’s laptop gets ransomware, and the infected file versions sync to SharePoint before IT catches it, overwriting clean content across an entire library. 

None of these are infrastructure failures, and Microsoft’s built-in tools handle them poorly if enough time has passed. The Recycle Bin catches obvious accidents if you catch them quickly. Outside that window, the options get expensive and slow. This is the exact gap backups exist for. 

How Does the Shared Responsibility Model Apply to SharePoint?

The shared responsibility model in cloud services divides the work clearly: Microsoft owns the platform, the physical infrastructure, and its own disaster recovery. You own your data, your access controls, and recovery from anything that isn’t a platform failure. 

If you delete something and let it age past the Recycle Bin window, that’s on you or if a sync client pushes corrupted files to a shared library, that’s on you as well. 

Microsoft’s service agreement covers the availability of the platform itself. It doesn’t guarantee that your specific data will be there when you need it. 

The 14-day site-collection restore window that Microsoft Support can access exists as infrastructure disaster recovery, not as a customer data recovery service. 

It restores full site collections only, with no granularity, and the clock on it starts from the moment data is purged. Thus, after 14 days, that path also closes.

What Are the Limitations of Native SharePoint Backup?

Files Restore allows recovering only a whole SharePoint document library. But if you need to restore just one SharePoint file? You’ll need to restore the library, find your file, copy it somewhere, and roll back the restore.

Besides, you have to select each library manually. Hardly a time-saving approach you want in your workflow.

1. Limits of Retention Policy

Data recovery, determined by the SharePoint data retention policy, is an easier-to-use option. But there are strict time frames. You can restore your SharePoint data, but you have to do it while the data is retained. Now think about compliance, which may require retrieving files from years ago.

2. Challenges with Litigation Hold

You may think that indefinite data retention makes Litigation Hold a perfect tool for data recovery. Not exactly. Litigation hold is a trade-off: features for the time.

Litigation hold allows you to restore from only one data version. If you make any changes, you have to update the Hold manually. Otherwise, you won’t be able to recover the most recent SharePoint data version.

Also, while recovering from Litigation Hold, the folder hierarchy is disrupted. That means you’ll need time to bring a file where it was deleted from.

3. Security Drawbacks

There is another major drawback, related to the security of Microsoft 365 storage. The SharePoint data on hold is kept in the same cloud as the data it should protect. On the contrary, backup has a more secure approach, which is based on storing a copy separately from the data it backs up.

Though you can back up and restore SharePoint data using built-in tools, they have some limitations:

1. Turning off the version history prevents you from restoring files to a previous version.
2. If you upload a deleted item again, the restore operation for that item will be skipped.
3. If your files were removed from the site collection recycle bin, you can’t restore them. Within 14 days of purge, Microsoft Support can restore a prior whole site collection from DR backups; they cannot restore individual files.
4. Files Restore is limited to the last 30 days.
5. All data is stored in the same cloud, which leaves backup data vulnerable to the same threats as the original data.
6. Backing up your Sharepoint data is a manual process. To ensure you can retrieve the latest version, you must back up your data again if any changes are made.
7. Using OneDrive Sync is not the most secure option, as your backup can be infected with ransomware.

Using automated third-party tools will help you to avoid those limitations.

There are several ways to back up your SharePoint site. There are also several ways to restore it.

Which SharePoint Data Should You Back Up?

The right answer is everything, but being specific about what “everything” is important. These are the things that consistently get left out of backup scope:

1. Version History Inside Document Libraries

A backup that only captures the current state of a file is useful until there occurs a need to check older versions. Those prior versions should be in the backup, not just the latest copy.

2. Lists and List Attachments

People build real operational workflows on SharePoint lists. They’re not document libraries, so they’re easy to exclude when configuring backup scope, and people realise their mistake of not backing them up only after they’re needed.

3. Site Pages and Web Parts

When these disappear, users notice before IT does. They’re not always covered by tools that focus primarily on document libraries.

4. Permissions and Sharing Links

A restored library that’s missing its permissions structure is functionally broken. The files are there but the right people can’t access them, and tracking down and rebuilding permissions manually is tedious work.

5. Teams-Connected Sites

Teams stores its files in SharePoint. Every Private Channel creates its own separate site collection. These are easy to miss when defining backup scope, especially the Private Channel sites.

6. The Term Store

This is the metadata taxonomy that organizes content across your tenant. If you restore a library without it, the content loses the structure users rely on to find things.

7. SPFx Customizations, PnP Templates, and Search Configuration

If your sites have custom apps, branded page layouts, or a configured search schema, those need to be captured. A technically complete file restore that looks and behaves wrong to every user who touches the site is not a successful restore.

SharePoint Online vs. SharePoint On-Premises

The backup approach is different enough between the two versions that the distinction is worth covering directly.

SharePoint Server, which organizations host on their own infrastructure, has a functional built-in backup through Central Administration. 

You navigate to Backup and Restore, select a site collection, point it at a network path you control, and run it. The result is a backup file you own. It’s not sophisticated, but it works and you control where it goes.

SharePoint Online has no equivalent native backup. Central Administration backup simply doesn’t exist for the cloud version. 

When you search for SharePoint backup instructions and find a tutorial that walks through Central Administration steps, check whether it was written for Server or Online. If it mentions the on-premises admin interface, the instructions don’t apply to SharePoint Online.

SharePoint Online admins working around this usually end up with one of four options: retention policies, selective exports through PowerShell or the Microsoft Graph API, the Microsoft 365 Backup paid add-on, or a third-party tool. 

The PowerShell and Graph API routes are worth calling out specifically because they’re often mistaken for a full backup, but they’re not. You’re actually exporting content you specifically asked for, not capturing a complete point-in-time snapshot of the site.

How Often Is SharePoint Backed Up?

Microsoft backs up SharePoint Online site collections every 12 hours and retains those backups for 14 days. These aren’t accessible to you. 

They exist for Microsoft’s platform recovery purposes. Getting a restore from them requires contacting Microsoft Support, and what you get back is a full site-collection restore with no ability to pick individual files or folders.

For backups you control directly, daily incrementals are a reasonable starting point for most active sites. 

Sites where collaboration is constant and content changes throughout the day can justify more frequent runs during working hours. Sites that change rarely can run on a weekly schedule without significant practical risk.

The more useful question than frequency is how much data loss you can actually tolerate. If losing a full day of work on a critical project site is acceptable, daily is enough. If it isn’t, the backup needs to run more often. 

Compliance frameworks often set minimum retention requirements measured in years rather than months, and not every tool can meet those requirements. You should verify the retention capabilities of whatever you use before relying on it.

How Do You Back Up SharePoint Manually?

We all know the caveats with manual approaches. They require some effort. It is not preferred but if you’re in a pinch, or if you just need a lightweight way to capture critical files, you’ve got a couple of do-it-yourself options:

1. Direct Download

Go to your SharePoint library in the browser, select files or folders, and click Download. It’s simple, but you’ll need discipline to keep doing it regularly.

2. PowerShell Scripts

In SharePoint Online, there’s no supported full ‘backup’ cmdlet. You can use Microsoft Graph, CSOM, or PnP PowerShell to export content selectively (e.g., library items) or capture site templates, but not perform a full point‑in‑time site backup.

What Third-Party Solutions Can Back Up SharePoint?

SharePoint backups look slightly oversimplified until one runs into an issue. Microsoft native solutions give us some safety net, but it’s limited. We’ve already discussed plenty of issues with the approach earlier. That’s where third party solutions work their magic. 

They are built to automate the process of backups; instead of relying on memory to remember to back up, these tools take the load off you. Another key feature is that one can store these backups in cloud providers other than Microsoft, which can be an immense help during a ransomware attack or outages. 

One can also gain the flexibility of backing up data to any granularity—single file, version, or list item. All of this while also helping you achieve compliance and long-term retention requirements.

Solutions in the Market

If you look out for solutions in this space, you’ll come across several players in the market, such as Veeam Backup for Microsoft 365, AvePoint Cloud Backup, Druva inSync, Acronis Cyber Protect, Spin.AI’s SpinBackup. 

Microsoft also offers Microsoft 365 Backup (paid add‑on) for SharePoint and OneDrive, providing rapid point‑in‑time restores and longer retention within the Microsoft 365 trust boundary. Each of these adds automation and security that native Microsoft tools lack. 

Advantage of SpinBackup

However, not all solutions are created equal. That’s why many organizations choose SpinBackup, which combines the must-have features (automated backups, off-cloud storage, granular restores) with advanced protection like ransomware monitoring and AI-driven anomaly detection. We’ll use the next section to explore this with some depth.

How to Backup SharePoint Online with SpinBackup

To ensure data protection and make your SharePoint backup and recovery more efficient, you can use third-party software. Spinbackup is a fully automated backup solution that helps you protect your data.

Our tool backs up your SharePoint files and sites automatically and saves all changes without any effort on your part. With SpinBackup, you can back up SharePoint to cloud storage including Azure, Amazon’s AWS, or Google’s GCP. To back up SharePoint, make sure you are subscribed to our Custom Storage plan.

If you need to change backup settings or recover your data, here’s what to do:

1. Log in to your Spin.AI account (get a free 15-day trial here)

2. Go to SharePoint & Teams section.

3. Pick the SharePoint you want to create a backup and press Autobackup. In the pop-up window, select Backup settings and click Update

What Are SharePoint Backup Best Practices?

We’ve discussed several strategies for backing up SharePoint data, but we should also make a note of the best practices for backing up data:

1. Capture Everything

Backups for SharePoint work best when you treat the site like a living system, not a pile of files. Don’t just scoop up documents; capture the stuff that makes a site behave the way users expect: version history, lists and their attachments, Site Pages and web parts, permissions, sharing links, and the Term Store that holds your metadata together. 

If you’ve ever restored a library without its permissions or content types, you know how “restored” can still feel broken.

2. Backup Frequency

Frequency matters, but fit it to reality. High‑change sites deserve frequent incrementals during the workday and a full pass on a slower cadence; calmer sites can ride a gentler schedule. 

Run heavy jobs outside business hours so you don’t trip SharePoint throttling and get a reputation for slowing everyone down. 

And, assume you’ll need different restore sizes at different times: sometimes it’s a single file version from yesterday, sometimes it’s a whole site to last month. Your tooling should handle both, including restores to an alternate location so you’re not overwriting what’s there now.

3. Flexible Recovery

Don’t lean on the Recycle Bin as a strategy. It’s great for short‑term accidents, but it’s time‑limited and not a backup. Same story with retention: compliance labels help you keep data, but they aren’t designed to put a site back together after a mass change or ransomware hit. 

Keep a copy off‑tenant and, where possible, in immutable storage. If someone syncs an encrypted mess to a library, you’ll want a clean point‑in‑time snapshot you can roll back to without debate.

4. Critical Inclusions

Plan for the things people forget. Teams files live in SharePoint, and Private Channels create their own sites—include them. Customizations like SPFx apps, PnP templates, search schema, and Site Pages matter to how work gets done; if they vanish, users will tell you immediately. 

Very large libraries restore faster when you split them into sensible chunks, and you’ll avoid classic SharePoint limits on paths and lookups that tend to bite during big recoveries.

5. Regular Drills

Finally, practice. Do a small restore every quarter and actually click around afterward: are the permissions intact, are the pages rendering, does navigation still make sense? Keep a short list of business‑critical sites with owners and give them tighter RPO/RTO. 

If you can explain, in one sentence, how you’d get “the Q2 board pack as it looked last Friday at 3 p.m.” back in under an hour, you’re in good shape. If not, tune the plan until you can.

Conclusion

SharePoint backup is not just about storing extra copies of files. It is about being able to restore the right state of work, quickly, with structure and permissions intact, when the business has been exposed to a vulnerability. 

The 93-day Recycle Bin and Microsoft’s 14-day site-collection restore window catch a reasonable slice of accidents, but they have hard edges. 

Outside those windows, or for anything that requires granular recovery such as a single file version, a specific list item, a library from last month, you need something beyond what Microsoft includes.
SpinBackup runs the backups automatically, stores copies outside your tenant, and restores at whatever granularity you need without a support ticket and a wait. You should set it up and do a test restore once a quarter and this would be something that helps everyone sleep peacefully at night.
Start a free 15-day SpinBackup trial and have automated SharePoint backup running today.

Frequently Asked Questions

Was this helpful?

Yes No