As powerful as the SharePoint Backup tool appears, it does not contain all the elements necessary to recreate your...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
SharePoint environment. While SharePoint stores all of its content in SQL Server (documents, images, text, security, site metadata, and so on), there is a collection of files on the file system that are not in the database, and therefore they do not get properly captured in a backup.
The following items play a pivotal role in the generation of SharePoint pages but are not covered in the SharePoint backup:
- Third-party or custom Web parts
- SharePoint site definitions and XML files
- SharePoint .aspx template pages
- SharePoint script files
The first step in a successful recovery process is the restoration of the environment using the Backup/Restore tool. The subsequent steps involve bringing in any elements that were not captured in the SharePoint backup. The biggest piece of this is the inclusion of nonnative SharePoint Web parts. Whether purchased from a vendor, acquired online, or custom built, Web parts must be registered in a specific way in order for SharePoint to consider them "safe." While this is not a chapter on deploying SharePoint Web parts, let's quickly touch on the two main requirements for a successful Web part deployment.
First, the associated DLLs need to be placed on the file system, either in the underling BIN directory of the virtual server or in the Global Assembly Cache (GAC). Second, the Web part must be placed in the list of Safe Controls. This is done in the SharePoint Web.config file. If you examine this file, you'll notice a collection of Web part registrations under the SafeControls node. All Web parts, even native SharePoint Web parts, must be registered here. The challenge from a DR perspective is that this file, Web.config, and the associated Web part DLLs are not captured in a SharePoint backup.
If these steps are not executed in a restoration process, the SharePoint pages that contain the respective Web parts will not properly generate (they may not generate at all, redirecting you to a generic error page). Therefore, it is important to take inventory of all nonnative Web parts used and to store the associated CAB or install files for future restoration. You may even do this in the SharePoint document library to ensure that they do get captured in the SharePoint backup process.
In addition to Web parts, other system files might be altered through standard or advanced SharePoint customization. These files include underlying xml, aspx, and script files. All SharePoint file system files reside in the following directory:
C:\program files\common files\microsoft shared\Web server extensions\12
It is important to note any changes made to files in this directory and to take appropriate measures to document the alterations in your DR plan. Table 7.1 shows an example of a section that you should include in your disaster recovery plan so that you can track these changes.
Table 7.1 A Change Log Is Important for Customizations Made to SharePoint Because There's No One Place for Custom SharePoint Artifacts
|Date||Description||Location||Made By||Approved By|
|4/20||Updated portal.js to accommodate customization||\12\TEMPLATE\LAYOUTS\portal.js||mcardarelli||sjamison|
|5/18||Added logo.jpg file||\12\TEMPLATE\IMAGES\logo.jpg||mcardarelli||sjamison|
Outside the bounds of the SharePoint-related files necessary for full portal restoration, but equally important, is the need to have a plan in place to ensure that any replica environment stays consistent with the software, patches, and third-party Web parts deployed in the original environment. A disaster recovery plan should always denote the current state of the SharePoint servers and should be updated as changes are made.
NOTE: Because the MOSS 2007 DR tools are somewhat anemic, many enterprise customers opt to purchase a third-party backup and restore tool. For example, DocAve 4.1 from AvePoint enables SharePoint administrators to monitor multiple SharePoint 2003 and 2007 farms across the globe, perform item/ subsite/site-level data backup, full-fidelity restore, within or cross-site content management, seamless data archiving, and site-specific "one-switch" disaster recovery from a single Web UI.
TABLE OF CONTENTS
- Part 1: Creating a Microsoft SharePoint disaster recovery operations document
- Part 2: Understanding Microsoft SharePoint Server backup and restore options
- Part 3: Using the Microsoft SharePoint Server 2007 backup tool
- Part 4: Managing Microsoft SharePoint Server 2007 backup files
- Part 5: Using the Microsoft SharePoint Server 2007 restore utility
- Part 6: Scheduling a Microsoft SharePoint Server 2007 backup
- Part 7: What's not covered by a SharePoint Server 2007 backup
This chapter excerpt from Essential SharePoint 2007, by Scott Jamison, Mauro Cardarelli, and Susan Hanley, is printed with permission from Addison-Wesley Professional, Copyright 2007.