SharePoint 2010: Backup and Restore Best Practices

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.

Contoso’s recommended policy on Versioning for SharePoint 2010

 

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.

Contoso’s recommended policy on Recycle bin for SharePoint 2010

 

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:

1. • <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 3^rd 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 3^rd 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.