Introduction
Local Continuous Replication (LCR) which formerly was known as the Local Continuous Backup feature is, when speaking high availability and total cost of ownership (TCO), an extremely interesting new feature. The LCR feature makes it possible to create and maintain an exact copy (replica) of databases in a storage group on an Exchange 2007 Server to a second set of disks in the server or to a NAS/SAN (via iSCSI or LUNs). Exchange Administrators dealing with Small Business Servers (SBS) might even want to use an externally attached USB drive. When the LCR copy has been created its currency is maintained through so called change propagation (log replay). This change propagation works by copying the production storage group transaction log files to the location of the LCR storage group (log shipping), where the transaction log files are then replayed into the database(s). The goal of the new LCR feature is, as mentioned, to take high availability even further, as well as reduce the total cost of ownership (TCO) for Exchange Server 2007, and I must say LCR does exactly that. It reduces the recovery time used in disaster recovery situations as you can switch to the LCR copy in a few seconds should a production database get corrupted. We all know that the costs associated with backups, restores etc. has grown considerably over the last couple of years, especially with messaging servers, but since you, when using the LCR feature, always have an exact copy (replica) of a production storage group, it reduces the number of regular backups you need to perform. You shouldn’t drop your Exchange backups completely but you could, without any worry, change your Exchange backup schedule from daily to weekly.
Okay let’s get moving with the exciting stuff.
Enabling and Configuring Local Continuous Replication
The Local Continuous Replication feature is enabled on a Storage Group level under the Mailbox node located beneath the Server Configuration in the left pane of the Exchange System Management Console, as can be seen in Figure 1 below.
Figure 1: Enabling Local Continuous Backup (Replication)
After clicking Enable Continuous Replication in the Actions pane, we’re informed that enabling LCR for this storage group will create a second copy of the databases in the storage group (Figure 2). Since this is exactly what we want to do, click Next.
Figure 2: Enable Storage Group Local Continuous Backup (Replication)
Now we’re going to specify the path to the LCR files for the respective Storage Group (Figure 3), for the purpose of this article we’re simply specifying the E: drive, which is just another partition on the same server, but as mentioned in the introduction section of the article, this could be anything from a share on a remote server, a SAN/NAS or even a connected USB drive. When the location has been specified we can click Next.
Figure 3: Specifying the paths for the replicated log and system files
In the next step we have to specify the path to the location of the second copy of the database(s) as shown in Figure 4 below, we can then click Next.
Figure 4: Specifying the path for the copy database
We have now reached the step where we enable LCR for the Storage Group, so let’s click Enable and see what happens (Figure 5).
Figure 5: Enabling Local Continuous Replication for the Storage Group
As can be seen in Figure 6 the enable Local Continuous Replication wizard completed successfully, but notice that automatic initial-seeding of the Storage Group didn’t occur, then click Finish.
Figure 6: The Local Continuous Replication feature was enabled with success
The reason why initial-seeding didn’t take place automatically was simply because we’re running a build that doesn’t support this task yet, but don’t worry as you know we’re still speaking early BETA software, and this missing feature will be available in Exchange Server 2007 BETA 2.
Since initial-seeding didn’t take place the status of the copy will show as broken (Figure 7).
Figure 7: Copy status for the Storage Group broken
If you bring up the Property page of the respective Storage Group and click the Local Continuous Replication tab, you’ll see a more detailed status (Figure 8).
Figure 8: LCR copy in an unseeded state
Since initial-seeding didn’t take place automatically, and since seeding is a required step in order for us to get a functional copy of the database running in a healthy state, we have to do the seeding manually using the Update-StorageGroupCopy task. But before we can seed the database we need to suspend Local Continuous Replication for the respective Storage Group. As some of you have perhaps noticed, there’s an option for suspending Local Continuous Replication for the respective Storage Group in the Actions pane in the Exchange Management Console, but unfortunately this task is not working in pre-BETA 2 builds and therefore prevents us from successfully suspending LCR via the GUI. Therefore we need to execute this task via a CMDlet in the Exchange Management Shell instead. To do so fire up the shell by clicking Start > All Programs > Microsoft Exchange Server 2007 > Exchange Management Shell, then type the following:
Suspend-StorageGroupCopy –identity “First Storage Group”
Now that we have suspended LCR for the Storage Group, we need to initiate the seeding, this is done by executing the following CMDlet:
Update-StorageGroupCopy –identity “First StorageGroup”
Notice the progress bar indicator shown in Figure 9 below.
Figure 9: Seeding the Mailbox Database
When seeding has occurred, we can again resume LCR for the Storage Group, so we’ll execute below CMDlet:
Resume-StorageGroupCopy –identity “First StorageGroup”
When LCR has been resumed, let’s switch back to the Exchange Management Console and click Refresh (Figure 10).
Figure 10: LCR has been seeded and the copy is healthy
Notice the Status under the Property page of the Storage Group, here you can see the status is healthy but can also see the things such as the last time logs were copied, replayed etc. (Figure 11)
Figure 11: Status under the Property Page of the Storage Group after seeding has occurred
In Figure 12 below, you can also see the seeded mailbox database in Windows Explorer.
Figure 12: Seeded Mailbox Database in Windows Explorer
Testing the Log File Shipping and Replaying Mechanisms
Now that we have enabled the LCR feature; I guess you might be interested in seeing how this log file shipping works right? In order to see this, we simply need to send a test message with an attachment (big enough to generate a few log files) from a mail mailbox located in the database belonging to the Storage Group on which we enabled LCR.
As you can see in Figure 13 and 14 below, there currently exists four transaction log files which are associated with the database in the Storage Group.
Figure 13: Existing Log Files associated with the database in the production Storage Group
Figure 14: Log Files associated with the second copy of the database in the production Storage Group
So let’s fire up OWA 2007 and send the test message.
Figure 15: Large attachment sent via OWA 2007
As you can see in Figure 16 below two new log files have now been generated.
Figure 16: New log files
Even more interesting is that these two log files have been shipped to the Log files folder (Figure 17) as well as being replayed into the database replica (Figure 18), we specified back when LCR was enabled.
Figure 17: Shipped Log files
Figure 18
Switching to the Replica Database
Alright now that you have seen how log file shipping and log file replay works, you probably wonder how you switch to the replica database, in case the production mailbox database gets corrupt. Well first you should make sure the respective Mailbox database is dismounted, you should then launch the Exchange Management Shell and type:
Restore-StorageGroupCopy –Identity “First Storage Group” –ReplaceLocations
This CMDlet will update the Active Directory so that the mailbox database, Transaction Log Files, as well as the System Files path points to the replicas, which in this case is E:\DATABASES and E:\LOGS.
Because we’re speaking an early BETA build, we also need to manually copy a prefix log file from the log files folder to E:\LOGS (will be fixed in BETA 2).
Now switch back to the Exchange Management Console and navigate down to the Mailbox node under Server Configuration container. Click Refresh in the Actions Pane, then notice the database file path has changed to E:\DATABASES\Mailbox Database.edb as shown in Figure 19 below.
Figure 19: Changed Database File Path
The final step is to mount the mailbox database. When you have done so the LCR copy of the production database is used but since it’s fully replicated, your users won’t notice a thing.
Note:
Remember to re-enable LCR for the particular Storage Group after performing a switch to a secondary copy of a database
Conclusion
The new Local Continuous Replication feature in Exchange Server 2007 is an extremely welcome addition to the Exchange product, when speaking high availability. Not only will you be able to reduce the backup schedule from a daily to a weekly backup and thereby reduces the total cost of ownership (TCO). In case a production database in an LCR-enabled Storage Group crashes or is down for other purposes, you’ll also be able to switch to the secondary copy in a few seconds.
As many of you know, an expensive 3rd party solution is required in order to be able to make use of database replication in Exchange 2003, so the LCR feature is definitely a feature worth mentioning for your Exchange 2003 Server customers (or your boss!), because LCR is one of the best benefits of migrating to Exchange Server 2007, when that time comes.
Some of you may also have heard about the new Cluster Continuous Replication (CCR) feature, and yes you’re right I’ll cover that feature in a separate article here on MSExchange.org in a near future.
