With SharePoint gaining popularity in the last year and the recent release of DPM 2007 which supports the protection of SharePoint this has become a hot topic in the last few months. The protection and recovery of SharePoint data is not small undertaking and there is quite a bit of flexibility with what you can recover. For this reason, let me caution you in that this can be a complex undertaking but once the methods are understood, its benefits far surpass the trouble of the initial learning curve.
So let’s start with the basics of what is required in order to protect SharePoint with DPM and we will expand from there. Over the course of this series, we will cover protection and recovery on several various levels, each of which will have it’s own nuances which dictate this breadth of coverage.
We begin with the Protection Requirements. Below is a list of what is needed to fully protect and recover SharePoint data.
Let’s start with the following assumptions:
With this configuration, we can restore any site to its original or alternate location or we can also recover a Content Database or the entire Farm.
To start and register the WSS Writer service:
After a moment of configuring, the entry "The command completed successfully" will appear and the CMD window will close.
DPM only offers the option of protecting the entire SharePoint farm as seen in the screenshot below. This changes when the discussion revolves around recovery of data, as we will see in the next section. DPM provide a great deal of granularity when it comes to recovery of SharePoint data.
If the WSSCmdletsWrapper is not registered properly, then the SharePoint farm you see in the screen shot above will not appear. If it is missing, run the ConfigureSharePoint.exe utility on a SharePoint front-end web server to allow DPM to reconfigure the necessary options.
At this stage, you should be able to create a DPM Protection Group which contains the SharePoint servers take an initial replication of the content. Depending on the size of the sites, this can take a few minutes to hours to complete.
Since there are numerous distributed SharePoint implementations across many servers, we need to talk about which of these servers to protect. Here is a short list.
Web Front-end servers – Since all are the same, only one will need to have the ConfigureSharePoint.exe on it to register the WSS Writer.
Configuration Database Server – The data stored here is unique and not stored on other database servers so it is vital that you have a DPM Agent installed to protect it.
Content Database Servers - Content databases host all the information, content, and data of the farm. Each needs to be protected by a DPM Agent.
Before DPM can be used to recover any data to a protected Farm, the DPMRecoveryWebApplication must be created on the recovery farm’s server. As a requirement of the restoration process, it is helpful to understand the process necessary to create this SharePoint Web Application.
Below are the steps necessary to create the DPMRecoveryWebApplication.
This is the last entry to make before hitting OK to have the web application created. This will take a few moments but once complete, DPM will be able to recover SharePoint data. Upon completion of the DPMRecoveryWebApplication web application, the Application Created screen appears. At this point, schedule time to run ‘iisreset /noforce’ and once complete, DPM will be able to recover SharePoint data using this recovery farm.
Once these steps have been completed such as the installation of the DPM Agent on the various SharePoint servers, registering the WSS writer, creation of the DPMRecoveryWebApplication on the recovery server, and creation of a recovery site in the production farm, you are ready to protect your SharePoint data.
Next, we will take a look at the steps necessary to recover the entire SharePoint farm whether the production farm is available or not.