Local Continuous Replication (LCR) involves using additional storage on the same Exchange server, and administering transaction log shipping between a primary location and backup locations. LCR doesn't offer any type of server resilience. If the Exchange server fails, you must restore from tape or perform another backup method.
LCR is useful if you have a simple disk or controller failure, and don't have any logical corruption in your Exchange information stores. If you have successfully planned for Local Continuous Replication, you should have implemented your LCR storage as mount points, instead of individual drive letters. Therefore, switching between the failed primary and the replicated copy of the information store is simple.
What if a corruption has occurred and you want to revert to a version of the store before the corruption or failure happened? Using LCR can be troublesome. A full copy of the Exchange Server database must be protected, but doing so on local disk is expensive.
How can an Exchange administrator with a storage area network (SAN) provide some database resilience if he doesn't have the capabilities (technical or resource) to implement clustering? The administrator must allow network storage to handle this. NetApp calls it Snapshot; Compellent refers to it as Data Instant Replay; and with EMC it's known as SnapView. Different vendors call them different things, but every vendor has a method to take snapshot backups. All snapshot backups work in one of two ways and affect storage-array performance in varying degrees. Overall, snapshot backups offer several benefits to Exchange administrators.
An Exchange administrator has complete control over snapshots, and doesn't need to refer back to storage administrators to restore any information or mount additional disks. All backup information that an Exchange admin needs resides on the storage array. It's very unlikely that two disks will fail on a storage array than on a direct-attached storage (DAS) disk system. If this does happen, the storage hosting your Exchange information has been replicated to another area within the overall storage array. If a store corrupts, the Exchange administrator can either repair the database or revert to a previous version and let the transaction logs roll to bring the store up to date.
Rolling back to a previous version isn't as involved as it sounds. Because networked storage is block-based, the data can be placed back into a previous state. In the case of NetApp systems, no data is moved. Instead, metabase pointers are changed to direct the LUN back to a previous state on the disk.
In other SAN systems, there may be a small amount of disk-block rearrangement as old data is placed back into the physical location of the current data. This restore action will take either the same amount of time as switching to an LCR copy or slightly longer.
SAN is beneficial for quick recoverability if the most recent snapshot isn't valuable, possibly because a corruption had been occurring for some time. In such a case, an Exchange administrator can choose a less recent backup, and try to use that database as the starting point to roll the transaction logs forward. However, this option isn't available when using LCR. The replica must be activated or the entire store must be recovered from backup media.
EXCHANGE SERVER 2007 HIGH AVAILABILITY STRATEGIES AND SANS
Part 1: SAN vs. SCR -- which is the best Exchange high availability solution?
Part 2: Replacing Local Continuous Replication with SAN storage technology
Part 3: Using Exchange 2007 Cluster Continuous Replication on a SAN
|ABOUT THE AUTHOR:|
Mark Arnold, MCSE+M, Microsoft MVP, is a technical architect for Posetiv, a UK based storage integrator. He is responsible for the design of Microsoft Exchange and other Microsoft Server solutions for Posetiv's client base in terms of the SAN and NAS storage on which those technologies reside. Mark has been a Microsoft MVP in the Exchange discipline since 2001, contributes to the Microsoft U.K. "Industry Insiders" TechNet program and can be found in the Exchange newsgroups and other Microsoft Exchange forums.