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:

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:

• With Single Item Recovery, if the user changes certain properties of an item in any mailbox folder, a copy of the item is saved into the Recoverable Items folder before the modification is written to the store.  Therefore, if the modification of the message results in a corrupted copy, the original item can be restored.
• The Calendar Repair Assistant detects and corrects inconsistencies that occur for single and recurring meeting items for mailboxes homed on that Mailbox server so that recipients won't miss meeting announcements or have unreliable meeting information.
• During mailbox moves, the Mailbox Replication Service detects corrupted items and will not move those items to the target mailbox database.
• Microsoft Exchange Server 2010 Service Pack 1 introduces the New-MailboxRepairRequest which can address corruptions with search folders, item counts, folder views, and parent/child folder issues.

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.