Share via

SharePoint 2010: Backup and Restore Best Practices

  • Article

Introduction

This whitepaper gives an operational area of SharePoint specifically on Backup and Restore.

Backup Solution

The following Table represents backup recommendation for SharePoint 2010 Collaborative environment.

 

 

Table 1 – Backup Solution

1.1.1.1. Core Content Recovery

For Core Content there are 2 levels of data recovery such as Content recovery and Site recovery. Each level addresses a different business issue and is often performed by persons in different roles within the organization.

Content recovery refers to recovering a document or list by using the Recycle Bin or versioning.  Content recovery is a frequent and small-scale activity, and it can be performed by end users and site administrators.

Site recovery refers to using tools to recover from accidental deletion or data corruption of a site.  Site recovery can be performed by site administrators.

Database recovery refers to the databases such as Content Database and Service application Databases.

1.1.1.2. Content Recovery

Content Recovery is one or the most frequently used features in SharePoint. SharePoint takes a layered approach to it and provides multiple options:

  • ·         Versioning
  • ·         Recycle Bin

What is Versioning

 

Versions allow keeping multiple copies of documents that vary in content over time.  This mechanism provides self-service recovery for users and is most useful for incidents in which a document is overwritten or corrupted.  Through this mechanism user can revert to a previous version of a document.

Versioning is configured by the site collection administrator on a per-site basis.  By default it is turned off.  There are 3 possible versioning policies:

  • ·         No Versioning
  • ·         Create Major Versions
  • ·         Create Major and Minor Versions

The policy should instruct administrators to proactively manage the versioning process because versions of documents are not represented as differentials.  Therefore each version is a complete representation at that instant I time.  This can drive database sizes to the  quotas very fast and impact backup and restore performance.  User and administrator education will be the most impactful effort can make.

 

Deciding on versioning is site collection administrator job. However, Contoso design team can advise the site collection administrator to limit the number of versioning in their site collection.

Restrict Versioning in the following ways:

1) Limit the number of major versions
2) limit a number of major version that will have minor versions
3) CANNOT limit a number of minor versions to keep for a major version

*Limit depends on business use cases, for example content publishing site requires more versioning than community sites.

What is Recycle bin

 

The Recycle Bin has a 2 stage model that is on by default and is configurable on a per-web application basis.  The length of time that an item stays in the Recycle Bin is by default 30 days but is configurable.  This gives a 60 day opportunity to recover deleted content.  In the majority of cases this will be sufficient.  Again this is a fundamental aspect of Content Recovery strategies.  Users should be educated on the existence and use of this feature.  Multiple versions of a document can exist in the Recycle Bin and cannot be restored over an existing document.  Site collection admin would need to use versioning for that.

 

Stage 1 is the first stage Recycle Bin and is located at the site level.  It is available to users with Contribute, Full Control, or Design permissions.  When a document is deleted it is sent here and continues to impact the site quota.  It remains for the 30 days configured by the administrator is reached.

 

Stage 2 is located at the site collection level and it contains items deleted from the Stage 1 Recycle Bin.  It will remain here until the time period specified by the administrator.  It does not affect the site quota but does impact the size of the site and its content databases.  The administrator can place a quota on the Recycle Bin size.

 

This Recycle Bin times do affect the life of content and the policy should be consistent with Business Records Retention policy.

 

Default 2 stages bin will be turned on and configured for 30 days for an item to recover. However, Site collection admin have rights to change it.

 

Recovering a site directly is available in SharePoint 2010 SP1. SharePoint 2010 SP1 introduces “Site Recycle Bin” feature which will help Site collection administrator to restore the site. Hence, the recommendation is Contoso to use “Site Recycle Bin” for restoring a site.

1.1.1.3. Content Databases

All content databases can be backed up by using SQL server tools.  In the event of a disaster, these databases backup with SQL server should be restored using the standard restore procedures.

1.1.1.4. Farm Backup and Configuration Database

The recommendation is  Contoso should be using backup and recover a farm without the content databases attached. This method provides Contoso to backup farm settings and Web application settings, in addition to the settings for any service applications that have been selected.  

Advantage of full farm backup is - On Recovery, Farm doesn’t need to recreated and reconfigured.

 To copy configuration settings by using a farm backup, it is recommended that Contoso first detach the content databases from the farm.

 Here are the steps to be performed

