Executive Summary:

Many organizations are using Microsoft's SharePoint platform as a crucial document management system and collaboration tool. Unfortunately, SharePoint provides no native item-level recovery of documents or list items stored within SharePoint. However, Microsoft System Center Data Protection Manager (DPM) 2007 gives administrators a rich set of recovery tools that offer advanced snapshot-based recovery of item-level SharePoint content as well as the entire SharePoint infrastructure.

Microsoft SharePoint Products and Technologies have become a crucial component of the infrastructure in many organizations, with the platform serving as a mission-critical document repository and collaboration tool. Unfortunately, the platform’s built-in backup and restore capabilities have never really delivered the type of enterprise capabilities that organizations have come to expect. Of particular note is the fact that there’s no native way to provide for item-level recovery of documents or list items stored within SharePoint. With the release of Microsoft System Center Data Protection Manager (DPM) 2007, however, administrators have access to a rich set of recovery tools for Share- Point, allowing for advanced snapshot-based recovery of SharePoint content from within a simple but powerful interface. As with any new technology, there are tips and tricks involved with DPM’s deployment and caveats that you need to take into account. Read on to learn what it takes to deploy DPM into a Windows SharePoint Server (WSS) 3.0 or Microsoft Office SharePoint Server (MOSS) 2007 environment, including best-practice architectures and maintenance requirements of the application.

Introducing System Center Data Protection Manager 2007
In the past, organizations that required robust enterprise backup and restore capabilities for SharePoint either purchased third-party software or constructed an elaborate process of invoking command-line utilities such as Stsadm that performed site-collection-level backups. Although many of these third-party products offer great functionality for SharePoint, they can be expensive and cumbersome to use. Microsoft was on the line to produce a utility that could easily manage and back up SharePoint on its own terms, allowing both for dayto- day recovery of individual items within SharePoint and for full-scale disaster recovery of the entire SharePoint infrastructure.

System Center DPM is Microsoft’s foray into the enterprise backup space. It’s the second generation of a product that was designed to provide simple but powerful backup capabilities for Microsoft infrastructures, including the Windows OS, Microsoft SQL Server, Exchange Server, and SharePoint. Microsoft developed DPM to integrate directly with Windows’ Volume Shadow Copy Service (VSS), allowing the product to create snapshots of data on a protected system as frequently as every 15 minutes. This means you could potentially configure DPM to recover a failed server to a point in time no more than 15 minutes in the past.

DPM offers two distinct benefits for SharePoint administrators. The first is the ability to take a VSS snapshot, back up the SharePoint SQL databases, and provide upto- the minute restoration capabilities. The second benefit is DPM’s SharePoint-aware item-level recovery capabilities, which allow administrators to restore items from the moment of the last recovery point. It’s important to note that SharePoint content databases and SharePoint content, although the most critical components to backup in a SharePoint environment, don’t provide for restores of the SharePoint indexes, Web part binaries, or the IIS metabase on Web front ends. These components should be backed up using SharePoint’s XML-based backup that is included in the product.

DPM also allows for other advanced functionality such as Exchange database and mailbox-level recovery capabilities, bare-metal recovery of servers, and the ability for end users to restore earlier file versions directly from protected file servers simply by using Windows Explorer. In addition, Microsoft makes DPM administration robust and simple using either a PowerShell console or the standard GUIbased DPM Administrator console, which Figure 1 shows. To keep managers happy, the console also includes a series of built-in reports, such as the ones shown in Figure 2. These capabilities position DPM as a powerful tool not only for SharePoint, but for any Microsoft-focused organization.

Designing a SharePoint DPM Solution
DPM performs backups from a central console server. This server is directly attached to any disk volumes or tape backup libraries to which data will be backed up. DPM performs both short-term (backup to disk) and long-term (backup to tape) content protection, and you can configure it to “expire” content from the disk-based storage and archive that content to tape.

