Even before installing SharePoint 2010 it is good practice to deal with business continuity management – in other words: backup and recovery of SharePoint 2010 farms. Many things became easier in the newest release of Microsoft's composite collaboration platform, but certain manual configuration steps cannot be avoided.
This mini-series of articles attempts to give you the nuts and bolts of backup configuration and performing it, as well as dealing with how to recover the backup. Obviously, the better backup and recovery is prepared, the less time you will spend restoring a SharePoint 2010 environment. And after all, the less time you business loses, the better it is.
Initial Backup Configuration
As mentioned before, there is no way around configuring manually (or at least verifying) some initial settings. First of all, you need to distinguish on what level you want to perform backups. Depending on this level, you must have different permissions to perform backup and recovery from the Central Administration:
Backing Up the Farm
SharePoint 2010 offers a high level of granularity: You can separately back up any object starting from the entire farm down to single lists. It is straightforward to choose the backup components you want to save for a later recovery. On the "Backup and Restore" section of the Central Administration (CA), you will find the same granularity. If you go for a farm backup, the before mentioned requirements hold. Moreover, the following services must be running at the time you are issuing the backup command from CA:
More options can be chosen on the next page of the backup wizard: You can specify whether you want to run a full or differential backup and whether you want to back up only the configuration settings or also add the content databases. And, of course, you can also specify the backup folder.
It is good practice to perform any type of farm backup into a local folder and only afterwards transfer the backup files to a network share or remote location.
While you can back up both content and configuration data for your farm using CA and PowerShell (PS), you can only back up the farm's content databases using the SQL Server tools. The preferred tool for this operation is the SQL Server Management Studio (SSMS).
In order to be able to back up the content databases, you must have the db_backupoperator role assigned to the user you are trying to perform the backup with.
Backing Up Content Databases
Content databases are the heart of your SharePoint web applications. Using CA or PowerShell, you can backup entire web applications, in other words configuration settings plus content databases. Although these two methods allow for the full backup of single web applications, you can only back up the content databases using the before mentioned SSMS backup method.
If you opt to choose the CA approach, please note also that there is no way to generate a separate backup for configuration data and content databases. The generated backup files for a web application are self-contained. Again, choosing "Perform a backup" from CA is the way to go. The only option that should be changed is the selection of the desired web application and its corresponding backup folder.
The PowerShell cmdlet to perform the same task is straightforward to use: No matter on which granularity you would like to back up your farm, the cmdlet of choice is always
Backup-SPFarm comes with a set of parameters, of which the most important are:
You can review the status of running or finished jobs in CA, in the section "Backup and Restore" | "Check backup and restore status".
The report gives you an insight of the current jobs, including the time, result, the person who started the job and a finish date for each backup component (in case it didn't fail). This is a great way to see at a glance where the backup failed. If one component cannot be backed up, the overview will show a corresponding error message, along with the details. This helps to easily identify backup or restore problems and track them to their root.
There is another way in order to get detailed insight into the backup status and check for detailed error messages and exceptions. In the directory you specify during the CA or PS setup of the backup configuration, at the end of the backup/restore operation you will find either spbackup.log or sprestore.log.
Backing Up Site Collection, Lists and Document Libraries
SharePoint offers also the possibility to back up entire site collections, lists and documents. These options can be found in CA, specifically in the section "Granular Backup". There are only a couple of mouse clicks that need to be performed in order to export an entire site collection: You simply select the site collection you want to export and specify the backup folder.
Requirements for this step include a running SharePoint Timer Service as well as there must not any backup be running already. The site collection will then be available on the file system as a single backup file, in the directory you specified for the backup. The preferred file extension is .bak.
While backing up on farm level, for different granularity you had to use always the Backup-SPFarm PowerShell cmdlet, for the granular backup it is a bit different. There are different cmdlets for backing up site collections and lists or document libraries. Backing up a site collection using PowerShell works using the following cmdlet and corresponding parameters:
The Identity and Path parameters are straight forward. UseSqlSnapshot will create a read-only view of the current content database and use this one for restoring the content database. NoSiteLock causes the standard behaviour of setting the site collection to read only not to take effect. In other words: Your site collection will still be writable, i.e. modifiable by users. As you can imagine, this could possibly cause the currently backed up site collection not to be up-to-date at the end of the backup procedure.
Similarly, you can back up single sites, lists or document libraries:
The Export-SPWeb cmdlet is the backup command with the most granularity. Using the IncludeUserSecurity parameter you can include full permissions of the list/library. GradualDelete is especially recommended for larger sites or lists. It will cause the site or list to be gradually deleted and prevents further access to it.
It is a very good strategy to use it in order to minimize the impact of content deletion on SharePoint and the underlying SQL server. If you want to remove a site or list and archive it, then Export-SPWeb -GradualDelete -IncludeUserSecurity -IncludeVersions is the command of choice.
Backing Up Log Files
Log files are good and important to have. But sometimes they are just loitering on different drives and growing very large. Hence, it makes sense to merge them for backup purposes and save them away as a single file. This can explicitly be done using PowerShell:
This command will merge all diagnostic log files into a single log file (in the location you specify). "All" in this case means all diagnostic log files from each server in the farm – hence this operation usually takes a notable amount of time.
In addition, using PowerShell it is also possible to copy single servers' diagnostic log files into a specified archive folder, using the standard Copy-Item cmdlet.
The default location for the Collect Usage Data Files is on the same partition where SharePoint is installed. Since they can grow very large, it is recommended to store them to another driver in order to achieve better performance.
Conclusion
SharePoint Server 2010 offers a lot of functionality for backing up using different granularity levels. Whether you want to use Central Administration (preferrable for manual backups) or PowerShell, depens completely on your preferences: Most of the times all the operations are available using either approach.
In this first part of the Backup and Restore Introduction we introduced the initial configuration and setup of SharePoint 2010 backups. Moreover, we had a look at different backup methods using Central Administration, PowerShell or SQL Server tools and concluded this first part with backing up diagnostic and usage logs.
This mini-series of articles attempts to give you the nuts and bolts of backup configuration and performing it, as well as dealing with how to recover the backup. Obviously, the better backup and recovery is prepared, the less time you will spend restoring a SharePoint 2010 environment. And after all, the less time you business loses, the better it is.
Initial Backup Configuration
As mentioned before, there is no way around configuring manually (or at least verifying) some initial settings. First of all, you need to distinguish on what level you want to perform backups. Depending on this level, you must have different permissions to perform backup and recovery from the Central Administration:
- Farm, Service Applications, Content Databases: Local Administrator Group Member
- Site collections, sites, lists, document libraries: Farm Administrator Group Member
Backing Up the Farm
SharePoint 2010 offers a high level of granularity: You can separately back up any object starting from the entire farm down to single lists. It is straightforward to choose the backup components you want to save for a later recovery. On the "Backup and Restore" section of the Central Administration (CA), you will find the same granularity. If you go for a farm backup, the before mentioned requirements hold. Moreover, the following services must be running at the time you are issuing the backup command from CA:
- Timer Service
- SharePoint Foundation Administration Service
More options can be chosen on the next page of the backup wizard: You can specify whether you want to run a full or differential backup and whether you want to back up only the configuration settings or also add the content databases. And, of course, you can also specify the backup folder.
It is good practice to perform any type of farm backup into a local folder and only afterwards transfer the backup files to a network share or remote location.
While you can back up both content and configuration data for your farm using CA and PowerShell (PS), you can only back up the farm's content databases using the SQL Server tools. The preferred tool for this operation is the SQL Server Management Studio (SSMS).
In order to be able to back up the content databases, you must have the db_backupoperator role assigned to the user you are trying to perform the backup with.
Backing Up Content Databases
Content databases are the heart of your SharePoint web applications. Using CA or PowerShell, you can backup entire web applications, in other words configuration settings plus content databases. Although these two methods allow for the full backup of single web applications, you can only back up the content databases using the before mentioned SSMS backup method.
If you opt to choose the CA approach, please note also that there is no way to generate a separate backup for configuration data and content databases. The generated backup files for a web application are self-contained. Again, choosing "Perform a backup" from CA is the way to go. The only option that should be changed is the selection of the desired web application and its corresponding backup folder.
The PowerShell cmdlet to perform the same task is straightforward to use: No matter on which granularity you would like to back up your farm, the cmdlet of choice is always
| 1 | Backup-SPFarm -Directory "path" -BackupMethod "Full|Differential" -Item |
- Directory: Set the backup folder
- BackupMethod: Specify whether to run a full or differential backup
- Item: Specify the farm, web application or (shared) service application you want to backup
You can review the status of running or finished jobs in CA, in the section "Backup and Restore" | "Check backup and restore status".
The report gives you an insight of the current jobs, including the time, result, the person who started the job and a finish date for each backup component (in case it didn't fail). This is a great way to see at a glance where the backup failed. If one component cannot be backed up, the overview will show a corresponding error message, along with the details. This helps to easily identify backup or restore problems and track them to their root.
There is another way in order to get detailed insight into the backup status and check for detailed error messages and exceptions. In the directory you specify during the CA or PS setup of the backup configuration, at the end of the backup/restore operation you will find either spbackup.log or sprestore.log.
Backing Up Site Collection, Lists and Document Libraries
SharePoint offers also the possibility to back up entire site collections, lists and documents. These options can be found in CA, specifically in the section "Granular Backup". There are only a couple of mouse clicks that need to be performed in order to export an entire site collection: You simply select the site collection you want to export and specify the backup folder.
Requirements for this step include a running SharePoint Timer Service as well as there must not any backup be running already. The site collection will then be available on the file system as a single backup file, in the directory you specified for the backup. The preferred file extension is .bak.
While backing up on farm level, for different granularity you had to use always the Backup-SPFarm PowerShell cmdlet, for the granular backup it is a bit different. There are different cmdlets for backing up site collections and lists or document libraries. Backing up a site collection using PowerShell works using the following cmdlet and corresponding parameters:
| Backup-SPSite -Identity "Site Collection Name"-Path "path" [-UseSqlSnapshot] [-NoSiteLock] |
Similarly, you can back up single sites, lists or document libraries:
| Export-SPWeb -Identity "Site/List/Library name" -Path "path" [-IncludeUserSecurity] [-GradualDelete] [-IncludeVersions] |
It is a very good strategy to use it in order to minimize the impact of content deletion on SharePoint and the underlying SQL server. If you want to remove a site or list and archive it, then Export-SPWeb -GradualDelete -IncludeUserSecurity -IncludeVersions is the command of choice.
Backing Up Log Files
Log files are good and important to have. But sometimes they are just loitering on different drives and growing very large. Hence, it makes sense to merge them for backup purposes and save them away as a single file. This can explicitly be done using PowerShell:
| Merge-SPLogFile -Path"path" -Overwrite |
In addition, using PowerShell it is also possible to copy single servers' diagnostic log files into a specified archive folder, using the standard Copy-Item cmdlet.
The default location for the Collect Usage Data Files is on the same partition where SharePoint is installed. Since they can grow very large, it is recommended to store them to another driver in order to achieve better performance.
Conclusion
SharePoint Server 2010 offers a lot of functionality for backing up using different granularity levels. Whether you want to use Central Administration (preferrable for manual backups) or PowerShell, depens completely on your preferences: Most of the times all the operations are available using either approach.
In this first part of the Backup and Restore Introduction we introduced the initial configuration and setup of SharePoint 2010 backups. Moreover, we had a look at different backup methods using Central Administration, PowerShell or SQL Server tools and concluded this first part with backing up diagnostic and usage logs.
