About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.
An on-premises SharePoint Server farm is several systems at once: a set of SQL Server databases, a search index held in files, web servers with their own IIS configuration, service applications with their own settings, and trust relationships with other farms. A backup that captures one of these does not automatically capture the rest.
SharePoint has its own backup tools, and Microsoft documents both what they cover and, usefully, what they do not. This article sets out those tools and their gaps, so that a recovery plan can fill the gaps before they are found during an outage.
The two backup systems
Microsoft's overview of backup and recovery in SharePoint Server states that SharePoint Server provides two backup systems: farm and granular. It also describes a third recovery route, recovery from an unattached content database.
Farm backup
The overview explains that farm backup starts a SQL Server backup of content and service application databases, writes configuration content to files, and also backs up the Search index files, keeping the index synchronised with the search database backups. The farm, a web application, its content databases, or individual services and service applications can be selected.
Microsoft's page on how to back up a farm adds practical points:
- A backup does not affect the state of the farm, though it uses resources and may slightly affect performance.
- The first farm backup must be a full backup before a differential one is possible.
- A backup folder is needed on the local computer or the network; Microsoft recommends backing up locally for performance and then moving the files to a network folder.
Granular backup
The granular system works at a smaller scale. The overview explains that From the granular backup system, you can back up a site collection or export a site or list. It is more read- and processing-intensive than farm backup. In our reading, that makes it best suited to targeted protection of particular sites, scheduled at quiet times, rather than to protecting a whole farm.
Microsoft notes several limits:
- Workflows are not included in exports of sites or lists.
- On SQL Server Enterprise, granular backup can use a database snapshot for consistency. Users can keep working, but changes made during the backup are not included.
- We do not recommend that you use SharePoint Server site collection backup for site collections larger than 85 GB.
Unattached content database recovery
The overview lists an option to connect to a content database by using the unattached content database feature, back up or export data from it, and then restore or import the data. In our understanding, this lets an administrator restore a content database to SQL Server from an ordinary database backup, without attaching it to the farm, and pull out only the site or list that was lost.
Configuration-only backup
The overview describes one more option that is useful in recovery: a configuration-only backup, which extracts and backs up the configuration settings from a configuration database. Microsoft notes that this works whether or not the configuration database is attached to a farm, and that the result can be restored to the same farm or another one.
Its behaviour on restore is precise. When a configuration is restored, settings in the farm are overwritten if the backup has values for them, and Settings in the farm that are not in the configuration backup are not changed. Microsoft also notes that Web application and service application settings are not included in a configuration backup.
In our reading, a configuration-only backup is a way to carry farm-wide settings to a rebuilt farm, not a replacement for a farm backup. It is worth taking alongside the farm backup because it is small, and because it can be restored on its own.
What a farm backup does not include
These are dependencies a SharePoint recovery plan must account for. Microsoft lists several categories of gaps across its pages.
Settings on the web servers
The overview states that some settings in the SharePoint Server environment are not included in a farm backup, and lists settings stored on web servers, including:
- Application pool account passwords.
- HTTP compression and time-out settings.
- Custom ISAPI filters.
- Computer domain membership.
- IPsec and Network Load Balancing settings.
- Secure Sockets Layer (SSL) certificates.
- Dedicated IP address settings.
Microsoft also advises against relying on an IIS metabase backup for IIS settings, and recommends documenting the IIS configuration of each web server with a configuration-monitoring tool instead.
Manual configuration changes
Farm backups include Web.config changes made through the object model or Central Administration. They do not include changes made by hand. The farm backup page gives the main example: for web applications using forms-based authentication, the Web.config files were updated manually to register the membership and role providers, so they must be protected by a file backup.
Trust certificates
The farm backup page states that the backup does not back up any certificates that you used to form trust relationships. Microsoft's page on how to restore a farm adds that, for farms sharing service applications, the certificates must be kept separately and the trust relationships re-established after the restore.
Data and keys outside SharePoint's databases
Three further gaps concern data that SharePoint uses but does not hold:
- Remote BLOB storage. SharePoint backs up remote BLOB stores only if you are using the FILESTREAM remote BLOB store provider. With any other provider, the stores must be backed up separately.
- Business Data Connectivity. The farm backup includes external content type definitions but does not back up the data source itself. Microsoft says to back up that source when backing up the service or farm.
- Transparent data encryption. With TDE on SQL Server, the farm backup page requires separate recovery of TDE key material, whether SharePoint or SQL Server tools are used. Preserve the certificate and private key or asymmetric-key provider that protects the database encryption key; a database backup alone does not make that protector usable elsewhere. Establish the required protector on the recovery SQL Server before restoring the encrypted database.
Databases SharePoint backs up but cannot restore
One more point from the farm backup page is easy to miss: the configuration and Central Administration content databases are backed up, but these cannot be restored using SharePoint Server tools. The overview also notes that many service application databases cannot be backed up individually from SharePoint and need SQL Server backup instead, and that a service application backup does not include its proxy unless the proxy is backed up too.
In our reading, a farm backup is therefore not, on its own, a way to rebuild a farm from nothing. It restores content and service applications into a farm that exists, or that has been rebuilt with the same configuration.
Search is a special case
The overview describes search as a special case because of the interactions between its components. A search backup runs SQL Server backups of the search databases and backs up the index files in parallel, with crawling paused for part of the backup.
The restore page adds a warning for anyone using SQL Server tools alone: The search index is not stored in SQL Server. If search is backed up and restored with SQL Server tools, a full crawl is needed afterwards. The restore page also explains that whether an incremental crawl is possible depends on the restored content database keeping its original ID.
In our reading, a full crawl on a large farm can take a long time, during which search results are incomplete. That cost belongs in the recovery time estimate.
Version limits on restore
The restore page states plainly: You can't back up from one version of SharePoint Server 2019 and restore to another version of SharePoint Server 2019. The same applies to 2016 and 2013. In our understanding, "version" here means the build, including updates. A recovery farm must therefore be at the same update level as the farm that was backed up, which means the installation media and updates must be available.
The restore page also notes that farm-level recovery is meant for a failure of the complete farm, or where partial recovery is not possible. For a database, service application, list, library or document, it recommends a smaller method.
Testing a farm restore
In our view, a SharePoint farm restore is one of the harder recoveries to rehearse, because it needs a second farm at the same build. That is also why it is worth rehearsing at least once. We recommend a test that restores into an isolated farm and then checks the things this article lists as gaps: whether sites load over HTTPS with the right certificate, whether forms-based sign-in works, whether shared service applications connect, whether documents held in remote BLOB storage open, and how long search takes to return complete results. Each failure is evidence that some part of the backup, recovery kit or restore process needs investigation.
Choosing the recovery method
From Microsoft's descriptions, our reading of which method fits:
| What was lost | Method |
|---|---|
| A document or list item | Recycle bin or versioning first; otherwise unattached database recovery or export |
| A site or list | Granular export, or unattached content database recovery |
| A site collection (under 85 GB) | Site collection backup and restore |
| A service application | Service application restore, with its proxy |
| The whole farm | Rebuild at the same version, then farm restore, then the gaps |
A recovery kit for a SharePoint farm
From the gaps above, our recommendations for what to hold alongside the farm backup:
- The farm backup, with full and differential backups, copied off the farm.
- SQL Server backups of the databases SharePoint cannot back up or restore itself.
- Installation media and updates for the exact SharePoint build.
- Certificates: SSL certificates with their private keys, and trust certificates for shared service applications.
- Web server configuration, documented: IIS settings, application pool identities (passwords held in a password manager, not in the kit), ISAPI filters, load balancing and IP settings.
- Manually changed files, such as Web.config changes for forms-based authentication.
- External data: remote BLOB stores using other providers, and Business Data Connectivity data sources.
- TDE protector and recovery material, if TDE is used, held separately and securely.
- An estimate of the full crawl time, if search might need rebuilding.
Preserve the encryption protector and the wider directory
The SharePoint guidance calls out TDE key recovery, but the distinction matters: the database encryption key is stored encrypted in the database. Recovering it elsewhere requires the certificate and private key, or asymmetric-key provider, that protects it. A database backup alone does not supply a usable replacement for that server-level protector. Have the database owner document and test this dependency alongside the SharePoint backup.
Also separate a page’s applicability list from product lifecycle support. Confirm the farm’s exact edition and build against current Microsoft lifecycle guidance before preparing a production replacement; the older 2016 and 2019 procedures do not establish that those products remain supported. Retain custom solution packages and their deployment record, service identities, directory dependencies and external data-source details. In a rehearsal, keep outgoing email, workflows and external integrations isolated until their effects have been reviewed. Opening a restored site is only one part of accepting a farm recovery.
Microsoft’s lifecycle pages record that SharePoint Server 2016 and SharePoint Server 2019 ended extended support on 14 July 2026. Their procedures are historical recovery context; a production replacement needs an explicit supported-version decision.
Risks and limits of this article
- Based on Microsoft documentation as read on 11 November 2026. Some pages were last updated in 2023 or 2025, and SharePoint Server Subscription Edition may differ in detail.
- The comparisons, method table and recovery kit are our reading and recommendations, labelled as such.
- No backups or restores were run for this article, and Microsoft's PowerShell procedures are deliberately not reproduced.
- SharePoint in Microsoft 365 is out of scope.
Sources
Writer research: 11 November 2026. Independently reopened for review: 13 November 2026.
- Microsoft Learn: Overview of backup and recovery in SharePoint Server
- Microsoft Learn: Back up farms in SharePoint Server
- Microsoft Learn: Restore farms in SharePoint Server
- Microsoft Learn: Back up service applications in SharePoint Server
This article was originally published on .