Hot Split Snapshot Backups of SharePoint Portal Server (323584)

MORE INFORMATION

You can use the SharePoint Portal Server Backup Application Programming Interface (API) to perform backups of SharePoint Portal Server databases while the SharePoint Portal Server services are running, thereby avoiding service interruptions. Some third-party backup software vendors, such as Veritas, use add-on software agents or modules to implement this API.

For additional information about backing up SharePoint Portal Server databases, click the article numbers below to view the articles in the Microsoft Knowledge Base: SharePoint Portal Server is becoming increasingly important in enterprise environments. As a result, you must be able to quickly back up and restore the dashboard site without affecting users. However, a standard backup of SharePoint Portal Server causes three issues:

• Changes made to the dashboard site between the time of the backup process and the time of the restore process are lost.
• The larger the dashboard site grows the longer the backup and restore process takes.
• The dashboard site must be offline to all users for the whole restore process.

EMC Corporation Quick Recovery Solution

EMC Corporation developed a quick recovery solution for Microsoft Exchange Server by using EMC TimeFinder™ software to create Business Continuance Volumes (BCVs) in the EMC Symmetrix® line of storage products, and using EMC SnapView™ and MirrorView™ software to create replicas in the EMC CLARiiON® line of products. This solution is now available for SharePoint Portal Server. The solution leverages EMC Split Mirror technology to create full, on-disk replicas (sometimes referred to as snapshots) of the critical volumes on which the SharePoint Portal Server data resides.

You can mount these replicas to a separate computer for any purpose, for example, integrity checking and backup to tape. If a failure occurs on the production database, the snapshot can replace the damaged database almost instantly, and then be brought up to date with all the changes from the time that you created the replica or snapshot. Users experience almost no downtime (if the process is scheduled at a low-impact time) with no data loss.

For more information about these EMC products, visit the following EMC Corporation Web site: Microsoft provides third-party contact information to help you find technical support. This contact information may change without notice. Microsoft does not guarantee the accuracy of this third-party contact information.

NOTE: EMC, EMC², Symmetrix, and CLARiiON are registered trademarks. TimeFinder, SnapView, and MirrorView are trademarks of EMC Corporation.

Testing and Validation

Representatives from EMC Corporation built a Symmetrix-based Storage Area Network (SAN) in the SharePoint Portal Server development lab with the assistance of the SharePoint Portal Server development and test teams to test and validate this process. This test provided a supportable solution that you can use if you follow the steps in this article.

This article describes the procedure to configure EMC (or another storage vendor with applicable technology) to create a Microsoft-supportable scenario. You can use this procedure until EMC Corporation develops an automated solution for SharePoint Portal Server snapshots.

To Back Up the Database

WARNING: If you use Registry Editor incorrectly, you may cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that you can solve problems that result from using Registry Editor incorrectly. Use Registry Editor at your own risk.

NOTE: The database restore process deletes the checkpoint file; you may want to have a copy of the checkpoint file on the replica for troubleshooting purposes.

Circular logging automatically replaces Microsoft Web Storage System transaction logs as the program slowly writes their contents to the database. By default, circular logging is active on SharePoint Portal Server. You must turn off circular logging to keep the complete set of transaction logs that you need to fully update the database during a recovery. For SharePoint Portal Server, you must use Registry Editor to turn off circular logging.

To back up the data:

1. Turn off circular logging, and then change the location of the checkpoint file (working directory) to your mirrored log file volume.
   1. Start Registry Editor.
   2. Locate the Circular Logging value under the following registry path:

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\CfgData\Objects\{11111111-2222-3333-4444-555555555555}

      NOTE: The globally unique identifier (GUID) value {11111111-2222-3333-4444-555555555555} varies between installations of SharePoint Portal Server. Because there may be several GUID keys listed under the Objects key, you must locate the correct GUID key by finding the Circular Logging value.
   3. Set the Circular Logging value to 0.
   4. Make sure that the Working Directory value and DB Log Path values are the same.
   5. Quit Registry Editor.
   6. Shut down the Microsoft Exchange Information Store service, which also shuts down the SharePoint Portal Server service.
   7. Start the SharePoint Portal Server service, which also starts the Exchange Information Store service.
