|
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.
This diagram gives a very high level overview of the process and why it allows us to protect all SharePoint content:
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).
Don’t see all the options listed above? You don’t have SP1 for DPM installed and/or the agent on this machine hasn’t been updated. Pre-SP1 there was no options for this utility, it simply prompted for a username and password.
Once this operation is complete, you will notice the ‘Windows SharePoint Services VSS Writer’ Windows service is now started and set to use the credentials you specified.
More information about using ConfigureSharePoint.exe can be found here: http://technet.microsoft.com/en-us/library/dd441708.aspx.
But what about ‘stsadm –o registerwsswriter’, what’s that command for? You do not need to run this command when you use ConfigureSharePoint.exe, it does the equivalent operation on your behalf and is just used for activating the service.
Hang on, what is WSSCmdletsWrapper?
When running ConfigureSharePoint.exe we saw a reference to another utility called WSSCmdletsWrapper. We also see entries for this in the SharePoint logs when protection is up and running (more on this in part 4), so what is it?
WSSCmdletsWrapper is a DCOM application registered as a server on the WFE. It is used to connect the SharePoint Object Model (managed code) to the unmanaged DPMRA service. So basically we use ConfigureSharePoint.exe to give the WSSCmdletsWrapper process access to the SharePoint farm via the SharePoint Object Model. This then passes information to the DPM replication agent (DPMRA) service. This process is used for all jobs requiring access to the SharePoint farm.
Creating a Protection Group
Now we have a high level understanding of how DPM works with SharePoint under the hood, let’s look at how you actually protect SharePoint from the DPM UI.
Once you have run ConfigureSharePoint.exe from the WFE being used to interface with DPM, the SharePoint farm will appear in the UI when creating a protection group using the wizard. As shown below, when protecting a SharePoint farm, you only need protect it with a single check-box in the UI via this WFE. The farm is displayed in the name format: ‘Server\ConfigDBName’.
If you have not properly run ConfigureSharePoint.exe and registered the WSSCmdletsWrapper DCOM application, then the SharePoint farm seen in the UI above will not appear. To rectify this re-run the utility.
In the example above, you will also notice 2 other items. The SPSearchComponent and the SSPComponent. These are shown because I ran ConfigureSharePoint.exe with the ‘EnableSPSearchProtection’ parameter that is now included in DPM SP1. More on this in part 6 – What about Search?
Once you have specified your protection goals, configured any other settings and created the initial replica, DPM will be protecting your SharePoint farm according to your schedule! It’s that easy.
Note: DPM protects SharePoint by using Express Full backups only, for a complete explanation of this and the process under the hood, see the following webcast: http://edge.technet.com/Media/DPM-2007-SP1-How-does-DPM-really-work.
In part 3, I look at how DPM restores SharePoint data at the various levels available, from the entire farm down to a single item. As part of this I will look at how to create a recovery farm for item level recovery, why it is required and the caveats you should be aware of. |