Local Continuous Replication (LCR) is a high availability feature built into Exchange Server 2007. LCR allows admins to create and maintain a replica of a storage group to a SAN or DAS volume. This can be anything from a NetApp to an inexpensive jump drive or even a removable sled. In Exchange 2007, log file sizes have been increased, and those logs are copied to the LCR location (known as log shipping) and then used to “replay” data into the replica database (aka change propagation).
LCR can be used to reduce the recovery time in disaster recovery scenarios for the whole database, instead of restoring a database you can simply mount the replica. However, this is not to be used for day-to-day mailbox recovery, message restores, etc. It’s there to end those horrific eseutil /rebuild and eseutil /defrag scenarios. Given the sizes that Exchange environments are able to get in Exchange 2003 R2 and Exchange 2007, this alone is worth the drive space used.
Like with many other things in Windows, LCR can be configured using a wizard. The Local Continuous Backup wizard (I know, it should be the LCR wizard) can be accessed using the Exchange Management Console. From here, browse to the storage group you would like to replicate and then click on the Enable Local Continuous Backup button. The wizard will then ask you for the path to back up to and allow you to set a schedule. Once done, the changes will replicate, but the initial copy will not. This is known as seeding and will require a little PowerShell to get going. Using the name of the Storage Group (in this example “First Storage Group”) you will stop LCR, manually update the seed, then start it again, commands respectively being:
Suspend-StorageGroupCopy –identity “First Storage Group”
Update-StorageGroupCopy –identity “First StorageGroup”
Resume-StorageGroupCopy –identity “First StorageGroup”
Now that your database is seeded, click on the Storage Group in the Exchange Management Console and you should see Healthy listed in the Copy Status column for the database you’re using LCR with. Loop through this process with all of your databases and you’ll have a nice disaster recovery option to use next time you would have instead done a time consuming defrag of the database.