Backup / Restore of Microsoft SharePoint Server 2007 (VSS-aware backup sets)

This article covers various backup / restore issues for Microsoft SharePoint Server 2007 backups (using the VSS-aware backup set type).


Functionality	DS-Client (VSS-aware Backup / Restore)
Server farm, except the configuration and Central Administration databases	Yes
Configuration and Central Administration databases	No (Microsoft does not support this capability)
Web applications	Yes
Site collections	Yes
Content databases	Yes
Databases for Shared Services Providers	Yes
Search databases for Shared Services Providers	Yes
Search databases	Yes
Windows SharePoint Service Search	Yes
Office SharePoint Server Search	Yes

The following requirements must be met before you can back up / restore SharePoint servers with the DS-Client’s VSS-aware backup set type.

• On every target SharePoint machine you want to back up, manually start the Windows SharePoint Services VSS Writer service:

1. Open Administrative Tools > Services and start the service. By default, this service must be manually started, however you can configure it with the Automatic startup type.

2. Register the Writer in the Windows registry by running the “STSADM -o registerwsswriter” command from command prompt. The executable is located in the <%Program Files%>\Common Files\Microsoft Shared\Web Server Extensions\12\Bin\ directory.

• The Windows SharePoint Service Search (SPSearch) should be running on the SharePoint web server if you want to backup SPSearch.

• The Office SharePoint Server Search (OSearch) must be running on the SharePoint web server if want to backup OSearch.

• If you are backing up a SharePoint Farm (not a standalone machine), the following additional requirements must be met:

• Add the IP address and computer name for all the Microsoft SQL Server(s) and SharePoint Web servers in the Farm to the DS-Client computer’s “Hosts” file, which is found in:

• The Windows SharePoint Services VSS Writer service must be running on one of the SharePoint web servers.

• The SQL Server VSS Writer service must be running on every Microsoft SQL Server machine in the SharePoint Farm.

• Manually document all the configuration settings in Office SharePoint Server to correctly re-create the configuration database and the Central Administration content database of a SharePoint Farm. Microsoft (KB article #512815) recommends documenting the following settings:

• Application pool settings, including service accounts (all accounts that run as Web applications, including the crawler account and the search account).

• Web application names and databases. Be sure to document the content database names associated with each Web application.

The Microsoft SQL databases used by SharePoint can support differential backup (see the Knowledge Base Article for Microsoft SQL Server in “Database Backup Policy”).

During a restore, there are two phases: The first phase restores the SharePoint server’s Microsoft SQL full dump. The second phase restores the SharePoint server’s Microsoft SQL differential backups (if applicable) as well as OSearch and SPSearch.

• Before restoring a Web Application, any existing Web Application with the same name must be deleted from SharePoint Central Admin.

• Before restoring OSearch, you must ensure the SharePoint Service provider (SSP), associated databases and index files do not exist in the original location. Do not remove the web application if the SSP is ‘Administration site host’ for Shared Services. It is not possible to remove the last SSP by using Central Administration. You will need to use the “stsadm” command:

The following considerations must be made if you want to restore a VSS-aware SharePoint backup to an alternate location.

• A VSS-aware SharePoint backup set supports only renaming the SQL database component in an alternate restore.

• You can only rename the SQL database name. However, this will not rename the internal .mdf and .LDF files of this database. Before performing the restore, ensure that there is no file of the same name in the target data directory, otherwise the restore will fail.

For example: If the original database name is ‘abcd123’, then the internal database and log files will likely be ‘abcd123.mdf’ and ‘abcd123.LDF’. If you restore the Microsoft SharePoint Server to an alternate location and rename the database to ‘xyz1234’, the internal files will still be ‘abcd123.mdf’ and ‘abcd123.LDF’.

NOTE: Whatever name you want to use for the database, it must already exist in the Microsoft SharePoint Server. This is because the VSS-writers need to be able to link the restored data to the new database name. (In the previous example, this would mean linking the ‘abcd123.mdf’ and ‘abcd123.LDF’ files to the ‘xyz1234’ database.)

• Renaming components: It is useful to rename the SQL Server component of a SharePoint server only in the following scenarios.

• Scenario 1: The source database name already exists in the target SharePoint Farm (i.e. it is being used by another database).

2. Alternate restore the SharePoint server and rename the database component to the database created in step 1.

3. After the alternate restore is finished, in the SharePoint server application, create a new web application using the restored database.

• Scenario 2: The target database has a different database name from the source, however it does have the same databaseid and siteid as the source.

• Alternate restore the SharePoint server and rename the database to the same name as on the target location (i.e. the database that has the same databaseid and siteid but different database name).

1. After restoring Web application, go to the SharePoint Central Administration web page, click on 'Application management', 'create or extend web application', attach the content database to a new web application.

b) Restore ssp using "stsadm -o restoressp" operation on a WFE and make sure to use the "KeepIndex" parameter. This "hooks up" the SharePoint Service provider (SSP) you restored to the SharePoint Farm".

3. After restoring SPsearch, restart the Windows SharePoint Services Search service from Administrative Tools > Services.

Microsoft’s VSS has special requirements for accounts running the writers on all target server instances for backup and restore:

• To configure this account from the target computer, click Administrative Tools > Services, select the corresponding VSS Writer Service and right-click on Properties. In the Log On tab, configure the account that runs the writer.

• The account must have permission to issue BACKUP DATABASE and RESTORE DATABASE commands to the target database servers.

• The account must have permission to access Microsoft SQL Server, which requires it to be a member of the SQL Server sysadmin group.

After restoring from a SharePoint VSS-aware backup set, you try to create a new web application in the restored SharePoint server (for example, using “WSS_Content_1080”). When you do, SharePoint returns errors similar to the following:

“The attach operation cannot continue because another object in this farm already contains the same ID. ...”

“An object of the type Microsoft.SharePoint.Administration.SPApplicationPool named "SharePoint - 1090" already exists under the parent Microsoft.SharePoint.Administration.SPWebService named "". Rename your object or delete the existing object.”

“An update conflict has occurred, and you must re-try this action. The object SPWebApplication Name=Sharepoint -1080 Parent=SPWebService is being updated by <Domain>\<User>, in the OWSTimer process, on machine <Computer>. View the tracing log for more information about the conflict.”

This is a known Microsoft issue. Before any SharePoint database is restored, you must ensure that there is no existing database ID (of the same number). If there is, it must be completely removed from SharePoint (including any shared applications).

Refer to the Microsoft KB article 939308 (http://support/microsoft.com/kb/939308). This article explains how to clear the file system cache on all servers in the server farm on which the Windows SharePoint services timer service is running.