Protecting Your SharePoint Environment with Microsoft Data Protection Manager
* This article was written in the context of System Center Data Protection Manager 2006 (SCDPM), a technology now considered deprecated with the introduction of System Center Data Protection Manager 2007. Variations may exist. *
Protecting Your SharePoint Network with Microsoft Data Protection Manager
After you conclude your initial configuration of Microsoft Data Protection Manager, protecting your SharePoint servers should be the next task to complete so that you can ensure that your critical business data is protected in accordance with a properly structured SharePoint disaster recovery policy.
The initial deployment of DPM necessitates several actions, however most importantly deploying DPM agents to your SharePoint content database repositories so that critical SQL data can be protected in the event of a disaster. This disaster can be anything, from an intruder engaging in corporate espionage to weather damaging a data center. Setting up protection of this business critical data should be a large priority within your organization.
Setting Up Data Protection Manager Protection Groups
The first step in protecting your SharePoint environment is to setting up protection groups that all hold common characteristics. A protection group is just your SharePoint servers that you want to protect, grouped into a logical collection, each of which have a DPM agent deployed onto it, under a common protection umbrella, or protection goal. For each volume that should be protected within the SharePoint environment, a protection group should be designed and implemented, applying to all units under this protection group with the same protection policy.
Within a SharePoint environment, the protection policy can be tailored very differently depending on your organization. It is important to set thresholds for each protection group on data that if lost will not impact business processes, and data that if lost will severely influence how your organization runs its business.
Three Main Assets of SharePoint Typically Protected
There are three main assets relating to SharePoint that are advantageous to protect leveraging DPM, depending on your environment:
SharePoint File System â€“ If you have custom development implementations, such as SharePoint WebParts, custom applications, or tailored third party products that were development heavy to customize to your environment, these files should be protected. Typically, protecting the default file stores of SharePoint is good practice since it streamlines restoration after a disaster. If you have custom features or solutions in MOSS, these should be protected.
SQL Database files The most important portion of the SharePoint environment is the backend SQL data that builds an arbitrary amount of content repositories. These database files should be firstly exported which can then be protected by Microsoft Data Protection Manager.
Server System State For a full fidelity backup, it is often advantageous to implement a scheduled backup using the inherit System Backups (the Windows backup utility) to make a copy of the system state, after which that file can be protected by Microsoft Data Protection Manager.
If you have custom development implementations, such as SharePoint WebParts, custom applications, or tailored third party products that were development heavy to customize to your environment, these files should be protected. Typically, protecting the default file stores of SharePoint is good practice since it streamlines restoration after a disaster. If you have custom features or solutions in MOSS, these should be protected.
User Tolerance for Loss
For some, and for the sake of providing a detailed example, protecting the SharePoint file stores is a portion which may not require much protection, since these can be restored from SharePoint media (Assuming there aren’t heavy modifications. If you have custom site definitions, or features and solutions in MOSS, these should clearly be protected). Therefore, it has a high tolerance for user loss. The SQL data however which builds the structure of the SharePoint site and is responsible for the housing of business data has a low tolerance for user loss, and should therefore be given a high priority with Microsoft Data Protection Manager.
There are more factors to consider with your SharePoint protection groups. Within protection groups, there are parallel scheduling mechanisms (consistency check schedules and common protection schedules).
Building on the example above, and assuming we don’t have enhancements such as custom site definitions (SPS 2003) or features and solutions (MOSS 2007). Again, this is meant as an example to show DPM architecture of protection groups and isn’t a best practice since it would vary heavily from company to company.
SharePoint Data and Server Protection GroupThis protection groups related to your protecting your SQL data after being exported and your System backup in case of a major server disaster.
SharePoint File Protection GroupTypically the SharePoint file stores are protected.
Creating SharePoint Protection Groups With Data Protection Manager
There are 6 major steps that have to be performed when creating our SharePoint protection groups:
Naming Your Protection Group
Selecting Group Members
Reviewing Disk Allocations
Choosing Replica Creation Method
Selecting a Protection Schedule
- Initializing the Protection Group
To create your SharePoint Protection groups, open up the DPM console dialog and open the Protection tab. Following, a DPM wizard dialog will invoke, where you will be required to enter the name of your protection group, typically you can use the above groups. Firstly, enter the SharePoint Data and Server Protection Group since it has a low tolerance for data loss. If you have other protection groups currently leveraging DPM ensure that there are no naming convention collisions and that you can easily remember that naming convention.
On the next Create New Protection Group dialog you will select the group members that are going to be accommodated by your protection group. These can either be shares or volumes and folders. You must select one or the other, you can not combine the two, you must choose one or the other. You can create a new protection group if you need to do both, however you will throw exceptions if you attempt to do both within the same group.
The next dialog that you will invoke is the Review Disk Allocations screen which will show you the implications of the selections you previously chose to protect. DPM will automatically make selections as to how to allocate your disk size, based on several backend calculations. The application is flexible enough that if you desire to change these settings, you can do so, however the DPM calculations are typically the most optimal.
Once you have either decided to use the default selections as calculated by DPM or made your own decisions for disk space allocation, the next step is to set the replication settings for your SharePoint protection groups. Replication cycles and options are fairly flexible and can be tailored to your enterprise needs, allowing you to set scheduled times and protected data transport mechanisms, typically these are structured schedules and it is most times advantageous to rely on the automated moving of protected files. It is possible to move the files manually; however, this is typically not beneficial since one of the benefits of using DPM is the automated processes it provides.
Last Decisions for Your SharePoint Protection Groups
The last configuration step for SharePoint protection groups is to create the protection schedule. This will require you to make two decisions:
What synchronization schedule do I want?
What shadow copy schedule do I want?
There are two different options to configure because the synchronization schedule is an adaptive process that does comparisons of the data to find what has changed within your SharePoint environment and what hasn’t. If only small portions of your SharePoint environment has changed, DPM will only move the portions of data that have changed will allowing the legacy data to remain the same, conserving precious system resources while still allowing you a full fidelity backup procedure.
Similar to check sums, there will also be a check as to whether the data is still dependable, by using consisting checks. This is done by comparing blocks of data between the protected files and those that have been recently backed up so that you can ensure that your data is consistent between your protected resources and the backups that you might have to potentially use at a later date when a disaster occurs that impacts your SharePoint environment.
This consistency check is usually non-deterministic if it is not blatantly scheduled within the advanced options while creating your protection groups.
Not similar to your synchronization scheduling are shadow copies. Shadow copies are similar to the versioning mechanisms that exist within in SharePoint, whenever there are changed to a file a version of that file is saved so it can be reverted to if need be. For each schedule shadow copy, there will be a sister file saved that is similar.
One the last screen you will get a summary of your protection group, once you instantiate it, it will take effect with all implications including scheduling, backups, and all other assets as you have configured it throughout the protection groups wizard steps.