Planning and configuring backup and restore options

Backups are an important part of designing and maintaining a SharePoint Server environment. The ability to backup and recover data is integral to many business processes, such as the following instances:

• Recovering or restoring accidentally or maliciously deleted content
• Platform or service upgrades
• Migrating between infrastructure solutions
• Recovering from failed upgrades
• Recovering from unexpected system failures or disasters

Natively, SharePoint Server supports the following backup designs:

• Farm
• Granular
• Configuration only

Let's examine these backup designs in more detail.

Farm

In a farm backup scenario, you'll be targeting backing up major components of the farm. The farm backup architecture is initiated from Central Administration and launches a SQL Server backup of content and service application databases. It also saves configuration content to files and backs up the Search index data.

A SharePoint farm backup supports both Full (all data) and Differential (data that's changed since the last full backup).

Within a farm backup, you can select the following nodes:

• Farm: The farm is the highest-level object. You can choose from the following selections:
  • Content and configuration data (default), which backs up the entire server farm (including settings from the configuration database)
  • Configuration-only, which only backs up the settings stored in the configuration database
• Web application: The Web application node represents the pieces necessary for an entire web application, including the following:
  • App pool name and account information
  • Authentication settings configuration
  • General web application settings, such as managed paths
  • Internet Information Services (IIS) site binding configuration, such as the protocol, port, and host header information
  • Changes to the Web.config file that were made through object model-based scripting or applications, as well as changes made through Central Administration (changes made manually are not backed up)
  • Sandboxed solutions (sandboxed solutions are stored in a web application's content databases)
• Services and service applications (not shared): Service and service application backups contain the settings for that service or service application, as well as any databases associated with it. If backing up a service application, the related proxy is not included. To fully protect the service application and its related application proxy, perform either a full farm backup or two consecutive backups with the service application in the first and the application proxy in the second.
• Proxies for service applications that are not shared: This is the application proxy only.
• Shared Services: Shared services require both a service application and an application proxy to run. Choosing the Shared Services node will back up all of the service applications and the corresponding service application proxies.

In addition, there are things that even a full backup doesn't cover (mostly related to the operating system and IIS configurations):

• Application pool account passwords
• HTTP compression settings
• Time-out settings
• Custom Internet Server Application Programming Interface (ISAPI) filters (configured through IIS)
• Computer domain membership, group membership, or organizational unit placement
• Internet Protocol security (IPsec) settings
• Network Load Balancing (NLB) settings
• SSL certificates or certificate trust stores
• Dedicated IP address configurations and settings
• Windows Firewall settings

For these settings, you will likely want to perform operating system backups or exports. Furthermore, there are a few additional caveats for farm-based backups that you should be aware of when planning a backup and restore strategy:

• The native SharePoint Server backup tools do not have a native scheduling interface. To perform scheduled backups, you will need to create a backup script of your own and schedule it using Windows Task Scheduler.
• SharePoint Server backup does not protect changes to Web.config made outside Central Administration or object model-based scripting solutions.
• SharePoint Server backup does not protect individual site customizations that are not part of a trusted or sandboxed solution.
• SharePoint Server backup does not protect trust certificates that have deployed for cross-farm solutions or service applications.
• Databases configured to use SQL FILESTREAM Remote Blob Storage (RBS) can only be backed up and restored to SQL database servers with the RBS provider installed.
• If your farm or applications use forms-based authentication, those settings must be manually configured after you perform a restore by registering the membership and role providers and redeploying the providers.

Any flat files that you backup through PowerShell or another export process can then be backed up using software such as System Center Data Protection Manager.

Granular

When backing up certain components (such as sites, workflows, customizations, web applications, or other individual components), you perform a granular backup. As you saw in the previous section, there are a number of tools you can use to perform various types of backups.

A granular backup, when using native tools, relies on Transact-SQL statements to export content. With the granular backup system, you can export or backup site collections and lists.

Workflows are not included when performing exports of sites or lists.

You can perform granular backups using native tools, including PowerShell, Central Administration, and SQL Management Studio. If you are using a version of SQL that supports database snapshots (such as Enterprise Edition), backups can trigger a database snapshot and allow users to continue accessing the site as normal. When backup utilizes database snapshots, you gain the added advantage of a totally consistent backup at a particular point in time. The downside is that it is a more I/O-intensive operation to perform a database snapshot, so users may experience a brief slowdown when the database snapshot is initiated.

As previously mentioned, the native SharePoint backup solution administration is performed from the farm's Central Administration page. Many organizations, however, use third-party backup solutions that utilize an application-aware backup agent for SharePoint services, applications, and databases.

Whichever method you choose for performing a backup (whether you are using full farm backups or more granular backups), you'll have a route to restore your environment or its components should unexpected circumstances arise.

Configuration only

With a configuration-only backup, you are only backing up the server or farm configuration without any data. This type of backup might be useful for replicating farm configurations in conjunction with disaster recovery preparation or building test and development environments. Depending on the mechanism used, you can back up either the entire farm configuration or parts of the farm or server configuration using either the Central Administration interface or by using PowerShell.

Central Administration

By performing a configuration-only backup with SharePoint Server Central Administration, you can back up the configuration of the farm. The Central Administration configuration backup method can only be used to back up the full configuration of the local farm. It cannot be used to back up a remote farm or a disconnected configuration database.

To perform a farm backup using Central Administration, follow these steps:

1. Verify that the user account performing the backup is a farm administrator.
2. Navigate to the Central Administration page. Under Backup and Restore, click Perform a backup.
3. On the Perform a Backup — Step 1 of 2: Select Component to Back Up page, select the farm from the component list browser, then click Next.
4. On the Start Backup — Step 2 of 2: Select Backup Options page, select Full in the Backup Type section.
5. In the Backup Only Configuration Settings section, select Backup only configuration settings.
6. In the Backup File Location section, enter the Universal Naming Convention (UNC) path of the destination backup folder, then select Start Backup.

The UNC path will contain a backup that can further be moved to offline media and preserved.

PowerShell

When using the Backup-SPConfigurationDatabase PowerShell cmdlet to perform a configuration-only backup, you can overcome the limitations of performing a backup with Central Administration. PowerShell-based backups allow you to backup configurations from either local or remote farms, as well as disconnected configuration databases.

Performing the backup from PowerShell, depending on the target configuration database, may require additional permissions. Generally speaking, the account that is used to perform the backup must have the following permissions or memberships:

• A db_owner fixed database role on all of the databases being backed up or updated
• A securityadmin fixed server role on the SQL server instance where the databases are hosted
• Membership to the local Administrators group on the server where Backup-SPConfigurationDatabase is being executed
• Membership to the WSS_ADMIN_WPG local group on the server(s) where SharePoint products are installed
• A SharePoint_Shell_Access role for the databases that are being acted upon
• Optionally, the db_backupoperator fixed database role for the databases being backed up or updated

You can use the Add-SPShellAdmin cmdlet to grant the account used for PowerShell administration access to the SharePoint_Shell_Access role to specific databases. It is recommended that you specify which databases to use with the -Database parameter as that will add the named account to the farm configuration database, the Central Administration content database, and the database specified in the parameter, as well as to the WSS_ADMIN_WPG group on all SharePoint web servers.

You can use a function or PowerShell script, such as the one in the following code block, to accomplish the task of adding an additional administrator to the SharePoint farm. Copy and paste the following script into SharePoint Management Shell, then run New-FarmAdmin -Identity <username> -IncludeAllContentDatabases:

Function New-FarmAdmin ([string]$Identity,[switch]$IncludeAllContentDatabases)
{
    $CentralAdminWebApp = Get-SPWebApplication –IncludeCentralAdministration | `
    ? {$_.DisplayName –like "SharePoint Central Administration*"}
    New-SPUser –UserAlias $Identity –Web $CentralAdminWebApp.URL –Group "Farm Administrators"
    $CentralAdminContentDB = Get-SPContentDatabase –WebApplication $CentralAdminWebApp
    Add-SPShellAdmin -Database $CentralAdminContentDB -Username $Identity
    If ($IncludeAllContentDatabases)
    { 
       $ContentDatabases = Get-SPContentDatabase
       Foreach ($Database in $ContentDatabases) 
       {
          Add-SPShellAdmin -Database $Database -Username $Identity
       }
    }
}

For more information on the Add-SPShellAdmin cmdlet, see https://docs.microsoft.com/en-us/powershell/module/sharepoint-server/Add-SPShellAdmin?view=sharepoint-ps.

You must also have write access to the network share path that will be used as the destination for the backup. The Backup-SPConfigurationDatabase cmdlet is used to initiate a backup.

To perform a configuration backup using PowerShell, perform the following steps:

1. Launch SharePoint Management Shell.
2. Run Backup-SPConfigurationDatabase -Directory <BackupFolder> -DatabaseServer <DatabaseServerName> -DatabaseName <DatabaseName>.

Be sure to specify the -Directory parameter value destination as \\server\share.

Both planning for disaster recovery scenarios as well as day-to-day backup and restore scenarios are crucial to ensuring your data is protected from destruction or environment failure. In the next section, we'll discuss how Information Rights Management (IRM) can be used to protect your information in another way—from unauthorized use, tampering, or leakage.