Microsoft Exchange LCR Compliments Archiving
Written by Carl E. Reid on October 28, 2008
Recently I had an opportunity to meet with an associate and email administrator in New York City named Lisa Bruno. She and her team are involved in a Lotus Notes-to-Microsoft Exchange migration. Lisa shared some interesting insights. Having recently migrated to Exchange 2007, one of the many questions we find is ‘what to use for backup?’. Within Exchange you can set a “Local Continuous Replication”. It takes an exact replica of the storage group. Now the question is, since Local Continuous Replication is set do we need third party backup software? In response to that question, we determined that yes we still need a backup solution. By no means should LCR be considered as the only form of backup. LCR also compliments any implemented archiving solutions by adding an extra utility for maintaining data integrity. Data integrity is crucial to just that one instance when archived data must be retrieved due to a legal inquiry. While it does give that option and helps in recovering quickly, it should not be the end of all.
Now the “LCR” is more of another option if a disaster occurs. As a small business this gives us a quick reliable way of recovery. Should a database get corrupted it automatically gives you an option to switch to the LCR copy. To be exact in terms, it switches to a Passive copy of the database. This minimizes the downtime. Now how does this happen? It all takes place by creating a log file. This log file is called a Transactional Log. Each time a change is made on the database it writes to the log instead of directly to the database. This is how it determines how to quickly recover the database. As part of enabling the Local Continuous Replication from the Exchange Management Console under the Server Configuration Node under Mailbox. That is part of another documentation. To recover from a corrupted database you have the option to run Restore-StorageGroupCopy CMDlet. This will replace the LCR copy (passive copy) to become the active copy. The exact command is Restore-StorageGroupCopy -Identity “First Storage Group” -ReplaceLocations:$true
Once the passive copy becomes the active one, LCR is disabled. You have to enable Local Continuous Replication for that storage group. By using this method the path of the group also changes. Microsoft does not recommend this method but instead recommends the Restore-StorageGroupCopy CMDlet without the ReplaceLocations parameter. This is similar to the other method but it does not change the path of the storage group. It gives you more control to replace the database to its current path or set another path. For either method used you will probably need to restart the server.
You can suspend and resume the Local Continuous Replication at any time. To do so you can do it via the Exchange Management Console. Reasoning for suspending the LCR could be for any specific reason. But one in particular is to do an integrity check. This you should do once in a while. Once you are ready to enable the Local Continuous replication you can do so using the same Exchange Management Console. Just click on Resume Local Continuous Replication. Check the status field until it says Healthy.
Every once in a while you should check the integrity of the passive storage group copy to make sure that the database and the log file are not corrupted. This can be accomplished by running Exchange Server Database Utilities (Eseutil.exe).
















