Continuous data protection (CDP) systems have gotten a lot of attention in the Exchange Server world over the last year or two. After the devastation caused by Hurricanes Rita and Katrina, many organizations that had previously been satisfied with their disaster recovery arrangements started to look for better protection. Conventional backup systems are like the spare tire on your car: When your tire goes flat, you need a properly inflated, usable spare and the related tools on hand, but changing a tire is still a hassle—especially if you have to do it in bad weather, alongside a busy road, or under other less-than-ideal conditions. It would be much nicer to have a dashboard button that, when pushed, would automatically fix your tire for you. That’s the basic notion behind CDP: making disaster recovery easier with less data loss by increasing the frequency at which data items such as Exchange databases are backed up.
CDP for Exchange 2007
Exchange Server 2007 marks a radical departure from Exchange 2003 in many ways. One of the most important changes is that it includes native support for two different CDP methods: local continuous replication (LCR) and cluster continuous replication (CCR). LCR copies storage groups to different disks on the same server. This type of replication helps protect against problems with the original storage group’s physical storage, and it protects against some types of on-disk corruption, such as failed or corrupted writes. LCR replicas provide fast restores (provided you’ve fixed the problem that caused the original failure), which is great if you have a short RTO, and they might allow you to take fewer full backups to secondary storage such as tape. You can create backups from the LCR replica instead of from the production database, which can be a significant time-saver. However, LCR failover requires manual action.
CCR is designed to provide full replication of data between nodes in a cluster. The way CCR works is ingenious: You set up a two-node Exchange cluster that uses a special network share called a file share witness to keep track of the cluster state. The witness can be on any server accessible across the network, although Microsoft recommends using a server in the same AD site as the cluster. The two cluster nodes don’t have to share any storage. All previous versions of Exchange require the use of shared storage in clusters. To copy data from one node to the other, the CCR feature uses the same basic log-copying mechanism as LCR.
Both of these technologies work with a single database per storage group. Therefore, they’re best suited for protecting high-value data instead of entire servers. In using LCR and CCR, you’re also limited in the ways you can protect public folder databases; this isn’t a big problem because public folders already include their own replication mechanism. CCR requires that you use the same location and paths for the storage groups and databases on both nodes, just as conventional clustering does.
Both LCR and CCR benefit from a little-noticed Exchange 2007 change: Transaction logs are now exactly 1MB, down from the 5MB size we’ve always had before. The smaller size makes replication performance more efficient. It’s too early to tell which CDP vendors will update their products to work with Exchange 2007, especially given that Exchange 2007 includes its own CDP functionality. Taking the time now to understand how the technology works will help you have the necessary tools on hand when your system’s tires go flat.
