Microsoft Exchange Continuous Data Protection; merging local and remote site recovery
A couple of weeks ago I wrote about Lost Log Resiliency (LLR) and its positive impact on Microsoft Exchange 2007 database recoverability. However, LLR is only configurable within a Microsoft Exchange Cluster while non-cluster systems are relegated to the default setting. Check out the entry for Near loss-less data protection for Microsoft Exchange for more on LLR.
Since LLR is only configurable in Microsoft Cluster environments, it leads one to believe Microsoft Clustering is the best and only option to ensure consistent high-availability for Microsoft Exchange 2007. However, that is not so in all cases. During my research on LLR I talked to Utah State University about their cluster, backup and recovery infrastructure. During my discussion with Daniel Muller, IT System Administration Operations at Utah State University, I learned that Utah State University took a unique approach to Exchange data recovery and availability.
Joshua: Are you finding CDP a better option than LLR for maintaining consistent databases?
Daniel: Clustering and LLR weren't an option for us; we needed something that could deal with variable bandwidth considerations. The built in options didn't provide enough flexibility for the shared bandwidth to our disaster recovery site.
Joshua: Is it your experience that LLR is on by default? Does it drop log files to recover consistent databases?
Daniel: We never investigated LLR to that depth, but we did have Local Continuous Replication (LCR) enabled. LCR's impact on our network was too great for the value it delivered. That impact is why we investigated other options.
Joshua: How many users do you assign per storage group?
Daniel: We are currently attempting to keep our storage group databases under 100G. Therefore, we have varying user limits on our storage groups since we offer two different classes of service. We offer a 2 gigabyte mailbox service; which requires we limit those storage groups to 50 users each. A standard 500 megabyte service limits us to 200 users per storage group.
Joshua: How quickly, i.e. during peak times, are log files created?
Daniel: We generally find that log file creation is fairly minimal in our environment under peak user load. We control log file generation, on a typical day we will generate about 20 gigabytes of log files. However, when we undertake heavy administrative tasks such as migrating mailboxes, it's not unusual for transaction logs to exceed our 40GB volume limit quickly. We manually purge transaction log files if needed.
Joshua: InMage DR-Scout offers an option to set the databases consistent using Volume Shadow Copy Service (VSS), do you use that feature?
Daniel: Yes, although we had some initial trouble getting the feature working as desired. We eventually traced it to the excessive I/O load caused by the built-in LCR feature. Based on the InMage functionality, we disabled LCR. InMage offers an option to replicate data to another site, giving rise to a controlled disaster and data recovery option. That is, we can recover data as needed or fail-over the entire system to another location.
Joshua: Are your systems clustered using native clustering?
Daniel: No, we do not use Microsoft Clustering to cluster our Exchange nodes.
The net-net, Daniel and his team at Utah State University support a surprisingly large data set. They were able to merge a backup/recovery management need with a disaster recovery solution delivering up-to-the-minute on site recovery and a geographical recovery option. It becomes clear that continuous data protection should and can deliver more than just on site data recovery with products like InMage DR Scout.
Since LLR is only configurable in Microsoft Cluster environments, it leads one to believe Microsoft Clustering is the best and only option to ensure consistent high-availability for Microsoft Exchange 2007. However, that is not so in all cases. During my research on LLR I talked to Utah State University about their cluster, backup and recovery infrastructure. During my discussion with Daniel Muller, IT System Administration Operations at Utah State University, I learned that Utah State University took a unique approach to Exchange data recovery and availability.
Joshua: Are you finding CDP a better option than LLR for maintaining consistent databases?
Daniel: Clustering and LLR weren't an option for us; we needed something that could deal with variable bandwidth considerations. The built in options didn't provide enough flexibility for the shared bandwidth to our disaster recovery site.
Joshua: Is it your experience that LLR is on by default? Does it drop log files to recover consistent databases?
Daniel: We never investigated LLR to that depth, but we did have Local Continuous Replication (LCR) enabled. LCR's impact on our network was too great for the value it delivered. That impact is why we investigated other options.
Joshua: How many users do you assign per storage group?
Daniel: We are currently attempting to keep our storage group databases under 100G. Therefore, we have varying user limits on our storage groups since we offer two different classes of service. We offer a 2 gigabyte mailbox service; which requires we limit those storage groups to 50 users each. A standard 500 megabyte service limits us to 200 users per storage group.
Joshua: How quickly, i.e. during peak times, are log files created?
Daniel: We generally find that log file creation is fairly minimal in our environment under peak user load. We control log file generation, on a typical day we will generate about 20 gigabytes of log files. However, when we undertake heavy administrative tasks such as migrating mailboxes, it's not unusual for transaction logs to exceed our 40GB volume limit quickly. We manually purge transaction log files if needed.
Joshua: InMage DR-Scout offers an option to set the databases consistent using Volume Shadow Copy Service (VSS), do you use that feature?
Daniel: Yes, although we had some initial trouble getting the feature working as desired. We eventually traced it to the excessive I/O load caused by the built-in LCR feature. Based on the InMage functionality, we disabled LCR. InMage offers an option to replicate data to another site, giving rise to a controlled disaster and data recovery option. That is, we can recover data as needed or fail-over the entire system to another location.
Joshua: Are your systems clustered using native clustering?
Daniel: No, we do not use Microsoft Clustering to cluster our Exchange nodes.
The net-net, Daniel and his team at Utah State University support a surprisingly large data set. They were able to merge a backup/recovery management need with a disaster recovery solution delivering up-to-the-minute on site recovery and a geographical recovery option. It becomes clear that continuous data protection should and can deliver more than just on site data recovery with products like InMage DR Scout.
Leave a comment