Local Continuous Replication (LCR), a high availability solution for the Exchange 2007 Mailbox Server role, uses...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
the new continuous replication technology introduced in Exchange Server 2007. This backup and disaster recovery feature uses built-in asynchronous log shipping and log replay technology to create and maintain a copy of a storage group on a second set of disks that are connected to the same Exchange server as the production storage group.
Managing Local Continuous Replication in Exchange 2007
Part 1: Exchange 2007 Local Continuous Replication overview
Part 2: Enabling Local Continuous Replication on a storage group
Part 3: Viewing the status for a Local Continuous Replication copy
Part 4: Switching to the LCR copy for database disaster recovery
Part 5: Suspending and resuming LCR for an Exchange 2007 storage group
Part 6: Manually adding an Exchange 2007 database to a storage group copy
Part 7: Use Exchange Eseutil for a passive storage group copy integrity check
Part 8: Disabling LCR on an Exchange 2007 storage group
Part 9: Adding Local Continuous Replication performance objects and counters
Part 10: Exchange 2007 LCR administration summarized
Exchange 2007 Local Continuous Replication overview
The Exchange Product group developed the Local Continuous Replication (LCR) technology to provide a native data availability solution that can be used to recover an Exchange database on an Exchange 2007 standalone server in a matter of a few minutes. In Exchange 2003 as well as previous versions, you needed to recover the lost database by restoring it from backup, which, depending on the database size, could take up to many hours. With LCR, you will be able to switch over to an exact replica (that is, a fully updated copy) of the crashed database by running a simple Exchange 2007 task.
So how does this LCR magic work? As most of us know, the database type Exchange uses is Extensible Storage Engine (ESE). ESE employs transaction log files, which means that every time a modification is made, a transaction log file is generated (instead of the change being committed directly to the database). The reason is that when the ESE database is modified, the modification won't be made directly in the physical database but instead in memory of the respective Exchange 2007 Mailbox Server. This means that should the database for some reason become corrupted or shut down, Exchange always will be able to recover the lost data (which is held in memory, remember) by using the log files.
Each log file that is generated because of a modification in the database belonging to the active copy of the storage group is replicated (copied) from the source log folder (the log folder defined for the Storage Group containing the respective database) to a target log folder associated with the passive copy of the storage group. This isn't the entire truth, because each log file is first copied to an inspector log folder located beneath the target log folder, where it is inspected to make sure it is correct. (If it isn't correct, the log file will be recopied). Finally the file is copied to the target log folder and from there replayed into the database belonging to the passive copy of the storage group.
The target log folder also contains an IgnoredLogs folder that holds any valid log files that for some reason cannot be replayed. A typical reason is that the particular log is too old. In addition, the subfolder can contain an InspectionFailed and an E00OutofDate folder. The first is a folder that holds any log files that failed inspection. When this happens, an event 2013 will be logged in the application log. The E00OutofDate folder will hold any E00.1og files that are present in the target log folder when a failover occurs.
A new Exchange 2007 service called the Microsoft Exchange Replication Service will be installed on any Exchange 2007 servers with the Mailbox Server role installed. These are responsible for replicating the log files to the target log folder. As you can see, we've tried to illustrate the basic architecture of LCR in Figure 8.1.
The log files that are replicated from the active copy to the passive copy of the storage group will be replayed in batches in order to provide the best performance possible.
Since LCP, keeps an exact replica of the active copy of the storage group, the number of Exchange backups needed is also reduced drastically. But it's important to understand that LCP, in no way eliminates traditional backups of the databases on your Exchange 2007 Mailbox servers; instead, it provides you with the option of taking weekly instead of daily backups, for example.
|Some independent advice: Bear in mind that if you want to enable LCR for a storage group, the storage group may not contain more than one mailbox or public folder database. This is because LCR doesn't support multiple databases in the same storage group. Actually, you won't even be able to enable LCR on a storage group containing multiple databases. In addition, you cannot enable LCR for a storage group containing a Public Folder database if more than one Public Folder database exists in the organization. The reason is that LCR and Public Folder replication cannot run at the same time.|
When you're partitioning the disks that should be storing the passive copies of your storage groups, it is best practice to take advantage of mount points, because they will let you surpass the 26-drive-letter limitation that exists on a Windows 2003 server. If you end up in a situation where you need to switch to a passive copy of a storage group, using mount points will make the recovery process much more painless because you can quickly change drive letters and paths.
As has been the case with mailbox stores and log files in previous versions of Exchange, it's also recommended that you place the databases and log files for a passive copy of a storage group on separate disks, just as you do with active copies of storage groups.
You should, of course, also make sure that you partition the disks that are to be used for the passive copies of the storage groups, so they are at least the same size as the disks holding the active storage group copies. Finally, keep in mind that a Mailbox Server with LCR enabled will use approximately 30-40 percent more CPU and memory than a Mailbox Server on which LCR hasn't been enabled. These extra resources are primarily used by log file verification as well as log file replay.
|Tip: LCR enables you to offload Volume ShadowCopy Service (VSS) backups from the active storage group to the passive storage group, which will preserve disk I/0 on the disks on which the active storage group is located. This also means that you can perform restores from a passive copy of a storage group.|
As you can understand, LCR is an ideal solution for small or medium-sized organizations because the functionality allows rapid recovery from database issues and requires only an extra set of disks for the database copies. LCR increases the availability of databases on an Exchange 2007 standalone server in an affordable way. For small shops that don't have a big fancy server with multiple sets of disks, it is possible to keep the LCR copy on an external USB disk.
Return to table of contents or proceed to part 2 on how to enable Exchange 2007 LCR on a storage group.
|This chapter excerpt from How to Cheat at Configuring Exchange Server 2007: Including Outlook Web, Mobile, and Voice Access, by Henrik Walther, is printed with permission from Syngress, a division of Elsevier, Copyright 2007.
Click here for the chapter download.
Dig Deeper on Microsoft Exchange Server Sync and Replication Issues