2. Back up SharePoint Portal Server immediately, before you start the snapshot process.
   
   You get two benefits when you back up SharePoint Portal Server at this point:
   
   
   • You make sure that you can successfully restore the whole dashboard site if a failure occurs that goes beyond the Web Storage System database.
   • You make sure that you can delete the log files at the appropriate time without accidentally deleting logs that you need to restore the dashboard site.
   When circular logging is turned off, the program does not automatically overwrite logs because they are fully committed to the database. You must "groom" the logs by a separate process. The online SharePoint Portal Server backup performs this function.
   
   For more information about how to use snapshot technology to make sure that a good online backup image is always available, see the Creating a Resilient SharePoint Portal Server Backup section later in this article.
3. Check the event log for problems.
   
   The database replica is your standby copy for quick recovery. Do a final check of the event log for evidence of physical corruption on the production database (for example, 1018 errors) before you resynchronize the mirrors, which overwrites the event log.
4. Use snapshot technology to create a full, on-disk snapshot.
   
   Do not create a copy-on-first-write snapshot. This type of snapshot is dependent on the original data. You can restore the database from a full, on-disk snapshot even after the first volume has failed or after a significant passage of time (which indicates a large number of changes). Additionally, you can perform activities on the snapshot, such as backup to tape or integrity checking, with no performance impact on the production server.
   
   You must create the snapshot both instantly and exactly between Input/Output (IO) operations.
   
   NOTE:
   
   
   • If you do not create the snapshot exactly between IOs, there is a significant chance that you may destroy the database on the snapshot. If you do so, you cannot create a quickly recoverable image.
   • If you do not create the snapshot immediately, users are likely to experience significant delay and the server may time out, which potentially causes permanent damage to the data files.
   If your NTFS file system partition is formatted with 4k clusters, EMC Snapshot occurs both instantly and exactly between IOs.
5. Mount the snapshot on a separate system, and then do an integrity check to make sure that the snapshot process or any problem that occurred before you took the snapshot has not corrupted the data on the snapshot.
   
   You must run eseutil.exe /i /k on a separate "recovery" computer to look for torn pages or checksum errors. To do so, run the following command to specify the path to the snapshot copy of the database:

   eseutil.exe /i /k drive:\folder\wss.mdb

   If eseutil.exe returns anything other than 0 wrong page numbers or 0 bad checksums, you must resynchronize the snapshot, resplit the database and log volumes, and then verify the copy of the database by running eseutil.exe again.

To Restore the Database

To restore the data:

1. Stop the Exchange Information Store service, which stops the SharePoint Portal Server service.
2. Delete the checkpoint (.chk) file.
3. Flush the data volume cache, and then dismount the data volume.
   
   To do so, use either diskpar, diskpart, mountvol, symntctl, or EMC Symmetrix Integration Utilities or shut down the server.
4. Restore the snapshot.
   
   To do so, either overwrite the newer, damaged production data with the older snapshot or point the server to the snapshot volume instead of to the old production volume.
5. Either mount the volumes or restart the server, depending on the method you used to dismount the data volume in step 3 of this procedure.
6. Restart the services. The services restart automatically if you shut down the server in step 3 of this procedure.

The SharePoint Portal Server service does not start until the Exchange Information Store service has fully started because the SharePoint Portal Server service is dependent on the Exchange Information Store service. To apply the database logs that the SharePoint Portal Server service needs, the Exchange Information Store service replays all transactions that occurred to the database between the time you took the snapshot and the time you restored the snapshot.

When you follow the steps in this article, you produce a database that is free from the physical damage that caused the need for the restore process, and that has all of the data that the original database had. After you complete this process, the SharePoint Portal Server service starts with no changes to the underlying Web Storage System database. SharePoint Portal Server functions properly again, with very little scheduled downtime and no data loss.

Creating a Resilient SharePoint Portal Server Backup

If you follow the steps in this article to create snapshots of the Document Library and create a robust framework for full SharePoint Portal Server backups, you help complete a full SharePoint Portal Server recovery plan.

Microsoft recommends that you back up SharePoint Portal Server to a device in the same storage system as the rest of the SharePoint Portal Server data components, and then create snapshots of that volume. As soon as you create a snapshot, you can mount the snapshot on the same server that performs the recovery check on the snapped database. After the integrity check verifies that the data is valid, you can archive both the snapshot of the database and the snapshot of the SharePoint Portal Server backup file to tape, without consuming any resources on the production SharePoint Portal Server computer. After you do so, you can safely delete the backup file from the original volume to make space for additional backups. If something fails when you make the "new" backup, you can quickly restore SharePoint Portal Server from the backup file on the snapshot, and you will not have to wait for the data to come back from the tape.