Implement CCR to improve Exchange Server 2007 mailbox reliability

Do you want to improve the reliability of Exchange 2007 mailbox servers without affecting performance during daily backups? By implementing cluster continuous replication (CCR), you can strengthen your Exchange Server 2007 backup strategy without sacrificing server performance.

Nearly every organization that uses Microsoft Exchange Server believes that it will be available all the time.

Although streaming backups allow Exchange to function without interruption, the process can negatively affect server performance because of all of the high I/O that occurs. What if there were a way to improve the reliability of your Exchange mailbox servers without negatively affecting server performance during daily backups?

One way to improve mailbox server reliability is through clustering. In the past, Exchange Server clustering got a bad rap because of a fatal flaw in traditional active/passive clustering. This type of clustering provided hardware redundancy, but both cluster nodes used the same copy of the store. This meant that you were protected against hardware failures, but the store was still potentially a single point of failure.

In Exchange Server 2007, you can get around these limitations by implementing cluster continuous replication. CCR works differently from traditional clustering in that it doesn't use shared storage. Instead, CCR uses log shipping and replay to ensure that the cluster's passive node always has a nearly current copy of the database.

Having a failover cluster improves the reliability of Exchange 2007 mailbox servers. However, clustering is no substitute for regular backups. While a failover cluster can protect your server against some types of data loss, it does not protect you against data loss related to database corruption.

The passive node contains a replica of the active node's databases. If a log file containing logical corruption damages the active node's database, the passive copy of the database will be damaged as well. However, Exchange does take measures to prevent the passive copy of the database from being damaged by a log file that is physically corrupt.

If you don't have normal backups, malware infections become a much bigger issue. Suppose, for example, that your store became infected with a virus and you wanted to return the server to its state before it became infected. Without a normal backup, you're very limited in your ability to revert the store to the previous state.

Related information on backing up Exchange Server 2007
Microsoft Exchange Server backup method pros and cons 

Five Microsoft Exchange Server backup worst practices

Understanding Exchange Server 2007 backup and disaster recovery 

Having a cluster with a secondary copy of an information store does not provide comprehensive protection against data loss, so you still need a traditional backup. However, you'll also have to deal with how the backup affects your mailbox server.

To avoid this problem, run the backup against the passive cluster node -- rather than backing up the active node. Using this approach, you can run the backup at any time because the process has almost no performance impact on the active node.

There are, however, some limitations to using this approach. You can't run a streaming backup against a passive CCR node. You can only run VSS backups, and your backup application must be designed specifically to back up passive CCR nodes.

Windows Server Backup cannot perform this type of backup, so you'll need a third-party backup application. Microsoft recommends performing a full backup of your information store at least once a week and performing incremental backups throughout the week.

CCR has some limitations. If you want to use CCR, your clustered servers can't have any roles other than the Mailbox Server role installed. Microsoft requires that CCR clusters have no more than two nodes.

Note: You can implement CCR using both Windows Server 2003 and Windows Server 2008. If you implement CCR on a Windows 2003, it's recommended that you use a Majority Node Set Quorum with file share witness. (This model is available in Windows Server 2003 SP2.) If the cluster is deployed on Windows 2008, you should use a Node and File Share Majority quorum.

About the author: Brien M. Posey, MCSE, is a five-time recipient of Microsoft's Most Valuable Professional (MVP) award for his work with Exchange Server, Windows Server, Internet Information Services (IIS), and File Systems and Storage. Brien has served as CIO for a nationwide chain of hospitals and was once responsible for the Department of Information Management at Fort Knox. As a freelance technical writer, Brien has written for Microsoft, TechTarget, CNET, ZDNet, MSD2D, Relevant Technologies and other technology companies. You can visit Brien's personal website at www.brienposey.com.

Do you have comments on this tip?  Let us know.

Please let others know how useful this tip was via the rating scale below. Do you know a helpful Exchange Server, Microsoft Outlook or SharePoint tip, timesaver or workaround? Email the editors to talk about writing for SearchExchange.com.

This was first published in March 2009

Dig deeper on Microsoft Exchange Server Backup and Disaster Recovery

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

SearchWindowsServer

SearchEnterpriseDesktop

SearchCloudComputing

SearchSQLServer

Close