Get-SPWebApplication | %{$_.Name;$_.Url;%{$_.ContentDatabases|%{$_.Name};Write-Host ""}} Get-SPContentDatabase | Dismount-SPContentDatabase Backup-SPFarm -Directory \\servername\share -BackupMethod Full Mount-SPContentDatabase -Name <WSS_Content> -WebApplication <https://servername>l

 

1.1.1.5. Restoring Service Application

 

Using PowerShell, Service application will be restored.

Restore-SPFarm -Directory <BackupFolder> -Item Shared Services\Shared Services Applications\<ServiceApplicationName> -RecoveryMethod Overwrite [-BackupId <GUID>] [-Verbose]

Where:

    • <BackupFolder> is the path of the folder where the backups are stored.
    • <ServiceApplicationName> is the name of the service application.
    • <GUID> is the identifier of the backup to use in the restore process.

1.1.1.6. Configurations

Office SharePoint Server includes Internet Information Services (IIS) configurations and configurations stored in the configuration database and Central Administration content database.  In the event of a full disaster recovery, the following information will be required to restore the farm to the same exact configuration.

IIS Configurations

Internet Information Services (IIS) configurations are set in Central Administration or IIS Manager on each front-end Web server.

 IIS configurations are stored in the IIS metabase. The metabase is a plain-text XML file on each front-end Web server that can be modified by using IIS Manager, or directly by Office SharePoint Server. The metabase is susceptible to being corrupted or overwritten, and it should be included in backup strategy.

 It is recommended to document all IIS configurations rather backup for each Web server by using a tool that provides the configuration monitoring, such as Microsoft System Center Configuration Manager.

 IIS configurations documents should include the following:

1.       Application pool settings, including service accounts

 

2.       HTTP compression settings - default

3.       Time-out settings - 180 Seconds

 

4.       Custom Internet Server Application Programming Interface (ISAPI) filters 

5.       Computer domain membership - homeoffice

6.       Internet Protocol security (IPsec) settings - default

7.       Network Load Balancing settings

 

8.       Host header entries

9.       Secure Sockets Layer (SSL) certificates

10.   Dedicated IP address settings.

 

1.1.1.7. Binary Files

In the event that a SharePoint server needs to be restored, it is recommended to reinstall Office SharePoint Server and all other installed programs using the original binaries. Binary files should be kept in a secure location that can be easily accessible during a recovery scenario. The following table can be used to identify the different components.

 

Component

Basic Components

Operating System

Office iFilter Pack

SQL Server

Office SharePoint Server 2010

SharePoint 2010 Language Packs

  • ·         Ja-jp (Japanese)
  • ·         Es-es (Spanish)
  • ·         Fr-fr (French)
  • ·         Pt-br (Portuguese Brazil)
  • ·         Pt-pt (Portuguese)
  • ·         Zh-tw (Chinese Traditional)

RMS Client

URL Scan

Customizations

MSIT Site Delete Capture

Foxit PDF IFilter

Contoso SharePoint Branding

Contoso Site Provisioning / Site Directory

NewsGator  2010

MS Application Templates

JQuery

SharePoint Administration Toolkit

Table 2: Contoso Binary Files

1.1.1.8. Customizations

This section lists all 3rd party and in-house customizations that have been deployed to the environment and provides guidance for restoring them.

Custom code (WSP)

 

Customization includes

 

1.       Assembly Development 

Any custom code developed such as Web Parts, site or list definitions, custom columns, new content types, custom fields, custom actions, coded workflows, or workflow activities and conditions. It also includes 3rd party tools, if any. Any Visual Studio development wrapped as WSP.

 

2.       Artifact authored Development

Any code developed using SharePointdesigner or Internet Explorer.

 

For the Assembly development customization, it will be stored on the source control repository system (Team Foundation Server). In case of recovery WSP will be retrieved from Team Foundation server.

 

For the artifact authored development, objects will be stored in Content databases, which be backed up with SQL Server.

 

1.1.1.9. Read-Only Mode

Another capability in SharePoint 2010 is support for configuring content databases to be in a Read-only mode.  In this mode SharePoint 2010 will seamlessly detect and respond to this change and disables any user interface options associated with write and edit scenarios.  This allows user to continue using the system to retrieve data and work within SharePoint until the environment is again configured to be writable. 

Recommendation

The above capability should be used in Disaster Recovery solutions with secondary environments during patching and upgrade, when Contoso decides to have DR farm.  . 

1.1.1.10. Backup scenarios

