Microsoft Exchange Server 2010 features a new platform for high availability and site resilience that makes deploying redundant and highly available mailbox databases easier than before. But even the most extreme forms of redundancy and fault tolerance can't protect against every possible failure or disaster. Ensuring there's sufficient protection for the critical data in the Exchange organization is a necessary operational task for all organizations.
As part of data protection planning, it's important to understand the ways in which data can be protected, and to determine of those ways, which best suits the organization's needs.
Exchange 2010 provides native data protection that eliminates the need to make traditional backups of your data. The following table helps to decide whether you need to continue utilizing a traditional backup model or whether you can implement the native data protection features built within Exchange 2010:
Mailbox Resiliency (multiple database copies)
Accidental or malicious deletion of item
Single Item Recovery and deleted item retention with a window that meets or exceeds the item recovery SLA
Physical corruption scenarios
Single Page Restore (HA database copies)
Logical corruption scenarios
Single Item Recovery
Calendar Repair Assistant
Point-In-Time Backup (PIT) backup
Corporate/Regulatory Compliance requirements
Logical corruption is typically a scenario that requires a PIT backup. However, with Exchange 2010, there are several options now available that can mitigate the need for PIT backup:
Note that several of the mitigations mention PIT backup. A PIT backup can be either a traditional backup, or a lagged database copy. Both provide the same capabilities; however, the choice between the two will depend on your recovery SLA. The Recovery SLA will define the Recovery Point Objective (in the event of a disaster the data must be restored within a certain timeframe of the disaster), as well as, how long the backups must be retained. If the recovery SLA is 14 days or less, then a lagged database copy can be utilized; if the recovery SLA is greater than 14 days, then a traditional backup must be used. For the rogue administrator and corporate/regulatory compliance scenarios, the PIT backup typically is Isolated and maintained separately from the messaging infrastructure and messaging IT staff, which dictates a traditional backup solution.
Thanks to Ross for assisting me on this document.
A very nicely written and useful article.