I highly recommend DPM’s short-term backup-to-disk capabilities. They allow an organization to perform backups quickly, without the need to spool to tape. To use this option, you need to allocate a large chunk of disk space to the DPM console. Typically, the types of disks presented to DPM are slower, cheaper disks such as 7200rpm Serial ATA (SATA) drives on a SAN, or a large DAS storage enclosure. The amount of space required will vary depending on how much data DPM is backing up, how frequently it takes snapshots of the data, and how often it performs Express Full Backups. (DPM defines Express Full Backups as backups that include all data from the target, but transfer only changed files, reducing the amount of time and bandwidth that the backups take.) In addition, a SharePoint item-level recovery backup is a separate type of backup from a SharePoint SQL database backup, so you might need to allocate more disk space for this type of backup to have the most flexibility with the SharePoint restores.

To illustrate, let’s say you have 500GB of data stored in SharePoint content databases. Because the backup-to-disk volumes used must be larger than the size of the data, you would need approximately 700GB to 800GB of space on the backup-to-disk volume just for the SharePoint SQL database backups and the snapshots associated with them. In addition, you need to set aside 600GB to 800GB of space for backups of SharePoint items, as these types of backups are stored on different volumes than the SQL backups are stored. Total amount of space consumed to back up 500GB of SharePoint content could easily eclipse 1.5TB on the DPM console in this scenario. Therefore, it’s important to plan out the disk infrastructure required for DPM’s backup-to-disk capabilities.

Incidentally, one common mistake administrators make when allocating disk space to DPM is that they create or format volumes before presenting them to DPM through the Management tab of the console. However, DPM prefers unformatted, raw disk space, because it creates a large number of smaller volumes as part of its provisioning process. You should simply add raw disk space to the server and add the disks to the console as needed.

Using the DPM System Recovery Tool
It’s not immediately obvious how to back up the DPM console, but it’s highly crucial to do so to prevent the backup infrastructure from collapsing. Microsoft provides a separate tool, known as the DPM System Recovery Tool (SRT), which Figure 3 shows, for backing up the DPM console. The tool lets you create a boot disk and provides bare-metal recovery of any server it backs up. This essentially lets you recreate the exact running state of any server, even if the original server no longer exists.

There are a few key points that are important to understand about the DPM SRT. First, the tool is completely independent from the standard DPM product. It installs from separate media, uses its own agents, and operates independently. Second, by default, the SRT keeps all system backups indefinitely, which could cause the server to quickly run out of disk space. Be sure to configure the server to keep only a specified number of backups. Finally, remember that without SRT, a DPM infrastructure has a major Achilles heel: If the DPM console goes down, all backup history and logs will be lost, and recovering the data would be a challenge.

Preparing Servers for Backup
There are several prerequisites you need to satisfy before you install DPM and before it can protect managed servers. First, the DPM console must have access to its own SQL Server database for storing DPM-specific configuration and job information. Best practice would be to use a local SQL Server Express database on the DPM console server, as storing the database on a protected server could be catastrophic if that server went down.

You should also install both Microsoft IIS and Windows Deployment Services (WDS) on the machine before you install the DPM software. From experience, I can tell you that if you forget to install IIS and WDS in advance, DPM installation will likely fail, particularly if the server you are installing DPM on is running Windows Server 2003 SP2. You must also install PowerShell 1.0 and the VSS patch referenced in the Microsoft article “Availability of a Volume Shadow Copy Service (VSS) update rollup package for Windows Server 2003 to resolve some VSS snapshot issues,” at support.microsoft.com/kb/940349.

Continue to page 2

The DPM console must be installed with Windows Server 2003 SP1 or R2, as Windows Server 2008 is not yet supported. I also recommend that you install the 64-bit version of both Windows and DPM 2007, because memory support is better, and the system will scale much better than a 32-bit version will. As a side benefit for Exchange Server 2007 administrators, installing the 64-bit version of DPM lets you run the native version of Eseutil against backed up copies of Exchange databases.

