Prepare to back up and recover (SharePoint Foundation 2010)
Applies to: SharePoint Foundation 2010
Topic Last Modified: 2011-08-08
It is important to ensure that you have backed up and can recover the data that you need should a failure occur. Consider the information, procedures, and precautions that are described in this article before you back up and restore the environment. This article discusses restrictions and requirements for backup and recovery and how to create a shared folder on the network that can receive backed-up data.
|The SharePoint 2010 Service Pack 1 (SP1) upgrade process alters the schema of some of the farm databases and all content databases. Because of these changes, you might need to take additional steps to restore a backup that you made before the farm was upgraded to SP1 to the farm after it is upgraded to SP1. For more information about doing this, see Restore pre-SP1 backups to an SP1 farm (SharePoint Foundation 2010).|
In this article:
There are some restrictions in what can be backed up or restored. For more information about backup and recovery architecture and about what can or cannot be backed up and restored, see Backup and recovery overview (SharePoint Foundation 2010).
You cannot use a backup made from one version to restore to another version. To do this, you must use the upgrade process. You cannot restore to a farm with a lower update level than the update level of the farm that you backed up. The destination farm must have the same or newer update level. For information about how to upgrade, see Upgrading to SharePoint Foundation 2010.
If you perform a backup while any task that creates or deletes databases is running, these changes might not be included in the backup.
Do not modify the spbackup.xml file. This file is used by SharePoint Foundation 2010 and changing it can make the backups unusable.
Before you back up data, you must create a shared folder in which the data will be stored. For best performance, you should create this folder on the database server. If you want to archive the backups to another server, you can copy the whole backup folder to that server after backup is complete. Be sure to copy and move the whole backup folder and not the individual backup folders under this folder.
The SQL Server VSS Writer service, which is available with Microsoft SQL Server 2008 R2, SQL Server 2008 with Service Pack 1 (SP1) and Cumulative Update 2, and SQL Server 2005 with SP3 and Cumulative Update 3 database software, must be started for the SharePoint 2010 VSS Writer service to work correctly. By default, the SharePoint 2010 VSS Writer service is not automatically started.
You must make sure that the SharePoint 2010 Administration service is started on all farm servers before you perform a backup. By default, this service is not started on stand-alone installations.
You must ensure that the user accounts that you want to perform a backup have access to the shared backup folder.
If you are backing up by using Central Administration, the database server's SQL service account, the Timer service account, and the Central Administration application pool identity account must have Full Control permissions to the backup locations.
The database server and farm server that you want to back up must be able to connect to one another.
If you have changed the farm account, before you back up, you must grant the new account the correct permissions to the shared folder that will contain the backup data.
If you are using SQL Server with Transparent Data Encryption (TDE), and you are backing up your environment by using either SharePoint tools or SQL Server tools, the TDE encryption key is not backed up or restored. You must manually back up the key. When restoring, you must manually restore the key before you restore the data. For more information, see Understanding Transparent Data Encryption (TDE) (http://go.microsoft.com/fwlink/p/?LinkId=196394&clcid=0x409).
Use this procedure to create a shared folder on the network that can receive and hold backed-up data. You can also use this shared folder when you restore data. If you already have a shared folder that serves this purpose, you do not have to perform this procedure. By performing the following procedure, you ensure that you can access the shared folder from the computer that runs Microsoft SQL Server database software and from the computer that hosts the SharePoint Central Administration Web site.
If you are backing up by using Central Administration and SQL Server is not running on the same server, the backup folder must be on the same network or on a database server as SharePoint Foundation 2010. If you have a stand-alone installation where both SQL Server and SharePoint Foundation 2010 are running on the same server, you can use a local drive path as the backup folder location. If you are using SQL Server to directly back up a database, such as by using SQL Server Management Studio, the backup folder can be either local or on the network. For best performance, we recommend that you back up to a local folder on the database server and then move or copy the backup files to a network folder.To create a shared folder
Verify that the user account that is performing this procedure is a member of the Administrators group on the computer on which you want to create the shared folder.
If you create the shared folder on a computer other than the one running SQL Server, ensure that the service account for SQL Server (MSSQLSERVER) is using a domain user account and that it has Full Control permissions on the shared folder.
On the server on which you want to store the backup data, create a shared folder.
On the Sharing tab of the Properties dialog box, click Share, and then in the File Sharing dialog box, add the following accounts and assign them the Co-Owner role:
SQL Server service account (MSSQLSERVER)
The SharePoint Central Administration application pool identity account
The SharePoint 2010 Timer service account (if you are using SharePoint Foundation 2010 to perform backups)