How Can I Recover Data From a Corrupted SharePoint Server Database?

Steven Miller 40 Reputation points
2026-08-08T05:00:34.2333333+00:00

I’m dealing with an issue on an on-premises SharePoint Server where one of our content databases appears to be corrupted. Some SharePoint sites and document libraries are no longer accessible, while other parts of the farm are working normally.

We have backups, but I’m trying to understand the safest recovery approach before restoring anything because I don’t want to overwrite the healthy data or cause additional issues with the SharePoint environment.

Has anyone dealt with a similar SharePoint Server database corruption problem? What recovery methods worked for you, and are there any specific checks or precautions I should take before attempting the recovery?

Microsoft 365 and Office | SharePoint Server | For business
0 comments

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Julie Huynh 2,360 Reputation points Independent Advisor
    2026-08-08T06:00:15.2466667+00:00

    Dear Steven Miller,

    Good day! Welcome to Microsoft Q&A forum!

    Based on your description, I understand that you want to recover data From a Corrupted SharePoint Server Database. I understand that you wish to determine the safest recovery method before taking any action; however, my experience in this particular area is quite limited. Nevertheless, I can share some insights that may be of assistance.

    Based on my research, here are several recommendations:

    1/ Accurately identify the exact location of the problem.

    2/ Create a backup before performing any operations - I notice you have already done this, which is excellent.

    3/ Restore to a separate database instead of overwriting the current one.

    4/ If the backup is recent enough, consider utilizing a "database-attach" recovery.

    5/ Exercise extreme caution when performing DBCC CHECKDB (for SQL server) repair operations.

    6/ Conduct thorough checks after the restoration.

    This matter is indeed beyond my current expertise. However, you may find more specialized guidance within the Tech Community, where numerous experts can provide advice.

    Additionally, I have attached several articles that I consulted while researching your issue. I hope you find them useful.

    Note: This link is shared by community members for your convenience. It points to a third-party site that is not managed or verified by Microsoft. I can’t guarantee the quality, safety, or suitability of any content or software found there. Please review carefully and make sure you understand any potential risks before using it.

    Thank you for your time and patience.

    If you have extra questions about this answer, please click "Comment".

    Note: Please follow the steps in [forum documentation] to enable e-mail notifications if you want to receive the related email notification for this thread.

    Was this answer helpful?

    0 comments

  2. AI answer

    2026-08-08T05:00:59.1233333+00:00

    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:

    1. 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.
    2. 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.
    3. 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.
    4. 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.
    5. Precautions during SQL restore
      • The account performing the restore must be a member of the sysadmin fixed 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.
    6. 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.log file at the UNC path used for the restore job.
    7. 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.
    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.