Why should you backup an Exchange 2010 DAG implementation with DPM?
What should you be thinking about before you make a final decision?
What is the way out of this conundrum?
….Well, it depends. Let me walk you through a scenario.
First, let us make a couple of seminal assumptions:
· That you will you will have more than one copy of an Exchange DB in a DAG. OK, you are allowed a duh!
· That you will be deploying Exchange 2010 DAG with cheap JBODs, which will undoubtedly save you a bundle.
· If you are going to use JBOD, then you really understand how to interpret MTBF and its relationship to uptime SLA.
All Exchange Mailbox Servers in one site (HA but no DR)
If you want to deploy Exchange 2010 with JBOD, it is recommended that you should deploy with at least three copies. In addition to this, if you want to also use the DAG copies for Point In Time (PIT) recovery, then you will need a server to host the lagged copy of the DB. Lagged copies are a means to safeguard against store/logical corruption events (and possibly accidental mailbox deletions). If you are going to distribute the lagged copies among your primary severs, then you will need at least two lagged copies. If you are going to use dedicated servers with lagged copies with JBOD, for better reliability you are well advised to deploy enough servers to house two lagged copies; otherwise you could deploy dedicated lagged copy servers with RAID and thus only have one lagged copy per database.
So how many copies are we up to? …and how many servers?
OK, three copies per DB; two more for PIT lagged copies; one less if you share and distribute the lagged copy on more than one primary server or if you use RAID for PIT. That is, 1, 2, 3, wait. All right, you are big boys/girls (smart Admin people), you know how to fire up Microsoft Excel to do the math and cost it out.
From all accounts, recovering PIT from lagged copies is not a walk in the park. In fact, you are well advised not to plan for it too frequently. Plus, you can only have a maximum of 14 day replay lag for lagged copies. This is a limit imposed by Exchange 2010. If you also decide to share the primary servers and implement lagged copies, then you will be using the primary mailbox server for your recoveries – so plan your IOPS so that you do not impact Outlook client SLAs during these recoveries and re-seeds and manage your Active and Passive nodes carefully.
Introduce DPM into this equation:
Let us say you implement only three copies of an Exchange DB with JBOD, and use DPM for backup and PIT recovery. Now what? You have:
· As many PIT as you like J
· Recovering a PIT from DPM is far easier J
· You may not need that 4th DAG copy J
Wait, it is not all smiles; most of the time we recommend RAID for DPM. DPM is typically configured with RAID but is just as happy with JBOD, particularly if you do D2T, DPM2DPM or protect a secondary copy as well DPM-DR. Make sure that these choices are part of the spreadsheet you are working on. And, some of the following features may require you to move up to a higher version of Exchange 2010.
· Deleted items in Exchange 2010 no longer require PIT recovery; this can be implemented with the single item recovery and litigation hold functionality.
· The lagged copy or a DPM backup is useful for logical corruption prevention and for recovery of deleted mailboxes (since their purge cannot be prevented)
Additional reasons why you should consider DPM
In addition to direct storage costs attributable to backup, you should also consider these additional advantages. Some of these may very well be primary reasons for opting for DPM. You may also be able to use one less DAG node, and, in the process get some additional features
· Ease of use for recovery from backup with a simple and easy to use GUI.
o No time consuming steps to find and replay log files
o No need to (possibly) create scripts for recovering from a lagged copy.
o No need to guess how many log files you need to replay for a PIT.
o No need to play back all the log files, etc.
· You can easily backup to tape, for offsite storage for compliance, etc.
· Centralized standard (corporate) processes to implement backup and recovery across multiple workloads (File systems, SharePoint, Hyper-V, SQL, etc.)
So there you have it. Two solutions from Microsoft, working together to give you an optimal solution for your IT problems.
Krishna Mangipudi (Author)
Check back for more on how DPM 2010 will improve Exchange 2010 DR. That is a story for another day.
Some useful links
DPM 2010 Overview: For an overview of how DPM 2010 and Exchange 2010 work together, including a quick demo – check out our recent podcast at:
Exchange 2010: Planning for High Availability and Site Resilience