In addition to the configuration and content databases, it is necessary to back up the search databases, and other SharePoint services databases that have in the deployment. The backup should also include backup of any configuration settings on the Web front-end servers and the application servers.

 The recommendation is to regularly backing up the complete farm by backing up both the configuration and content. Regularly backing up the farm reduces the possibility of data losses that might occur from hardware failures, power outages, or other problems. It is a simple process and helps to ensure that all the farm data and configurations are available for recovery, if that is required.

 The following table lists components of a SharePoint environment that needs to protect, and the tools that can be used to back up and recover each component.

Component

Backup type

Frequency

Considerations

Farm

SharePoint

Once per week or after a customization.
  • ·         Performing a backup does not affect the state of the farm.
  • ·         The farm backup process does not back up any certificates that used to form trust relationships.
  • ·         Backing up the farm backs up the configuration and Central Administration content databases.

Web Applications

SharePoint

Once per month or after a customization.
  • ·         When back up a Web application, the Internet Information Services (IIS) settings and all content databases that are associated with the Web application are also backed up

Application Services

SharePoint

Full once per week or after a customization.
  • ·         Microsoft SharePoint Server 2010 backup backs up the Business Data Connectivity service external content type definitions but does not back up the data source itself

All SQL Server databases

SQL Server

Full once per week + several differentials per week or Full 2, 3 times a week + Transaction logs in between.

 

Transaction Logs

SQL Server

Every 10 min.

 

SQL Cluster Nodes

SQL Server

Weekly full system state backup and daily differential

 

Table 3: Contoso SharePoint 2010 Backup Scenario

Microsoft SQL Server 2008 R2 transaction logs record all changes that were made to a database since the last checkpoint or full backup. These logs contain required data for restoring the farm. The recommendation is backing up these logs every 5–10 minutes. Upon back up these logs, they are automatically truncated.

1.1.1.11. Restore Scenarios

What to restore

What to do

Web Front End

Replace hardware

Restore ?available image? or Restore/reinstall Operating system.

Service application

Run power shell command

Restore-SPFarm -Directory <BackupFolder> -Item <ServiceApplicationName> -RecoveryMethod Overwrite [-BackupId <GUID>] [-Verbose]

 

 

Single SQL Server Node

Wait for the resources to fail over to the passive node

Replace hardware

Restore ?available image? or Restore/reinstall Operating system.

Restore latest backups using SMSQL

 

Farm

Replace hardware

Restore available image or reinstall operating system.

Run power shell command

Restore-SPFarm -Directory <BackupFolder> -RestoreMethod Overwrite [-BackupId <GUID>]

  • ·         View the backups for the farm by typing the following: Get-SPBackupHistory -Directory <Backup folder> -ShowBackup.
  • ·         If no BackupId was provided, the most recent backup will be used.

 

Web Application

Run power shell command:

Restore-SPFarm -Directory <BackupFolderName> -RestoreMethod Overwrite -Item  <WebApplicationName> [-BackupId <GUID>] [-Verbose]

Where:

  • ·         <BackupFolderName> is the full path of the folder used for backup files.
  • ·         <WebApplicationName> is the name of the Web application that was backed up.
  • ·         <GUID> is the identifier of the backup to use for the restore operation.

Site

Site Recycle bin

Table 4: Contoso’s SharePoint 2010 Restore Scenario

SQL Backup Maintenance

SharePoint data protection is implemented through a Maintenance Plan on database servers.
The plan is designed to retain a 21 day recoverability of the databases in the event of a disaster.

The capacity of the Backup server has been planned based on assumption that total size of 21 days of backup with SQL compression enabled is less than 3x the size of the original databases.

Introducing a live maintenance plan on the secondary database server along with on-demand DFSR replication between secondary and primary backup servers allows for creation of two independent backup sets of SharePoint databases on local and remote backup servers, providing all prerequisites for retiring tape backup.

Maintenance Plan

