In part 2, I looked at how DPM protects SharePoint data. Part 3 focuses on how DPM recovers SharePoint data. I will focus on the prerequisites, components used and data flow that occurs when recovering data at various levels in a SharePoint farm.
Restoration of objects in SharePoint by using DPM can be broken into a few key recovery scenarios:
· The entire farm
· Content databases
· An SSP, its associated enterprise search data, and Windows SharePoint Services Search
· Sites, Lists and Items (everything below the content database level)
· Customisations and configuration settings outside of SharePoint databases
Restoration of data from each of these categories can involve a different process, supportability implications and prerequisites. For example, restoration of the farm configuration database and associated Central Administration content database is only supported as part of a FULL farm recovery. In this scenario all content databases must be restored to the exact same point in time also. With that in mind it is easier to discuss each of the recovery scenarios and how they work separately...
The entire farm
As already discussed above, recovery of an ENTIRE SharePoint farm is possible when using DPM. This includes the configuration and Central Administration databases. However, it is important to consider that this recovery option requires these databases, and all other databases in the farm are recovered together to the same point in time.
This is made possible because DPM uses VSS which allows for a point in time snapshot of all databases in a SharePoint farm. For this exact reason, restoration of the configuration and Central Administration databases is supported when recovering an entire farm.
Note: It is possible to select these databases for restore individually, but this is not a supported operation.
To recover an entire farm (except the search components which are covered separately), you simply select the ‘All Protected SharePoint Data’ option, followed by hitting recover on the configuration database as shown below.
This may not seem obvious at first but it is the correct way to restore an entire farm. By selecting the item shown above, you are really selecting the entire farm (its name is of course given by the name of the configuration database). At this point you can follow the wizard to recover the farm and all its content.
You do need to consider the 2 possible scenarios for farm recovery: the production farm is still live and the WFE used to protect it is available; the production farm is unavailable due to complete configuration database loss or corruption. Rather than repeat documentation already out there I will point you to the TechNet article that covers farm recovery in each of these scenarios: http://technet.microsoft.com/en-us/library/cc262562.aspx.
During the recovery process, DPM will recover all databases to the SQL Server instance(s) used by the farm. The DPM Agent and SQL VSS Writer are used for this process.
Content databases
Restoration of SharePoint content databases is very simple. Although backed up as part of the farm, the content databases are treated like any other SQL Server database and can be selected for restore individually. You have a few operations for restore: recover to original location; recover to alternate SQL Server instance; or copy to a network folder.
The wizard is fairly intuitive, so I won’t explain each step any further. I would however like to point out that the copy to network folder option is great and can be used to properly verify your backups and keep that all important test farm data up to date. Of course the option is less valuable when performed manually in the UI, but how about you use a PowerShell script to do this for you?! Now you can test the restore of your SharePoint content databases routinely...
$DPMServer = "DPM server name"
$pgName = "SharePoint protection group Name"
$dsName = "The DataSource name in the format WFE\config database name"
$db = "Name of database to be recovered"
$targetServer = "Target server name"
$targetPath = "C:\restore"
$pg = Get-ProtectionGroup $DPMServer | where { $_.FriendlyName -eq $pgName }
$ds = Get-Datasource $pg | where { $_.Name -eq $dsName }
$rp = Get-RecoveryPoint -Datasource $ds | where { $_.DataLocation -eq "Disk" }
$lastitem = $rp.count-1
$ri = Get-RecoverableItem -RecoverableItem $rp[$lastitem] -BrowseType child | where { $_.UserFriendlyName -eq $db }
$rop = New-RecoveryOption -TargetServer $targetServer -TargetLocation $targetPath -RecoveryLocation CopyToFolder -RecoveryType Restore -SharePoint
Recover-RecoverableItem -RecoverableItem $ri -RecoveryOption $rop
Warning: This script does not contain error handling and is based on my rather primitive PowerShell skillz J. That said you should be able to take it away and add to it. Once you have the database restored to a file share you can just run a routine SQL job or of course script out the restore to your test farm.
Note: Be sure to detach and reattach the database in SharePoint once it is restored so to update the sitemap table in the farm configuration database.
An SSP, its associated search data, and Windows SharePoint Services Search
Full support for backup and recovery of Shared Services Providers and SharePoint Search data was added in DPM 2007 SP1. Due to the intricacies and caveats of protecting and restoring this data, I have dedicated an entire post to it which is coming soon.
Sites, Lists and Items
Recovery at this level can be classed as item level recovery. In essence this is anything in the SharePoint object hierarchy that is stored within a SharePoint content database. Restoration of these items is only possible (in a supported manner) via the SharePoint Object Model. Whilst it is technically possible to extract these objects from content database and insert them into another, this may lead to corruption of the databases and related data and is therefore not supported.
The DPM product team worked with the SharePoint product team to ensure this recovery scenario could be implemented in DPM in a way fully supported by SharePoint. As such, DPM uses the SharePoint Object Model when performing item level restores.
For this to work, a ‘recovery’ farm is required and is used to temporarily host a recovered version of the content database that holds the SharePoint object you wish to recover. The object is then exported using the SharePoint Object Model and imported back into the production farm.
The following diagram explains the process in more detail:
Full details of how to create a recovery farm are available from here: http://technet.microsoft.com/en-us/library/dd180789.aspx. It is recommended that you take advantage of virtualisation technology for the recovery farm and possibly even use Hyper-V to host the recovery farm directly on the DPM server.
Be sure to read the short TechNet article referenced above as it contains a list of key points to consider, such as how to name the recovery Web application and the following requirements amongst others:
· If you protect a MOSS farm, then the recovery farm must also be MOSS.
· The features and templates installed on the recovery farm must match those of the target farm as it was at the time of backup. Any customized templates, added or modified, on the production farm, must be added to the recovery farm to ensure a successful recovery.
· The target farm must contain a site collection with the same path as the original protected site. If the site collection does not exist, you can create an empty site collection with the correct path on the target farm before you perform the recovery.
Those familiar with the stsadm export and import commands (which use the same APIs) will know that these requirements are down to caveats and limitations of the SharePoint Content Migration APIs and not DPM. They are not hard to work around but are the cause of most item level recovery failures and issues.
A full overview of the Content Migration APIs and what cannot be exported/imported is documented here: http://msdn.microsoft.com/en-us/library/ms453426.aspx.
OK, so now you know how item level recovery works let’s take a look at it in action. You can use the DPM UI to search or drill down through a content database down to the item level. As you can see below it’s as simple as navigating the SharePoint object hierarchy and selecting the item you wish to recover, be it a site collection or single document.
You are able to navigate the SharePoint object hierarchy like this because DPM catalogues your farm when it creates a recovery point (see post 2), storing it locally for search and navigation during a restore.
When the wizard fires up, you get a couple of recovery choices; recover to original site or recover to an alternate site. Either way you need the recovery farm in place first. Again I won’t speak you through the whole wizard; you can refer to TechNet for that: http://technet.microsoft.com/en-us/library/bb795893.aspx (Item recovery) and http://technet.microsoft.com/en-us/library/bb795899.aspx (Site recovery).
I will however cover some of the most common mistakes which include some of those already discussed above:
· Not enough space on the recovery farm temporary storage volume. This is for the initial database restore process of item level recovery.
· A site already exists at the recovery location but uses a different template to that being restored. For example, SharePoint will not allow a site created by using a Wiki Site template to be restored onto a site created by using the Team Site template.
· A sub-site, list or item is being restored to a location without a parent Site collection. You must have a parent object in place to restore any child objects.
· The recovery farm is a different version or build of SharePoint. The build must be the same since MOSS 2007 Enterprise contains features that are not available in Standard and WSS 3.0. The farm must also be patched to the same build and have the same language packs installed.
· The recovery farm does not contain all customisations that are deployed to the production farm. If an object being recovered depends on these the recovery may fail.
And finally a few points worth mentioning about the site/list/item recovery process and the use of a recovery farm:
· The last section of the wizard will NOT show the details of the object being restored. This is by design for SharePoint restoration.
· The files created in the temporary locations on the recovery and production farms are removed with the exception of the CMP files on the recovery farm. You will have to remove these yourself. Personally I think it is good that these are left behind as you can reuse them again. The other files are removed on a best effort basis so some manual tidy up may be required if the files are still locked when an attempt is made by DPM to remove them.
· A common question asked is about licensing of the recovery farm. This is naturally a complicated topic and I’m certainly not in a place to give an authoritative answer. For that you should speak to your local licensing expert. However, I can comment on what I currently know about the topic. In summary you do need licences for all software on the recovery farm. However it may be that you qualify for ‘Cold Server Backup for Disaster Recovery’. I’m told SharePoint recovery farms used by DPM qualify under this category. Jason Buffington has a great webcast on the topic of DPM Agent licensing if you want more information specific to DPM agents. Also check out the TechNet page here: http://technet.microsoft.com/en-us/library/bb808748.aspx.
· With so many pieces to the puzzle there is a lot to go wrong. Look out for part 4 which will cover troubleshooting issues with the backup and recovery process.
Customisations and configuration settings outside of SharePoint databases
Almost all content related to SharePoint is stored in SQL Server databases. However, some customisations and configuration settings are stored on the file system of the Web front end servers in a farm. Whilst DPM does not protect these automatically, it is possible to protect and restore these customisations and configuration settings by using the file system and system state options within DPM.
You should use DPM to protect any customisations not deployed through the use of SharePoint solutions, and any configuration changes including those to web.config files and IIS configuration files. There is no need to protect folders with customisations deployed through solution packages as these will automatically be redeployed by SharePoint in the event of Web front end failure.