Share via

  • Article

Prepare to back up and restore a Project Server 2010 farm

 

Applies to: Project Server 2010

Topic Last Modified: 2011-08-05

Before you back up project data, you must first create a shared folder on the network in which to store the data. You should also ensure that the accounts needed to perform a backup have access to the shared folder. This article and the procedures that follow cover preliminary considerations and the steps that you must take before you back up your data.

Preparation is the key to ensuring that you are backing up and can recover the data that will be needed should a failure occur. Before backing up your Project Server deployment, review your backup and recovery plan and consider the following key activities:

  • When you deploy Microsoft Project Server 2010, keep a record of the accounts that you create, and the computer names, passwords, and setup options that you choose. Keep this information in a safe place.

  • Always keep a copy of all recovery materials, documents, and database and transaction log backups at an offsite location. For more information about planning for backup and recovery, see Plan for disaster recovery in Project Server 2010.

  • Be certain that your system has adequate space to accommodate your backup. For more information about planning storage capacity, see Planning for Storage (https://go.microsoft.com/fwlink/p/?LinkId=121920\&clcid=0x409) in the "Windows Server 2003 Deployment Guide."

  • Periodically perform a trial data recovery operation to verify that your files are properly backed up. A trial data recovery can uncover hardware problems that do not show up with software verifications.

  • To safeguard against loss from a catastrophic event, such as a fire or earthquake, maintain duplicate copies of your server backups in a separate location from the servers. Doing so can help protect you against the loss of critical data. As a best practice, keep three copies of the backup media, and keep at least one copy offsite in a properly controlled environment.

The following restrictions and exceptions may apply when backing up or restoring the SharePoint 2010 Products server farm:

  • Built-in tools in SharePoint 2010 Products might not back up or restore the following:

    • Any custom solutions that have been deployed

    • Alternate access mappings

    • The Web application that hosts the SharePoint Central Administration Web site

    • The Internet Information Services (IIS) metabase

    • The Central Administration content database

    • The configuration database

      Important

      Although the configuration database and Central Administration content database can be backed up, we recommend against doing it with built-in tools on a running farm. Restoring backups of the configuration database and Central Administration content database taken from a running farm by using the tools built in to SharePoint 2010 Products or SQL Server is not supported.
      This is because data in these databases may not be synchronized with data in other SharePoint 2010 Products databases. Therefore, the tools built in to SharePoint 2010 Products do not recover these databases during a farm-level recovery operation.

      You can recover a farm, including the configuration database and Central Administration content database, in the following ways:

      • Use farm-level backups of a running farm taken with Microsoft System Center Data Protection Manager 2007 to recover an entire farm, including the configuration database and Central Administration content database. For more information, see Restore a farm in SharePoint Server 2010.

      • Restore a backup of the configuration database and Central Administration content database taken from a fully stopped farm. For more information, see Move all databases (Project Server 2010).

      If the configuration database and the Central Administration content database of a farm become unsynchronized, you must re-create both databases by using the SharePoint Products Configuration Wizard or Psconfig command-line tool.

      To protect the configuration database and the Central Administration content database:

      • Document all configuration settings and all your customizations so that you can correctly re-create the databases. For more information about recovering a farm, see Recovering your deployment in Project Server 2010.

  • Site collection backup and recovery does not support migrating a Central Administration site to a non–Central Administration site.

  • The SQL Server VSS Writer service, which is available with Microsoft SQL Server database software, must be started for the Windows SharePoint Services VSS Writer service to work properly. By default, the Windows SharePoint Services VSS Writer service is not automatically started.

  • If you want to move the backups that you created by using SharePoint 2010 Products to another location, be sure to copy and move the entire backup folder and not the individual backup folders under this folder.

  • If you want to schedule backups, you can use the Windows Task Scheduler to run them by using Windows PowerShell.

    Important

    Do not modify the spbackup.xml file. Doing so can corrupt your backup or restored farm and make it unrecoverable.

  • If you use Central Administration to back up, you cannot use other methods to restore, such as Microsoft SQL Server 2005 or Microsoft SQL Server 2008 tools.

  • If you perform a backup while any task that creates or deletes databases is running, these changes might not be included in the backup.

  • You should maintain a separate backup of all your custom solutions.

  • SQL Server does not support performing a backup to mapped drives, shares that end in "$" on remote computers, or IP addresses.

  • Backing up the Service Application does not back up the global search settings.

Task requirements

The following components are required to perform the procedures for this task:

  • Microsoft Project Server 2010 must be installed. For more information about installing Project Server 2010, see Deploy Project Server 2010 to a server farm environment.

  • The accounts listed in the following table must be enabled to do backup and recovery.

    Account Description

    SQL Server service account (MSSQLSERVER)

    If the Local System account is used for this service account, and if the shared folder is on another computer, you must give the computer that is running SQL Server Change and Read permissions to the shared folder. Alternatively, you can specify a domain user account and give that account permissions to the shared folder.

    A local administrator's account

    To perform backup and recovery by using Windows PowerShell, you must be logged on as a member of the Administrators group on the computer that holds Windows PowerShell.

    The SharePoint Central Administration application pool identity account in Internet Information Services (IIS)

    This application pool identity account is required to do backup and recovery when you use Central Administration. Therefore, the security account for this application pool must have Change and Read permissions to the shared folder that contains the backup data.

  • 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 your backup data.

  • If you are backing up by using Central Administration, the database server's SQL Server account, the Timer service account, and the Central Administration application pool identity account must have Write permissions to the backup locations. If you are using Windows PowerShell, the account that you use to log on must have Write permissions to the backup locations.

  • The database server and farm server being backed up must be able to connect to one another.

Creating a shared folder on the network

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 need 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.

Important

Membership in the Administrators group on the computer on which the shared folder is located is the minimum requirement to complete this procedure.

Create a shared folder on the network

  1. 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. For information about accounts in SQL Server, see the following resource:

  2. On the server on which you want to store your backup data, create a shared folder.

  3. On the Sharing tab of the Properties dialog box, click Permissions, and then add the following accounts:

    • SQL Server service account (MSSQLSERVER)

    • The SharePoint Central Administration application pool identity account.

  4. Select Allow for the Change and Read permissions, and then click OK.

  5. On the Security tab of the Properties dialog box, grant all the permissions except Full Control to the accounts listed in step 3, and then click OK.

Preparing to restore

You should be aware of the following before beginning to restore:

Important

Although the configuration database and the Central Administration content database can be backed up, we recommend against doing it with built-in tools on a running farm. Restoring backups of the configuration database and the Central Administration content database taken from a running farm by using the tools built in to SharePoint 2010 Products or SQL Server is not supported.

This is because data in these databases may not be synchronized with data in other SharePoint Server 2010 or SharePoint Foundation 2010 databases. Therefore, the tools built in to SharePoint 2010 Products do not recover these databases during a farm-level recovery operation.

If this data is not synchronized, users might experience various random errors.

You can recover a farm, including the configuration database and the Central Administration content database, in the following ways:

  • You can use farm-level backups of a running farm taken with System Center Data Protection Manager to recover an entire farm, including the configuration database and the Central Administration content database. For more information, see Restore a farm in SharePoint Server 2010.

  • You can restore a backup of the configuration database and the Central Administration content database taken from a fully stopped farm. For more information, see Move all databases (Project Server 2010).

If the configuration database and the Central Administration content databases of a farm become unsynchronized, you must re-create both databases by using the SharePoint Products Configuration Wizard or Psconfig command-line tool.

To protect the configuration database and the Central Administration content database:

  • Document all configuration settings and all your customizations so that you can correctly re-create the databases. For more information about recovering a farm, see Restore a Project Server 2010 farm by using built-in tools.

  • Consider a redundancy solution, such as clustering or mirroring, for the computer running SQL Server that is hosting the configuration database.

  • Project Server 2010 does not support a backup made from one version to be restored to another version of Project Server 2010. To do this, use the upgrade process.

  • If you are restoring by using the SharePoint Central Administration Web site, then the database server's SQL Server account, the Timer service account, and the Central Administration application pool account must have Read permissions to the backup locations.

  • If you are using Windows PowerShell, the account you logged on with must have Read permissions to the backup locations.

  • If the crawl-related account's credentials have changed between the time you backed up and the time you restore, you must reenter all crawl-related passwords after a restore is performed. This includes the password of the default content access account and each of the include crawl rules that has credentials.

  • Before restoring a service application on a stand-alone installation, the administrator must manually start the Microsoft SharePoint Service Application Administration service so that search can be provisioned. This service is required to create the search directories on the local server. These directories hold the search index files.

  • On stand-alone installations, you must restart the Timer service before restoring the service application.

  • If you are restoring or migrating search services and indexes to a new installation, make sure the search service is running before performing the recovery.

    After restoration, search might take up to 15 minutes to be available again.

  • Make sure that the synchronization service is paused before restoring any Web applications.

  • Be aware that you cannot perform more than one recovery from the same backup at the same time.