All managed servers must be running Windows 2003 SP1 or later and have the KB940349 patch installed. SQL servers must be either SQL Server 2005 SP1/SP2 or SQL Server 2000 SP4, and must have the VSS Writer service running.

To perform an item-level backup of SharePoint, the SharePoint Web front-end servers must satisfy their own specific requirements. This involves installing a SharePoint-specific patch referenced in the Microsoft article “Description of the Windows SharePoint Services 3.0 post-Service Pack 1 hotfix package: January 31, 2008,” (support.microsoft.com/kb/941422), starting the VSS Writer service, and providing the protection agent with the credentials for the MOSS/WSS farm. This last step is a bit more involved, but essentially involves running the ConfigureSharePoint.exe tool from the SharePoint Web front-end server. This tool, located in the \bin subfolder of the DPM installation directory on the DPM server, prompts you to enter the farm administrator credentials for SharePoint. You must re-run the tool whenever the farm administrator credentials change.

And, of course, before any backups can take place from the console, you must deploy specialized DPM agents to any system that will be backed up. These agents, deployed and administered from the console, as Figure 4 shows, can be pushed out to systems using an account with local admin rights on the servers. After you’ve satisfied all prerequisites and pushed out the agents, you create the initial backup replicas via the use of Protection Groups.

Creating a Protection Group
DPM uses the concept of a Protection Group, such as the ones that Figure 1 shows. Each Protection Group provides for different schedules, snapshot frequencies, and retention ranges, which you configure when you create the Protection Group. For each Protection Group, a replica volume and a recovery point volume is created for each protected resource. For SharePoint content databases, this means that each protection group will create two volumes for every content database. The recommended sizes for the replica and recovery point volumes will change based on criteria you specify when creating the group, so it’s not a bad idea to play around with those numbers to see how performing additional Express Full Backups or taking snapshots of data more often increases or decreases recommended volume size. Bear in mind that the recommended size for each of these volumes is determined according to the current size of the database, so you should increase the volume sizes if you anticipate that content database size will increase.

It’s crucial that you understand the difference between a SQL content database backup and a SharePoint item-level backup. The SQL content backup is based on VSS snapshots, but an entire database would need to be recovered in the event of data loss. These types of backups are geared toward scenarios involving disaster recovery. The SharePoint item-level backups, which are performed against a SharePoint Web front-end server, aren’t snapshot-based, so items can be recovered only at the point of the last Express Full Backup, but this type of backup lets you recover individual items without initiating a full database restore.

Restoring Content
The Recovery tab of the DPM console is where administrators can initiate restores of individual SharePoint items or of entire SharePoint content databases. You can restore SharePoint SQL content databases from SQL backups—either by overwriting an existing database or recovering it to a different SQL Server instance or even a flat network folder.

SharePoint item-level recovery using the DPM console simply requires navigating through a folder hierarchy to find the individual document or list item and restoring it to the SharePoint site. Assuming the item hasn’t been archived to tape, it’s immediately restored to the site.

Understanding DPM Licensing
DPM licensing costs are calculated according to the type of server being backed up. Standard Windows servers, such as file servers, require a DPM standard license; application servers such as Exchange, SQL Server, and Share- Point servers require an enterprise license. Your organization might already own DPM licenses, particularly if you’re invested in other System Center products such as Operations Manager 2007 or Configuration Manager 2007. It’s best to check with Microsoft to see what type of deal you can obtain.

Not Perfect, But...
For those organizations heavily invested in SharePoint and without a current itemlevel recovery product in place, DPM is an excellent choice. DPM is an impressive product, and there’s something quite magical about how simple it is to restore an entire environment painlessly with a few mouse clicks. It’s not perfect—I’d personally like to see the ability to install multiple redundant primary consoles, for example—but all in all, it’s an excellent tool to provide for enhanced recovery and protection capabilities for a SharePoint 2007 environment.