A family of Microsoft on-premises document management and storage systems.
For an on-premises SharePoint Server content database issue, the safest supported approach is to restore only the affected content database, not the whole farm, unless farm-wide components are also damaged.
Recommended recovery path:
- Confirm the recovery scope
- Content databases can be restored individually, one at a time.
- From within a content database, recovery can target site collections, sites, lists, and libraries, but object-level recovery is more complex than restoring the whole content database.
- If the problem is limited to one content database, avoid full-farm recovery to reduce risk to healthy data.
- Check for remote BLOB storage before restoring
- SharePoint Server restores remote BLOB stores only when the SQL Filestream remote BLOB store provider is being used.
- If another remote BLOB provider is in use, the remote BLOB store must be restored manually.
- Choose the restore method
- Supported methods for a content database are Central Administration, PowerShell, or SQL Server tools.
- If the content database is not selectable in Central Administration, use PowerShell or SQL Server tools.
- If using SQL Server tools, follow this sequence
- Back up the live transaction log first, if possible, to protect changes made after the last full backup.
- Restore the last full database backup.
- Restore the most recent differential backup after that full backup.
- Restore all transaction log backups after the most recent full or differential backup.
- Precautions during SQL restore
- The account performing the restore must be a member of the
sysadminfixed server role. - Stop the SharePoint Timer service before restoring and wait several minutes for running stored procedures to finish.
- Do not restart the Timer service until after the content databases are restored.
- In SQL Server Management Studio, restore the database with Overwrite the existing database selected.
- In recovery options:
- Use RECOVER WITH RECOVERY if all required transaction logs are included.
- Use RECOVER WITH NORECOVERY if additional transaction logs still need to be restored.
- RECOVER WITH STANDBY is not used for this scenario.
- The database is automatically taken offline during the recovery operation, so it will be inaccessible during restore.
- The account performing the restore must be a member of the
- If using Central Administration
- The account must be a member of the Farm Administrators SharePoint group.
- Go to Central Administration > Backup and Restore > Restore from a backup.
- Select the backup job, then the affected content database.
- Use Same configuration for the restore.
- Monitor progress on the Backup and Restore Job Status page.
- If errors occur, review the Failure Message column and the
Sprestore.logfile at the UNC path used for the restore job.
- Avoid risky farm-level actions unless required
- Do not directly try to recover the Central Administration content database or the configuration database with DPM because this can cause data corruption in the SharePoint farm.
- The Central Administration content database and configuration database can be recovered only as part of a full-farm recovery to the same farm, with the same computers.
Practical guidance for the scenario described:
- Since other parts of the farm are healthy, restoring only the affected content database is the lowest-risk option supported by SharePoint Server.
- If granular recovery is needed for only a few site collections, sites, lists, or libraries, that is possible, but it is more complex than restoring the full content database.
- If using DPM, full farm recovery cannot be done to a new location, and farm recovery requires the same SQL Server names, drive configuration, front-end configuration, and matching service packs, language packs, and patches.