From The Field

It’s been a while since I posted part 1 of this series where I looked at the questions you may ask when choosing a backup and recovery tool for SharePoint, and how these questions are answered from a DPM on SharePoint point of view.

In part 2, I look at how DPM really protects SharePoint data. I won’t be getting into how VSS works and how DPM copies block level differences, for that I recommend you watch this excellent webcast by Jason Buffington: http://edge.technet.com/Media/DPM-2007-SP1-How-does-DPM-really-work. I will however be going in to detail about the components required for SharePoint protection, along with how they work and the stages in setting them up.

Prerequisites

Before attempting to protect a SharePoint farm, you should ensure your DPM server is fully configured with all required updates and storage pool disks. In addition, it is important that you have SP1 for SharePoint and the post SP1 hotfix for WSS 3.0 installed (or a newer cumulative hotfix). This hotfix has a number of fixes/enhancements for the VSS writer service used by SharePoint.

VSS and the WSS Writer Service

The Windows SharePoint Services VSS Writer is the first key component used for protecting a WSS 3.0 or MOSS 2007 farm down to the item level by using DPM.

DPM works by using application specific VSS writers to protect application data. The SharePoint VSS writer is a referential writer that enables backup applications like DPM to use a single writer interface to call upon other VSS writers such as the SQL Server VSS writer.

This is crucial from a SharePoint perspective and is what allows us to protect everything in a SharePoint farm including the Configuration database and Central Administration content database. Typically we are not supported to restore these databases as there is no way to ensure their consistency with the rest of the farm.

However, with VSS and DPM we can because VSS will used the WSS Writer to freeze and snapshot all associated content at once, thus ensuring we have a consistent point in time replica of the content being protected! The VSS Writer also means we can protect an entire SharePoint farm with a single checkbox, more on this later.

For much more in-depth information and some nice diagrams about the SharePoint VSS Writer, and the way it works I recommend you read the following articles: http://msdn.microsoft.com/en-us/library/bb417460.aspx and http://msdn.microsoft.com/en-us/library/bb417449.aspx.

DPM Agent

As shown in the diagram, the DPM Agent is the second key piece required to protect a SharePoint farm. The agent is used for communication between the DPM server and each server hosting protected content.

The agent should be deployed on all servers that have content requiring protection. For example in a simple 5 server farm (2 WFE's, an Index Server and a 2 Node Clustered SQL Server), you would deploy the agent to the SQL Servers, the Index Server (if you want to protect Search) and ONE of the Web Front Ends.

So why not the other WFE? Well since the Web Front End servers do not host content, you only need to protect one to protect your entire farm. In fact this server is only really used to serve as an entry point for DPM to protect your farm. There is no reason why you couldn't protect the farm by deploying the agent to just the Index Server and SQL Servers. This would however mean that you couldn't grab system state and directories on the WFE that contain customisations.

Configuring the WSS Writer Service

Once you have the agents deployed to each server requiring protection, you need to let DPM know that there is a SharePoint farm requiring protection and give it permissions to access that farm. Note: The account used should be farm administrator and local administrator on the WFE.

To do this there is a utility available called ConfigureSharePoint.exe. The utility can be found in the <DPM Installation Path>\bin folder of the WFE that you have deployed the protection agent to. This utility configures the WSS Writer service and any associated services with the correct credentials required to access the farm for backup and recovery purposes. It also allows you to configure other options such as protection for search and the temp folder location (more of this in parts 5 and 6).