Why DPM 2010 and SharePoint are Better Together?
Non-Microsoft backup solutions tend to take generic backup functionality and adapt it to support-specific applications. In contrast, Microsoft created DPM 2010 to leverage fully supported Microsoft technologies in order to provide continuous data protection specifically for Windows Server hosts running SharePoint 2003, 2007 and 2010 products and technologies.
This support includes:
- Online backup of SharePoint content databases and configuration.
- Recovery of SharePoint sites, document libraries, lists and documents to either the original server location or an alternate SharePoint farm.
- Recovery of SharePoint content stored on SharePoint 2010 farms without requiring the use of a recovery farm.
Better protection for SharePoint with DPM
DPM 2010 is engineered to provide the best possible protection for SharePoint products and technologies. In fact, the team that built DPM 2010 worked in consultation with the team that built SharePoint to ensure that SharePoint workloads are reliably protected.
DPM 2010 seamlessly interacts with the SharePoint and SQL Server Volume Shadow Copy Services (VSS) writers so that DPM captures consistent versions of a SharePoint deployment without interrupting client access to SharePoint content.
VSS, DPM, and SharePoint interact in the following ways:
- DPM provides granular protection by combining VSS snapshot functionality with DPM block-level synchronization. The DPM block-based replication engine makes an initial copy of all data tiers of a protected SharePoint server farm, ensuring that the captured copy of the SharePoint data is a complete and consistent initial replica. DPM’s network transport functionality then ensures that this replica is transferred and recreated, and that the copy is made and verified.
- DPM 2010 captures backups using the SharePoint (and SQL) VSS writer. The writer provides a data-consistent set of disk-blocks that are synchronized with the DPM server. This approach provides the benefit of a “full backup” with the DPM server while minimizing the amount of backup data that needs to be transferred across the network.
- After the initial baseline copy of the protected SharePoint content databases are created, they are transferred to the DPM server at regular intervals.
- DPM’s “express full” backup technology uses the SharePoint and SQL Server VSS writers to determine which blocks have changed in protected files and on SQL databases throughout the farm. Those blocks, and only those blocks, are replicated to the DPM server, where they are applied to an active replica of the data, with previous iterations stored as a set of differences within the preceding backup.
The DPM server uses VSS on the volumes that host recovery data so that multiple shadow copies are available. Each of these shadow copies provides a separate recovery point - DPM can maintain up to 448 separate recovery points. VSS recovery points are stored on the DPM server. The temporary copy taken on the host is only stored for the duration of the DPM synchronization.
DPM 2010 can protect highly available SharePoint configurations. For example, DPM 2010 can protect SharePoint farm content that exists in both Config and all content databases, even if the topology changes and servers are added or removed. DPM 2010 can also protect farms hosted on backend SQL Server failover clusters, as well as mirrored SQL Server configurations.
Practices when Backup SharePoint using DPM 2010
Creating a SharePoint Recovery Farm
As discussed earlier, in some cases it is necessary to use a SharePoint recovery farm to recover certain types of SharePoint items, such as those from earlier versions of SharePoint or versions of SharePoint 2010 that have different service packs applied. A SharePoint recovery farm must have the following properties:
- Identical updates and software versions.
- Both the recovery and production farms must be in the same language and have the same language packs installed.
- The recovery farm must contain the features, templates, and all other customizations that are installed on the target farm.
- The target farm must contain a site collection that has the same path as the original protected site. If the site collection does not exist, you can create an empty site collection that has the correct path on the target farm before you perform the recovery. You can learn more about creating recovery farms through the following TechNet document: https://technet.microsoft.com/en-us/library/dd180789.aspx
- The SQL Writer Service must be running on the recovery farm.
- A DPM agent must be installed on the recovery farm.
Storage Calculator
The storage calculator allows you to estimate how much storage you must allocate in DPM 2010 to protect specific resources. DPM 2010 SharePoint storage calculator is provided to help you plan the protection of your SharePoint 2010 deployment. The storage calculator also provides guidance on three aspects of a DPM 2010 protection strategy:
- Estimates how much storage is required to protect a specific SharePoint 2010 deployment.
- Outlines the type and class of server, memory requirement, storage requirement and guidance for critical system parameters such as the page file size that are required to create a DPM server.
- Estimates backup window SLAs by providing the time needed for both Initial Replication and Incremental Synchronization.
Additional tools are available to help you estimate some of the input parameters for your specific implementation such as the amount of change in data from day to day (called “data churn.”) Data churn plays a crucial role in estimating the requirement to protect your SharePoint installation. Another factor that influences the amount of storage you will need is the Retention Range, or the number of days you expect to keep a replica. The Backup Frequency determines how many replica points you will have.
The storage calculator can be used in the initial phase of your SharePoint 2010 protection strategy to not only estimate the amount of storage you will require but to model your backup policies. You can conduct a what-if analysis to see the impact on backup SLAs by changing the storage IOPS and also by varying the network bandwidth available for backup and recovery. You can vary the storage consumption parameters - churn and the Retention Range - to see the effect on the storage requirement over time.
Using the storage calculator to estimate your deployment requirements can result in a deployment configuration that is robust and can function optimally over a period of time. You can access more detailed documentation related to the DPM 2010 Storage Calculator, as well as the Storage Calculator spreadsheet for SharePoint, at the following address: https://www.microsoft.com/downloads/details.aspx?FamilyID=c136c66c-bd4a-4fb1-8088-f610cd02dc51&displaylang=en