Why Microsoft Data Protection Manager Will Replace Your SharePoint Tape Backups
* 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. *
Why Microsoft Data Protection Manager Will Replace Your SharePoint Tape Backups
Typically, within organizations it is common to have a backup strategy where your critical SharePoint data is backed up to tape, and either taken to secure on-site locations or to a designated off-site sheltered faculty. Tape backups have been a reliable way to backup SharePoint data for an extended period of time, however this type of disaster recovery, although typically reliable, tends to be slow for restoration of crucial business processes.
The Three Types of Backups Processes
There are three main types of backups that exist for SharePoint (there are obviously several others that can exist, however in the context of this particular article):
- Disk-to-Tape (DtT)
- Disk-to-Disk (DtD)
- Disk-to-Disk-to-Tape (DtDtT)
The latter of the three is the most advanced, and relevant to a DPM implementation protecting a SharePoint environment. Although legacy networks are most familiar with DtT backups, this method alone is not advantageous to a SharePoint environment which needs a more agile disaster recovery framework so the business processes and the environment that information workers are used to can be ensured.
The second of the three, Disk-to-Disk backups, are much different that Disk-to-Tape backups for one overlying reason. Instead of populating backup material to a tape directly, it is copied to another server within your network, typically a network/file share. Similarly, within a Disk-to-Disk-to-Tape strategy, your SharePoint data is backed up into a network shared, and then pulled off that share onto a tape for offsite storage, while maintained on the file share for agile backups.
Why Combine Tapes with a Disk-To-Disk Strategy
Why are these two methods being combined anyways? It seems that in the long run, with a Disk-to-Disk-to-Tape strategy, there is a mixture of steps that could otherwise be handled with a simple Disk-to-Tape backup strategy. While this is true, one of the benefits of implementing Microsoft Data Protection Manager is that it allows automation of these steps in order to protect your SharePoint environment.
Picture first your SharePoint environment. Assume that you are involved with a medium sized company, around 5,000 employees each of which is heavily dependent on your SharePoint implementation for line of business applications and facilitating communications and collaborations within virtual teams in your organization. Your arbitrary SharePoint implementation is a medium server farm consisting of two front-end web servers, a separate server that facilitates indexing and job functions, and a backend SQL server. Within your SharePoint implementation are several file shares exposed as well which house certain content which don’t necessitate the need of revision controls which are provided by SharePoint such as .iso and .exe installation files (maintained in the blocked files list to protect the portal from malware). Within your SharePoint environment you also have 1 server dedicated to DPM processes that help to facilitate disaster recovery within your environment providing full fidelity backups for your 250 SharePoint site collections.
These site collections are critical for your business operations for multiple reasons, including however not limited to document repositories, revision controls, task management, and integration with a Team Foundation Server implementation providing your developers and program managers insight into your Software Development Lifecycle (SDLC) and work item tracking.
In the legacy backup strategy, your environment database files are placed on tape and moved off-site every morning at 2:00 a.m. in order to harvest the most recent data and not interfere with user activity.
Your CEO just uploaded a critical document to a document library whose subject is the quarterly fiscal budget, also including a PowerPoint presentation that is going to be shown to shareholders. Without these vital metrics, there will be less interest in the company and it is feasible that some of the shareholders may pull their funding and throw the company into a financial disarray.
And Then, a Catastrophe Occurs
Disaster strikes. Another user accidentally uploaded a document infected with a piece of malware that essentially turned your SharePoint server into a large paper weight, corrupting several pieces of functional SharePoint data and brining down your farm. Your CEO is in a state of panic because of the implications of not having the presentation and document available, and he is holding you responsible.
You tell him not to worry because as the SharePoint administrator you have rights to gain access to the tape backups. However, the CEO loaded the document at 9:00 a.m. this morning working on it feverishly all evening, making it not feasible for you to actually reload the document, so his work has been lost and now there is a possibility of shareholders not observing relevant metrics, and losing interest in the organization.
With DPM, this situation could be avoided. Using DPM, you can make a full backup of your SharePoint data (after export) and file stores so that if any relevant data is lost at anytime during the day, it can be restored, even in hourly increments. Once that data has been modified in coordination with the synchronization schedule, it will be pushed block by block into your backup files, ensuring that business critical data can immediately be pushed back into your environment.
This means that the CEO will be able to bring up the corporate portal during his meeting with shareholders, and even though his file was uploaded to the document library at 9:00 it can still be restored in enough time that he will have all of his relevant assets he needs to ensure his shareholders that they are making the right investment. Even better, since the CEO should have access to the relevant backups, he can even invoke the DPM UI and restore the backup himself. Other users can take advantage of this feature as well, depending on permissions that you set up. If the CEO didn’t have access, assuming he is not incredibly tech savvy and therefore his access is restricted to certain resources, you will most likely be responsible for restoring his relevant system status. This is easily done through the DPM UI, which is easy to facilitate through a Windows Explorer type snap-in, for both you as the administrator of the SharePoint environment as well as your users.
The Shrinking Window of Data Backups
Eliminating this 2:00 a.m. restoration process is eradicating the shrinking window of database backup. More and more data is needed to be backed up relating to your SharePoint environment, and there is less and less time during a 24 hour window for you to create these backups. The shrinking window isn’t large concern when you have an implementation of DPM since the data is constantly backed up for you to restore whenever problems may occur with your portal, which is quite useful for proper disaster recovery.
As described before, as the SharePoint administrator responsible or your network, you are responsible for proper disk allocations and how your backups are stored. Having space for multiple versions of large SharePoint environments might seem to be not advantageous for an environment based on disk-to-disk data storage, it would take up a fair amount of space if you have multiple SharePoint site collections with large content repositories!
Adaptive Copies Within Microsoft Data Protection Manager
DPM handles this type of allocation quite nicely by using adaptive copies, only moving the changes so that you can save disk space for an environment that can have incredibly large backups already pegged with network bandwidth allocations issues since users are typically relying heavily on SharePoint for virtual team environments. Even more relevant to SharePoint is that while users are currently hitting your portal environment backups can still be made of the file stores, which is crucial for a communications and collaborations platform which is typically under constant use.
Unhealthy Storage Limits Within A Disaster Recovery System
DPM will also warn you if you are exceeding an unhealthy storage limit, which by DPM standards is if you hit a threshold of 75%. This is an atypical situation, and should realistically cause two courses of actions.
1. What are my physical storage options, do I have proper disk allocation?
2. Would my DPM configurations be causing this issue?
DPM has several inherit calculations built into it that will help you as the SharePoint administrator. Using a disk-to-disk-to-tape backup solution further should emphasize why you should not be getting these types of messages, since your legacy data should eventually work its way off the disk-to-disk portion of the backup solution and should eventually move to a tape for off-site storage.
Errors Due To Lack of Space
Within a SharePoint environment, since the data is constantly changing, the cause of these types of errors is because within a platform that promotes virtual teams that data is changing constantly, and DPM upon initialization will make intelligent configuration options as to how fast your backup data will change. If the data changes over this threshold, the shadow copies of the data will grow to quickly and will cause DPM to become confused.
Solving this issue quickly is easy, by adding more space. The two options for adding more space are:
1. Add more disks
2. Increase the storage allocation of the DPM server