The Microsoft maintenance plan includes the following scheduled jobs:

  1. Back Up Database (Full)
    Scope: All Databases
    Backup set will expire: After 21 days
    Destination: \\<BKServer>\BK
    Backup Compression: On
    Schedule: Occurs every week on Saturday at 6:00:00 PM
  2. Back Up Database (Differential)
    Scope: All Databases
    Backup set will expire: After 21 days
    Destination: \\<BKServer>\BK
    Backup Compression: On
    Schedule: Occurs every week on Monday, Tuesday, Wednesday, Thursday, Friday, Sunday at 6:00:00 PM
  3. Back Up Database (Transaction Log)
    Scope: All user databases not participating in log shipping
    Backup set will expire: After 21 days
    Destination: \\<BKServer>\BK
    Backup Compression: On
    Schedule: Occurs every day every 17 minute(s) between 12:00:00 AM and 11:59:59 PM
  4. Check Database Integrity
    Scope: All Databases
    Include indexes
    Schedule: Occurs every day at 3:00:00 AM
  5. Shrink Database
    Scope: All user databases
    Limit: 102400 MB
    Free space: 10%
    Schedule: Occurs every week on Monday, Tuesday, Wednesday, Thursday, Friday, Sunday for 6 hour(s) between 8:00:00 PM and 1:49:59 AM
  6. Reorganize Index
    Scope: All databases
    Object: Tables and views
    Schedule: Occurs every week on Monday, Wednesday, Friday at 2:00:00 AM
  7. Rebuild Index
    Scope: All databases
    Object Tables and views
    Schedule: Occurs every week on Sunday at 2:00:00 AM
  8. Update Statistics
    Scope: All databases
    Object: Tables and views
    All existing statistics
    Scan type: Full scan
    Schedule: Occurs every week on Tuesday, Thursday at 2:00:00 AM
  9. Clean Up History
    History type: Backup, Job, Maintenance Plan
    Age: Older than 1 week 

 This plan should be configured on all SharePoint database servers.

Monitoring

All scheduled jobs are monitored for success, warning, and error events.
Jobs 3-6 schedule could be adjusted based on monitoring results to ensure that there are no job overlapping and/or database lockups.

Backup

On the primary database server, jobs 1-3 will provide a complete backup of all databases. For all mirrored SharePoint databases the backup jobs will skip the mirror database and produce a backup of principle database only regardless of its location.

On the secondary database server, all log shipped databases are by default in standby read-only mode. The maintenance plan executed on secondary database server will create additional backup set of SharePoint databases on secondary backup server.

Restore

Restoring data from primary backup server has no specific plan, as each scenario could vary.

In event when data cannot be retrieved from database backups, or even log backups located on the primary backup server, a second set of backups could be retrieved from secondary backup server utilizing existing DFSR mechanism established between backup servers for log shipping.

Monitoring

Real-time and predictive monitoring is a key business requirement to ensure the SharePoint team is aware at all times of the health of their environments holistically. Monitoring provides the main basis for taking preventative or remedial action to ensure continued operation within accepted performance parameters.

Microsoft System Center Operations Manager (SCOM)

Microsoft uses SCOM to monitor the SharePoint environment. Error conditions and Failures regarding a particular server, service or feature, are captured and filtered into the Alert Stream and forwarded on to a System Center Operations Manager (SCOM) console.

The SCOM Management Packs (MPs) used are:

  • ·         IIS SCOM MP
  • ·         SQL SCOM MP
  • ·         SharePoint SCOM MP
  • ·         Hardware SCOM MP
  • ·         Operating System SCOM

