This article can also be found in the Premium Editorial Download "Exchange Insider: Using VMware vSphere High Availability and distributed resource scheduler."
Download it now to read this article plus other related content.
With Exchange Server 2010, Microsoft Corp. made some major changes to the database structure that underlies the email application. These architectural changes have a significant impact on planning for Exchange Server's data storage requirements. Learn about the best Microsoft Exchange 2010 backup strategies in this tip and how Database Availability Groups can impact the way you do backups.
Exchange administrators have taken a number of different steps to prevent substantial data loss. In Exchange 2007, for example, it was a common practice to use continuous replication to replicate mailbox data to another mailbox server. A continuous replication solution provides fault tolerance and acts as a mechanism for protecting data between backups. (Of course, using a continuous data protection solution such as System Center Data Protection Manager is also a good option.)
Some observers feel Microsoft is working toward making Exchange Server backups completely unnecessary. The idea is that Database Availability Groups will eventually make Exchange resilient enough that you won't need backups.
Database Availability Groups are an Exchange 2010 feature that lets you create up to 16 replicas of a mailbox database. These replicas reside on other mailbox servers, and it's even possible to create database replicas in alternate data centers. Despite the degree to which Database Availability Groups can protect mailbox data, you shouldn't abandon your backups just yet.
Having multiple replicas of each database makes it easier to protect Exchange Server, but if a mailbox database becomes corrupted or gets infected with a virus, the corruption or viral code is copied to the replica databases.
But Microsoft does offer a delayed playback feature in which lagged copy servers are used to prevent transactions from being instantly committed to replica databases. If a problem occurs, you'll have enough time to prevent the bad data from being committed to a replica database. Once you've stopped the bad data from spreading, you can revert all your mailbox databases to match the state of the uncorrupted replica.
While this approach sounds great in theory, Microsoft still has a lot of work to do to make it practical. Right now the procedure requires you to take an educated guess as to which transaction log contains the first bit of corruption and then work through a complicated manual procedure to prune the log files. So while Exchange 2010's storage architecture makes it easier to protect your data by way of Database Availability Groups, you shouldn't rely on them as the only mechanism for protecting Exchange data.
About this author: Brien M. Posey is a seven-time Microsoft MVP for his work with Exchange Server, Windows Server, Internet Information Server (IIS) and File Systems/Storage. He has served as CIO for a nationwide chain of hospitals and was once a network administrator for the Department of Defense at Fort Knox.
This article was previously published in Storage magazine.
This was first published in August 2011