A farm backup is the most holistic form of backup that SharePoint supports. When you run a farm backup, SharePoint coordinates the backup with farm servers to ensure you get a consistent and consolidated backup. There are four primary types of farm backups that can be taken, and each is described in subsequent sections:
- Complete farm backup
- Differential farm backup
- Configuration-only backup
- Component-level backup
While somewhat flexible, SharePoint’s farm backup does have some limitations that are worth pointing out up front. One is that you cannot back up directly to tape since SharePoint only supports file system-based locations. If you need to archive to tape, you must employ an additional backup solution to archive the files generated by SharePoint’s backup.
SharePoint’s farm backup engine doesn’t scale well to farms with a number of large content databases. In general, if the total amount of content in your farm exceeds 500 GB, you should consider using SharePoint-compatible, third-party products instead. Many good ones exist, including System Center Data Protection Manager 2010 by Microsoft and DocAve by AvePoint.
While a farm backup is running, the farm can still be used for normal operations. However, the backup places a sizable load on the servers, so expect the performance to be affected. For this reason, try to schedule your farm backups during off-peak hours.
Performing a Complete Farm Backup
Among all the backup types covered in this chapter, a complete farm backup is the most important of all. It is the most complete in terms of backup coverage and offers the most flexibility in the number of restore options you have. If fact, if you do not run any other type of backup, a complete farm backup will leave you reasonably well protected.
Here is a summary of what is included in a farm backup:
- Most farm configuration settings
- Web application settings and all content databases
- Service application settings and databases, including search indexes
A complete farm backup also backs up and truncates the transaction log for each database, preventing runaway log files.
Despite being the most complete type of backup, there are some notable components that are not included in a complete farm backup. Table 16.1 describes these components and how to back up and restore them.
Table 16.1: Components not included in a complete farm backup
| Components | Backup Procedure |
| Farm configuration settings such as managed account passwords, which services are running on which servers, service application associations, and changes to timer job schedules. | Document and reapply manually if doing a restore. |
| IIS settings not configurable through SharePoint, including SSL certificates and IIS logging details. | Document and reapply manually if doing a restore. |
| Web application folders stored on each WFE server. By default, these are stored at InetpubwwwrootwssVirtualDirectories. | Back up manually or include in an OS backup of the server. |
| DLL files manually deployed into the global assembly cache (GAC). This is commonly done when manually deploying custom code. | Back up manually or include in an OS backup of the server. |
| Any changes made within the SharePoint Root (14 Hive). By default, located at Program FilesCommon FilesMicrosoft SharedWeb Server Extensions14. This is often done when manually deploying custom code or altering files located here. | Back up manually or include in an OS backup of the server. |
For more details on how to protect components not included in a complete backup, see “Plan for Backup and Recovery” on TechNet at http://technet.microsoft.com/en-us/library/cc261687.aspx.
Complete farm backups can be made with Central Administration or PowerShell. Regardless of which of these methods you use, the resulting backup set is the same. If you back up using one method, you can restore with another.
NOTE Although STSADM is a viable method for most backup and restore operations, it will not be covered in this chapter since PowerShell is the preferred method.
Using Central Administration to Perform a Complete Farm Backup
Here are the steps to perform a complete farm backup using Central Administration:
1. Click Backup And Restore, and then select Perform A Backup.
2. In Select Component To Back Up, select the Farm component at the top, as shown in Figure 16.1. This tells SharePoint to automatically include all farm components, or the “complete farm.”
Figure 16.1: Selecting all components for farm backup
3. Click Next to go to the Select Backup Options page (shown in Figure 16.2).
Figure 16.2: Setting backup options for complete farm backup
4. For Backup Component, Farm should be automatically chosen and doesn’t need to be changed.
5. For Backup Type, ensure that Full is selected.
6. For Data To Back Up, ensure that Back Up Content And Configuration Settings is selected.
7. For Backup Location, be sure that a valid Universal Naming Convention (UNC) path is listed, for example, \NAS01SharePoint. When the backup is issued, farm servers are responsible for backing up SharePoint-centric details such as farm configuration. Database server(s) also back up each of their databases to this location. This means that each SQL server must be able to write to this location.
8. Click Start Backup to begin. SharePoint creates a new timer job for the backup and schedules it to run immediately.
NOTE As shown at the bottom of Figure 16.2, SharePoint provides you with an estimate of the amount of disk space needed for the backup. This estimate is almost always on the high side as it includes the actual size of current database log files, which are not backed up in entirety. However, if you do not have the estimated amount of space available, an error is displayed, and you cannot run the backup using Central Administration. If you are unable to free up enough space, you can use the Backup-SPFarm cmdlet with the -force switch from PowerShell as described in “Using PowerShell to Automate Farm Backups,” later in this chapter.
After starting the backup, you are redirected to a Backup And Restore Job Status page. This allows you to monitor the progress while the backup is running. Since a timer job is processing the backup, you can safely close this window and return to it later. To return to the status page, click Backup And Restore, and then select Check Backup And Restore Job Status.
The amount of time the complete farm backup takes can vary widely, from minutes to over 24 hours. The primary factors are the size and number of content databases, the speed of your database servers, and the speed of the network in between the SQL servers, query servers, and the file server location specified in the UNC path.
Using Central Administration to Perform a Configuration-Only Backup
A configuration-only backup instructs SharePoint to back up only essential farm configuration settings. You can conceptually think of this as backing up the configuration database, but SharePoint does not actually do this. Instead, it captures many of these details and stores them in a series of XML and binary files. These settings include:
- Web application settings, including managed paths
- Farm solutions
- Incoming/outgoing email settings
- Timer jobs
- Diagnostic logging settings
- InfoPath Forms Services settings
Running a configuration-only backup is almost exactly the same as running a complete farm backup. Follow the steps in the previous section, “Using Central Administration to Perform a Complete Farm Backup,” but in step 6, select Back Up Only Configuration Settings. A configuration-only backup shouldn’t take more than a few minutes in most cases.
Using Central Administration to Perform a Component-Level Backup
A component-level backup is the backup of a single component within the farm. A component can mean one of many different SharePoint objects, such as a web application. When you select a component, all its subcomponents are also included and cannot be excluded. For example, when you select a web application, all content databases for that web application are included. Or you can back up all service applications or just a single service application. Within a web application, the smallest component that can be selected is a content database.
NOTE Some service applications such as the State Service application cannot be backed up as a single component.
Unfortunately, you are always limited to a single component. So, you cannot back up just two of the four content databases within a web application. Similarly, you cannot back up a single web application and a single service application together. This would be considered two components and requires two separate backup jobs. This limitation applies to PowerShell as well.
A component-level backup is run almost exactly the same as when you’re running a complete farm backup. Here are the steps:
1. Click Backup And Restore, and then select Perform A Backup.
2. In Select Component To Back Up, select a single component. You can expand and collapse components to see their subcomponents.
3. Click Next to go to the Select Backup Options page, as shown in Figure 16.2, earlier in this chapter.
4. For Backup Component, the selected component is shown.
5. For Backup Type, ensure Full is selected.
6. For Backup Location, be sure that a valid UNC path is listed.
7. Click Start Backup to begin. SharePoint creates a new timer job for this backup and schedules it to run immediately.
NOTE SharePoint also supports differential backups, in which only the changes since the last full backup are captured. Differential backups apply only to databases and not all components. When performing a restore from a differential backup, you must have both the differential and corresponding full backup available.
Understanding Farm Backup Sets
When any type of farm, configuration, or component backup is run, SharePoint keeps track of it in a separate folder within the UNC path provided for the backup location. The naming convention for each backup folder is SPBRxxxx, where xxxx is a number that begins with 0000, and increments to 0001, 0002, and so on.
In each backup folder, you’ll find a lot of BAK files. Some of these are XML-formatted files. some (the largest) are database backups, and some are other unreadable binary files. In addition, you’ll find two files useful for troubleshooting and performing restores:
spbackup.log This text file lists what was included in the backup and all logging details. A summary of the number of errors and warnings is listed at the end of this file.
spbackup.xml This XML file also lists what was included in the backup and describes what component is included in which BAK file. For example, you can identify which BAK file contains one of your content databases. This information can be used to restore the database directly from SQL Server, separate from SharePoint.
In the top-level folder (the parent of all the SPBRxxxx folders), you will find one more XML file named spbrtoc.xml. This file, called the table of contents, keeps track of each backup that was run and the corresponding SPBRxxxx folder. SharePoint uses this file when performing a farm restore.
Using PowerShell to Automate Farm Backups
All of the backup combinations available under Central Administration can also be run as PowerShell cmdlets. To run any type of farm backup, use the Backup-SPFarm cmdlet. Running a farm backup from PowerShell does not create a timer job, but the backup can still be tracked from the Backup And Restore Status page.
Here is the syntax with most of the commonly used options shown:
Backup-SPFarm -BackupMethod <Full | Differential>-Directory <UNC Path> [-ConfigurationOnly] [-Force]
Here are some examples on how it can be used.
- To run a complete farm backup:
Backup-SPFarm -BackupMethod full -Directory
\NAS01SharePointBackup - To run a configuration-only backup:
Backup-SPFarm -BackupMethod full -Directory
\NAS01SharePointBackup -ConfigurationOnly - To back up just the web application named “Intranet - 80”:
Backup-SPFarm -BackupMethod full -Directory
\NAS01SharePointBackup -item "Intranet - 80"
Central Administration makes farm backups very easy, but it does not support automating regular backups on a schedule. While a programmer can write a custom timer job for this, it is more complex, so the more common solution is to create a PowerShell script and run it as a scheduled task under Windows. Listing 16.1 is a script that we use to automate farm backups. This script will also archive old backup sets. Save this script as a text file named FarmBackup.ps1.
Listing 16.1: FarmBackup.ps1
#FarmBackup.ps1 Add-PsSnapin Microsoft.SharePoint.PowerShell # Parameter:Days of backup that should be retained $days = 3 # Parameter:Backup Folder $backupFolder = "\NAS01ackup" # Run complete backup Backup-SPFarm -BackupMethod full -Directory
There are two parameters you will need to adjust:
$days Any backups older than the number of days specified here are automatically removed.
$backupFolder Contains the UNC path where you want the backups to be stored.
To automate, you can schedule this script to run as a Windows scheduled task. This task can be created on any of your WFE servers. Here are the steps:
1. Run Task Scheduler (Start ⇒ All Programs ⇒ Administrative Tools ⇒ Task Scheduler).
2. In the Actions pane, select Create Task. The Create Task dialog box appears.
3. For Name, enter a suitable name for the task.
4. Click the Change User Or Group button and provide the username of the farm account or other account that has PowerShell access to all SharePoint databases. (See Chapter 14, “Managing Security,” for more information on granting PowerShell access.)
5. Click the Run Whether User Is Logged On Or Not radio button.
6. Click the Run With Highest Privileges check box.
7. Select the Triggers tab.
8. Click New and enter the schedule details—for example, whether you want to run the task daily or weekly.
9. Click OK to save the schedule.
10. Select the Actions tab.
11. Click New to create a new action.
12. For Program/Script: enter Powershell.exe.
13. For Add Arguments (Optional), enter the full path to where you have saved the previous script file—for example, D:scriptsFarmBackup.ps1
14. Click OK to save the action.
15. Click OK to save the task.
16. When prompted, enter the password for the account you specified in step 4. Click OK to save.
NOTE To get the previous script to run correctly, you may need to alter your WFE server’s configuration policy for running PowerShell scripts. The recommended setting is RemoteSigned. For more information on changing this, see the article “Set-ExecutionPolicy” at http://technet.microsoft.com/en-us/library/dd347628.aspx.