The MP data is aggregated into configured monitors (reference: https://technet.microsoft.com/en-us/library/dd440880.aspx).

Event Based Monitoring

Events are used to capture the state of given elements of the SharePoint environment. Monitoring includes Desired Configuration Management allowing Operations to detect and monitor “drift” in the configuration from the baseline configuration deployed.

Poll Based Monitoring

Poll Based Monitoring tests performance of the SharePoint Online Service. The Operations team watching the console can be engaged real-time to return the SharePoint environment to a normal operating state. Without poll based monitoring in place, the service may experience significant performance issues or even failures without knowledge until customer complaints cause the engagement of Operations. Polling uses Microsoft internal utilities URLMon and SPMon.

  • ·         Poll based monitoring using a tool such as URLMon,
  • ·         Poll based monitoring using synthetic transactions simulated with a tool such as SPMon.
  • ·         Poll based monitoring using metrics for performance counters recorded by the Perfmon capability of Windows.

SharePoint 2010 adds new advanced health monitoring functionality and performance counters to the product; however, a complete availability and performance picture can only be seen through a set of synthetic transactions. Traditional “ping” type transactions are not effective for monitoring SharePoint. SPMon is used within Microsoft to generate the following SharePoint specific synthetic transactions:

  • ·         Get Home Page and Login
  • ·         List Creation 
  • ·         List Delete
  • ·         List Item Creation / Edit
  • ·         Document library creation
  • ·         Document Library deletion
  • ·         Document Upload/Edit
  • ·         Do search query
  • ·         Verify search freshness

DPM (System Center Data Protection Manager) 

There are several tools available for the backup and restore, For reference Microsoft Tool “System Center Data Protection Manager” DPM features are provided below.  

Component

SharePoint backup

Microsoft SQL Server 2008 with Service Pack 1 (SP1) and Cumulative Update 2

System Center Data Protection Manager (DPM) 2010

File system backup

Environment

Yes

Yes6

Web application

Yes

Yes6

Content databases

Yes

Yes

Yes

Search and other services

Yes

 

 

 

Site collection

Yes1, 2

Yes1, 2

Yes1, 2

Site

Yes2

Yes2

Yes

Document library or list

Yes2

Yes2

Yes

List item or document

Yes

Content stored in remote BLOB stores

Yes3

Yes3

Yes3

Customizations deployed as solution packages

Yes7

Yes7

Yes6, 7

Changes to Web.config made by using Central Administration or an API

Yes

Yes

Yes4

Configuration settings (SharePoint)

Yes2, 8

Yes2, 8

Yes 2, 9

Customizations not deployed as solution packages

Yes. Files can be recovered if protected as files.4, 5

Yes

Changes to Web.config not made by using Central administration or an API

Yes4

Yes

IIS configurations not set through SharePoint

Yes5

Yes

SQL Server Reporting Services databases

Yes

Yes

Table 13: Summary of backup strategies in SharePoint Server 2010

1Environment-level and database-level backup and restore can be used for site collection recovery if a single site collection is stored in a database.

2Environment-level and database-level backups can be used with SharePoint Server unattached database recovery to restore site collections, sites, lists, and configurations.

3Content stored in remote BLOB stores is backed up and restored with other content, as long as the Remote BLOB Storage (RBS) provider in use has this capability.

4Changes to Web.config can be backed up by using file system backup from DPM 2010.

5IIS configurations can be recovered by using a bare metal backup from DPM 2010.

6 DPM 2010 can recover this item by using a combination of a bare metal backup and SharePoint Server backup. It cannot be backed up and recovered as an object.

7Fully-trusted solution packages are stored in the configuration database, and sandboxed solutions are stored in content databases. They can be recovered as part of Environment or content database recovery.

8Configuration settings can be recovered from Environment-level backups.

9The Central Administration content database and the configuration database for a SharePoint Server 2010 Environment can be recovered but only as part of a full-Environment recovery to the same Environment, with the same computers.

Comments

  • Anonymous
    January 01, 2003
    Brett, For site collections 15-100 GB in size, Microsoft recommends using SQL Server backups. If it's over 100 GB, you're going to want to consider a different backup tool, such as Microsoft's Data Protection Manager or one from a third party vendor (AvePoint, Quest, or Idera just to name a few). Hope this helps.

  • Anonymous
    January 01, 2003
    Good Stuff.. Thanks for sharing ..

  • Anonymous
    August 23, 2012
    Great stuff.  Can you tell me if I follow the Farm Backup and Configuration Database steps to backup the Farm config without the content databases, how long the Dismount and Mount processes will take?  When mounting there will be no upgrade involved, but the content db is huge (400+ GB), and I want to make sure the time to mount is not astronomical.  Thanks

  • Anonymous
    September 25, 2012
    In Farm environment, if I use powershell to perform Farm backup, do I need to open 445 port between Web to DB or DB to Web?  Is there any connectivity documentation available from Microsoft?

  • Anonymous
    April 14, 2015
    Shrinking databases is not best practice. It risks corruption of databases, impacts performance and should never appear in a regular maintenance plan.

    The SQL maintenance plan is not fit for purpose;
    1)The shrink step should be removed,
    2)The index and statistics steps will, unless the SharePoint health analyser rules are changed, duplicate effort
    3)The DBCC Check Integrity step should occur before backups are taken

  • Anonymous
    July 26, 2015
    The comment has been removed

  • Anonymous
    July 26, 2015
    The comment has been removed

  • Anonymous
    August 03, 2015
    Blobbing dsjhs sbjsbd sdbhsgd bis hdbf a h sharepoint 2013 mbsad kbsdk

  • Anonymous
    October 13, 2015
    It can be almost impossible to find well-qualified users on this matter, however, you look like you be aware of exactly what you’re covering!

    http://staygreenacademy.com/sharepoint-developer-training-online/

  • Anonymous
    April 11, 2016
    SharePoint Server Recovery is capable of extracting files and folders from MDF databases and restore data with powerful recovery modes and Live SQL Instance Mode. SharePoint Server recovery software supports recovery of databases created using MS SQL Server 2000, 2005, and 2008 and MS SharePoint Server 2007. - See more at: http://www.mozesoft.com/sharepoint-server-recovery.html