text: White Paper: Continuous Replication Deep Dive
  Applies to: Exchange Server 2007 SP1
  Topic Last Modified: 2009-01-14
  Ross Smith IV, Technology Architect; Scott Schnoll, Principal Technical Writer, Microsoft Exchange Server
  July 2008
  Microsoft Exchange Server 2007 Service Pack 1 (SP1)
  Table of Contents
  - Introduction
  - Continuous Replication Basics
  - Replication Components
  - Replication Service Components
  - Replication Service Configuration Information
  - Replication Service Communication Coordination
  - Log Shipping and Replay
  - Scheduled Outages
  - Unscheduled Outages
  - Lost Log Resilience
  - Transport Dumpster
  - Incremental Reseed
  - Database Reseed Scenarios
  - Standby Continuous Replication
  - Continuous Replication and Backups
  - Log Truncation
  - Comparing Continuous Replication with Other Replication Solutions
  - Conclusion
  - Additional Information.
  - Local Continuous Replication (LCR) LCR is a single-server solution that uses continuous replication to create and maintain a copy of a storage group on a second set of disks connected to the same server as the active storage group copy. For more information, see Local Continuous Replication.
  - Cluster Continuous Replication (CCR) CCR is a high availability feature that provides failover capabilities for e-mail service and mailbox data, using continuous replication to provide one copy of data redundancy with clustering technology for the server redundancy. For more information, see Cluster Continuous Replication.
  - Standby Continuous Replication (SCR) SCR is a disaster recovery feature that employs continuous replication to create and maintain multiple copies of a storage group. It is provided as a feature to facilitate site resiliency. For more information, see Standby:
  - Create a target database by seeding the destination with a copy of the source database.
  - Monitor for new logs in source log directory for copying by subscribing to Windows file system notification events.
  - Copy any new log files to the destination inspection log directory.
  - Inspect the copied log files.
  - Upon successful inspection, move the copied log file to the storage group copy’s log path and replay the copied log into the copy of the database.
  The two key services responsible for log generation, log shipping, and log replay activity are:
  - Microsoft Exchange Information Store service Responsible for servicing user and application requests, performing write ahead logging, and updating the database file via Extensible Storage Engine (ESE).
  - Microsoft Exchange Replication Service Responsible for log shipping and replay against the database copy.
  The following steps are performed by ESE when data is retrieved from, inserted into, or modified in a database.
  - An operation occurs against the database (a client sends a new message), and the page that requires updating is read from the database file and placed into the ESE cache (assuming the page is not already in memory), while the log buffer is notified and it records the operation in memory.
  - The changes are recorded by the database engine but these changes are not immediately written to the database file on disk. Instead, these changes are held in the ESE cache and they are known as dirty pages because they have not been committed to the database file. The version store is used to keep track of these changes, thus ensuring that isolation and consistency are maintained.
  - As the database pages are changed, the log buffer is notified to commit the change, and the transaction is recorded in a transaction log file, which may or may not require closing the current Exx.log file and starting a new log generation. (Note that ESE is also responsible for closing a log file once it reaches its maximum file size (1 MB) and starting a new generation.)
  - Eventually the dirty database pages are written to the database file on disk.
  - The checkpoint is advanced.
  For more information on diagnostics logging and the associated settings, see Diagnostic Logging of Exchange Processes.
  The Replication service uses several components to provide continuous replication between an active storage group and one or more copies of the active storage group. The following are a few of the components that are involved in the continuous replication process and pipeline.
  - LogCopier Responsible for copying closed log files from the source storage group to the target server that contains a copy of the storage group. This is an asynchronous operation in which the Replication service continuously monitors the source storage group's log file directory. It does this monitoring by subscribing to Windows file system notification events. When a new log file is closed on the source, an event fires which notifies the Replication service that a new file exists. The LogCopier will then copy the log file to the inspector location on the target server.
  - LogInspector Responsible for verifying that the log files are valid. It checks the destination inspector directory on a regular basis. If a log file is found to be corrupted or unusable for replay, the Replication service will request a re-copy of the file.
  - LogReplayer Responsible for replaying inspected log files into the database copy.
  - LogTruncater Responsible for deleting log files that have been successfully replayed into the database copy. This is especially important because typically after a full or incremental backup, the log files that are below the checkpoint are deleted because the log records contained within those log files have been written to the database. When continuous replication is used, the LogTruncator only deletes log files that are not needed for recovery and replay. Any log files on the active copy that have not been replicated and replayed into the database copy are not deleted by an online backup of the active copy.
  - Incremental Reseeder Responsible for ensuring that the active database and database copies are not diverged after a database restore has been performed, or after a failover has occurred in a CCR environment.
  - Seeder Responsible for creating the baseline content of a storage group used to start replay processing. The Replication service performs automatic seeding for new storage groups, and for any existing storage groups that still have all generated logs (including the first log file, which contains the CreateDB record) available.
  - Replay Manager Responsible for keeping track of all replica instances. It creates and destroys replica instances on-demand, based on the online status of the storage group. The configuration of a replica instance is intended to be static. Therefore, when a replica instance configuration is changed, the replica will be restarted with the updated configuration. In addition, during shutdown of the Replication service, replica instance configuration is not saved. As a result, each time the Replication service starts it has an empty replica instance list. During startup, the replay manager performs discovery of the storage groups that are currently online and creates a "running instance" list.
  The replay manager periodically runs a configupdater thread to scan for newly configured replica instances. The configupdater thread runs in the Replication service process every 30 seconds for LCR or CCR, and every 3 minutes for SCR. It will create and destroy a replica instance based on the current database state (whether the database is online or offline). The configupdater thread uses the following algorithm:
  - Read instance configuration from Active Directory.
  - Compare list of configurations found in Active Directory against running storage groups/databases. The Active Directory configuration for an instance is also checked to see if it has changed, if so the instance is put on a restart list.
  - Produce a list of running instances to stop and a list of configurations to start.
  - Stop running instances on the stop list.
  - Start instances on the start list.
  Each storage group and database enabled for LCR has the msExchHasLocalCopy attribute defined. The Replication service uses the following algorithm to search Active Directory for replica information.
  - Find the Exchange Server object in Active Directory using the computer name. If there is no server object then return.
  - Enumerate all storage groups that are on this Exchange server.
  - For each storage group with msExchHasLocalCopy set to true, retrieve the source and destination paths for the system files, log files, and database file.
  In a CCR environment, the Replication service performs the following tasks to retrieve the clustered mailbox server’s configuration.
  - Establishes a connection to the cluster database.
  - Determines which node owns the clustered mailbox server.
  - Enumerates all storage groups that exist on the source and target nodes, as well as various settings used for replication such as:
  - Source and destination paths for the system files, log files, and database file.
  - Returns the last owner of the storage group (assuming the storage group has been mounted before).
  - The network share used for log shipping.
  - The AutoDatabaseMountDial setting. See "Incremental Reseeder" earlier in this white paper.
  - The ForcedDatabaseMountAfter setting
  - Determine the appropriate network path for log shipping.
  - Verifies that the configuration on the source equals that of the target.
  For SCR environments, the Replication service uses the msExchStandbyCopyMachines attribute to identify which storage groups are enabled for replication, and it performs the following tasks:
  - Find the Exchange Server object in Active Directory using the computer name. If there is no server object then return.
  - Enumerate all storage groups that are on this Exchange server. For each storage group with msExchStandbyCopyMachines attribute, do the following:
  - Retrieve the ReplayLagTime and TruncationLagTime parameters for each target server.
  - Retrieve the source and destination paths for the system files, log files, and database file.
  The Replication service communicates between the active instance and the passive instance via three mechanisms.
  - Log Files Certain information, like backup status and database header changes, is recorded within the log files on the active instance and replicated to the copy, thereby updating the database copy. For more information, see "Continuous Replication and Backups" later in this white paper.
  - Cluster database or registry The Replication service stores replay state data on a per-storage group basis in either the cluster database (CCR) or the registry (LCR/SCR). The data that is written to and read from these locations is for persistent state information, such as:
  - Dumpster variables that are used when transport dumpster is invoked.
  - Activation variables like whether the database can be mounted if it is configured to allow no loss.
  - Replication status for the storage group; for example, Suspended or Failed.
  - Store process The Replication service will generate RPC calls to the Store process on the active instance for log truncation coordination. For more information, see "Log Truncation" later in this white paper.
  Now that we have a basic understanding of the core components that are involved, we can discuss how log shipping works. Before log files can be shipped to a passive copy, the active database copy must first be seeded. This can be accomplished in a few ways.
  -.
  - Seeding using the Update-StorageGroupCopy cmdlet You can use the Update-StorageGroupCopy cmdlet in the Exchange Management Shell to seed a storage group copy. You can also use the Update Storage Group Copy wizard in the Exchange Management Console.:
  - Share Name: <Storage Group GUID>$
  - Folder Path: <drive>:\<Storage Group Log Folder Path>
  - Share Permissions: <root domain>\Exchange Servers – Read
  - Folder Permissions: <root domain>\Exchange Servers – Read, <computer>\Administrators – Full Control, SYSTEM – Full Control
  Depending on the environment, the SCR target's service will connect using a particular namespace.
  - The Replication service on the CCR passive node always connects to \\nodenameActive to pull logs to the passive copy.
  - The Replication service on the SCR target, when connecting to a CCR source environment, connects to \\nodenameActive to pull logs to the SCR target.
  - The Replication service on the SCR target, when connecting to a SCC source environment, connects to \\CMSName to pull logs to the SCR target.
  - The Replication service on the SCR target, when connecting to a standalone mailbox server, connects to \\ServerName to pull logs to the SCR target.).
  - A log file is closed in the source log directory. LastLogCopyNotified is updated with the last generation that was seen in the source directory.
  - The target node Replication service utilizes a process at the managed code level (LogCopier) to pull the log files to the target node over Server Message Block (SMB). The copied log files are then placed in an Inspector directory that exists within the storage group’s log folder. The logs are placed in an inspector directory so that they are isolated and not accidentally replayed into the copy database until after they have gone through inspection. LastLogCopied is updated when a log is successfully copied into the Inspector directory.
  - The log files are inspected via LogInspector and moved to the passive log directory. LastLogInspected is updated when a log is successfully inspected. For more information, see "Log Inspection" later in this white paper.
  - If log copying or the log file inspection fails, the Replication service will attempt to recopy the log file and inspect it again. The Replication service will do this three times before marking the log file as irrecoverable and requiring a database reseed.
  - The log file is replayed into the database copy by the Replication service (LogReplayer). LastLogReplayed is updated when a log is successfully replayed into the database. For more information, see "Log Replay" later in this white paper.
  The following actions are performed by LogInspector:
  - Physical integrity inspection This validation utilizes ESEUTIL /K against the log file and validates that the checksum recorded in the log file matches the checksum generated in memory.
  - Header inspection The Replication service validates the following aspects of the log file’s header:
  - The generation is not higher than the highest generation recorded for the storage group in question.
  - The generation recorded in the log header matches the generation recorded in the log filename.
  - The log file signature recorded in the log header matches that of the log file.
  - Removal of Exx.log Before the inspected log file can be moved into the log folder, the Replication service needs to remove any Exx.log files. These log files are placed into another sub-directory of the log directory, the ExxOutofDate directory. An Exx.log file would only exist on the target if it was previously running as a source. The Exx.log file needs to be removed before log replay occurs because it will contain old data which has been superseded by a full log file with the same generation. If the closed log file is not a superset of the existing Exx.log file, then we will have to perform an incremental or full reseed. For more information on full reseed, see "Database Reseed Scenarios" later in this white paper.
  After the log files have been inspected, they are placed within the log directory so that they can be replayed in the database copy. Before the Replication service replays the log files, it performs a series of validation tests.
  - Recalculates the required log generations necessary for log replay to be successful. This check determines the highest and lowest log generations required by inspecting the database header.
  - The database header contains a log signature and this will be compared with the log file’s signature to ensure they match.
  - The database header will report one of two conditions: Either the database is in a consistent state (Clean Shutdown) or an inconsistent state (Dirty Shutdown). If the database is consistent, then the next log file to be committed log position (LGPOS) will be used to derive the lowest and highest required log generations. If the database is in an inconsistent state, then the “Required Log” stamp defines the lowest and highest required generations. In addition, the backup information that is stored in the database header is reviewed to determine the last generation that was backed up.
  - Determines the highest generation that is present in the log directory to ensure that a log file exists. If there are no log files, then replay cannot continue.
  - Compare the highest log generation that is present in the directory to the highest log file that is required. As long as the highest log generation that is present is equal to or higher than the highest required log generation, replay can continue.
  - Make sure the logs form the correct sequence. Checking all the log files in the directory is a slow process, so only the required log files are validated. This is done to determine if recovery will fail immediately (the assumption being that if recovery fails on generation N, the database header will require generation N-1). In addition to validating that all the required log files are available, the following additional validation steps are performed:
  - Ensures the generation of a log file matches the sequence expectation.
  - Ensures the log file's signature is correct.
  - Ensures the creation time of the log file forms a sequence with previous log files.
  - Query the checkpoint file, if one exists.
  - If the checkpoint file is too advanced by defining a generation that is higher than the lowest generation required, then the checkpoint file will be deleted.
  - If the checkpoint is too far behind and points to a non-existent file, then the checkpoint file will be deleted..
  - Validate that the required generations in the database header were updated. There are certain situations in which the database header will not get updated after a log replay event. This occurs when the log file that was replayed only contains termination and initialization records. In this scenario, however, the database should be in a consistent state.
  - Execute the LogTruncater phase to remove any unnecessary logs from the passive and the active path. This call reads the database header for full and incremental backup information, so replays are blocked for this duration. For more information on how log truncation is performed, see "Log Truncation" later in this white paper..
  - Lossless Lossless is zero logs lost. determine whether the databases can be mounted without any data loss. If possible, the databases are mounted. If they cannot be automatically mounted, the system periodically attempts to copy the logs. If the server returns with its logs intact, this attempt will eventually succeed, and the databases will mount. If the server returns without its logs intact, the remaining logs will not be available, and the affected databases will not mount automatically. In this event, administrative action is required to force the database to mount when logs are lost.
  - Good availability Good availability is three logs lost. Good availability provides fully automatic recovery when replication is operating normally and replicating logs at the rate they are being generated.
  - Best availability Best availability is six logs lost, which is the default setting. Best availability. the order of write operations of Exchange data is always memory, log file, and then database file. LLR works by delaying writes to the database until the specified number of log generations have been created. LLR delays recent updates to the database file for a short time. The length of time that writes are delayed depends on how quickly logs are being generated..
  - Committed The committed marker tells ESE the last log generated. The term is somewhat of a misnomer because it does not mean that the log records contained within the log file are actually written to the database file.
  - Checkpoint The checkpoint marker tells ESE the minimum log file required for replay. All log files prior to (below) the checkpoint contain log records that have been written into the database file.
  Exchange 2007 added an additional marker for LLR and divergence detection.
  - Waypoint The waypoint marker tells ESE the maximum log file required for replay. All logs prior to (below) the waypoint are required for recovery as some of those logs contain data that has been committed to the database. All log files after (above) the waypoint have not been committed to the database..
  - Committed is log generation 20 (the last log generation listed in “Log Committed”).
  - Checkpoint is log generation 2 (the first log generation listed in “Log Required”).
  - Waypoint is log generation 10 (the last log generation listed in “Log Required”).:
  - The Replication service will attempt to copy the missing log files from NodeA in order to prevent a lossy activation of the storage groups.
  - If the copy attempt fails, the Replication service will calculate the log loss by subtracting LastLogInspected from LastLogGenerated for each storage group and comparing this value with the clustered mailbox server’s AutoDatabaseMountDial value. If the difference is less than the AutoDatabaseMountDial value, then the storage group will mount. If the difference is more than the AutoDatabaseMountDial value, then the storage group will not mount.:
  - Data that was submitted to a transport server (messages or appointment invites)
  - Non-transport related user data (calendar entries, contacts, tasks, notes, drafts, property update, and so on)
  - Database maintenance records (online maintenance)
  - Log rolls:
  - MaxDumpsterSizePerStorageGroup Defines the size available for each storage group on the Hub Transport server. The recommendation is that this be set to 1.5 times the maximum message size limit within your environment. If you do not have a maximum message size limit set, then you should evaluate the messages that are delivered within your environment and set the value to 1.5 times the average message size in your organization. The default value for this setting is 18 MB.
  - MaxDumpsterTime Defines the length of time that a message remains within the transport dumpster if the dumpster size limit is not reached. The default is seven days..
  - If the databases are within the AutoDatabaseMountDial value, they will automatically mount. For LCR, the dumpster trigger is only initiated when Restore-StorageGroupCopy is exercised.
  - The Replication service will record that the storage group requires transport dumpster redelivery in the cluster database (or in the case of LCR, within the registry) by setting the DumpsterRedeliveryRequired key to true.
  - The Replication service will record the Hub Transport servers that exist within the clustered mailbox server’s Active Directory site in the cluster database (or in the case of LCR, within the registry) setting DumpsterRedeliveryServers.
  - The Replication service will calculate the loss window. This is done using the LastLogInspected marker as the start time and the current time as the end time. Since the transport dumpster is based on message delivery times, we generously pad the loss window by expanding it 12 hours back and 4 hours forward. The start time is recorded in DumpsterRedeliveryStartTime and the end time is recorded in DumpsterRedeliveryEndTime.
  - The Replication service makes an RPC call to the Hub Transport servers listed in DumpsterRedeliveryServers requesting dumpster redelivery for the given loss time window. If the Hub Transport server is not available, CCR will try the same request every 30 seconds until the configured MaxDumpsterTime is reached. For LCR, this request is only sent once.
  - The Hub Transport server will acknowledge the first redelivery request with a Retry response.
  - The Hub Transport server will redeliver the messages it has within its transport dumpster for the allotted time window. Once the message is resubmitted for delivery, the message is removed from the transport dumpster.
  - The Replication service makes an RPC call to the Hub Transport servers listed in DumpsterRedeliveryServers requesting dumpster redelivery for the given loss time window.
  - The Hub Transport servers that have successfully redelivered the dumpster messages will acknowledge the redelivery request with a Success response. At this point the Replication service will remove those Hub Transport servers from the DumpsterRedeliveryServers key.
  - This process will continue until either all Hub Transport servers have redelivered the mail, or the MaxDumpsterTime has been reached. Again, in the LCR scenario, the request will only be sent once, so Hub Transport servers that are unavailable at the time Restore-StorageGroupCopy is executed will never redeliver dumpster items for this loss window..
  - The transaction log files were reduced from 5 MB to 1 MB. This size reduction ensures that only a small amount of data is lost per log file.
  - LLR was added to ESE.:
  Initiating FILE DUMP mode...
  Database: priv1.edb
  ...
  State: Dirty Shutdown
  Log Required: 2-3 (0x2-0x3)
  Log Committed: 0-5 (0x0-0x5)
  ...
  - Committed is log generation 5 (the last log generation listed in “Log Committed”).
  - Checkpoint is log generation 2 (the first log generation listed in “Log Required”).
  - Waypoint is log generation 3 (the last log generation listed in “Log Required”).
  - Log generations 4 and 5 are beyond the waypoint..
  - In a scheduled outage scenario, the active log file is closed and all required log files are shipped to the target database copy ensuring that the copy activation is lossless.
  - Unscheduled outages where log shipping is healthy and keeping up with the log generation on the active will not diverge the database copies. This can be corrected by incremental reseed as a result of LLR enforcing a database lag so that the updated log stream can just be applied and rolled forward. Ensuring that log shipping is healthy is critical for environments that utilize continuous replication. For more information, see Monitoring Continuous Replication.
  - Network outages do not require database reseeds as long as the log streams on the source are not truncated. Log truncation will not happen automatically as continuous replication is in an unhealthy state or otherwise inoperable. For more information, see the "Log Truncation" section.
  - Network outages where there are multiple cluster replication host names defined do not require database reseeds, as automatic failover between the defined networks will occur, thus ensuring that the log streams are successfully copied to the passive node.
  The following scenarios require reseeds:
  - The administrator performed offline maintenance (ESEUTIL defragmentation, ISINTEG, ESEUTIL hard repair) against the production database. Offline maintenance operations like offline defragmentation change the structure of the database and these changes are not logged; therefore, a database reseed is required.
  - A log in the log stream is corrupted or accidentally deleted before it was copied to the passive. In this case the only way past that log for the copy is to perform a database reseed.
  - A failover occurred that significantly diverged the database copies. For this scenario to occur, the databases have to be brought online either through administrator intervention or by setting the ForcedDatabaseMountAfter value on the clustered mailbox server. Recall that when a lossy failover occurs, the Replication service calculates the loss in terms of log files and compares this to the AutoDatabaseMountDial value. If this loss is greater than the LLR depth, then database divergence has occurred between the nodes and this can only be corrected by performing a database reseed.
  - Setup for CCR automatically assigns ownership of the clustered mailbox servers to both the active and the passive node. However, if the passive node has failed or is otherwise unavailable, the passive node can be removed from the clustered mailbox server's list of RedundantMachines to allow for log truncation to occur on the active instance. However, once the passive node is repaired or brought back online and re-added to the RedundantMachines list, the database on the passive node will need to be reseeded as there is a gap in the log sequence. For more information on how to adjust the RedundantMachines list, see How to Configure Clustered Mailbox Server Ownership in a CCR Environment.
  - Using the Failover Cluster Management tool, Cluster Administrator, or Cluster.exe to manage storage group resources in a CCR environment could result in database divergence. The Cluster Administrator does not include any logic that the Exchange cmdlets have to prevent and warn administrators concerning database divergence issues during lossy failures. For more information, see the Exchange Team blog entry, Exchange Tools vs. Cluster Tools: What's the Deal?
  - In RTM, if you enabled the page zeroing functionality, this was only performed during an online streaming backup. As a result, page zeroing was not a logged operation and therefore, you would have to perform a database reseed to propagate the changes. This has been addressed in SP1, by allowing page zeroing to be an opt-in online maintenance task. For more information about how to use the functionality in SP1, see Online Maintenance Database Scanning in Exchange 2007 SP1 and SP2.
  - When a point-in-time recovery has occurred. In this scenario, an earlier copy of the database and old log files have been restored, taking the active database back to a specific point in time, thereby causing divergence from the passive copy. You would have to reseed the passive copy..
  - A lossy activation on an SCR target will never invoke the transport dumpster.
  - LCR and CCR only support a 1:1 replication model. SCR supports a many:many (1:1, many:1, and 1:many) replication model. (A source storage group can be replicated to multiple SCR targets, though we recommend having no more than four copies.)
  - When planning many:1 replication models, keep in mind that SCR has the same path requirements like CCR or LCR. Each database must be replicated to the same corresponding drive and path. When designing source servers, ensure that each folder path is unique.
  - Log copying to the SCR target is continuous, however SCR supports log replay lag and truncation lag.
  - Replay lag is designed to minimize the chance of needing to reseed when the source is also using continuous replication and experiences a lossy failure. By default, replay lag is set to one day.
  - Truncation lag is designed so that the logs on the target can be used to recover from loss on source. By default, truncation lag is disabled.
  - Even though an option for replay lag exists, during recovery/activation, all log files are replayed (unless the log files are removed from the log path manually).
  - Initial seeding of the database to the SCR target is not instantaneous. By default, the database will not be seeded until after 50 log files are replicated and the replay lag time has been exceeded. However, this can be overridden by executing Update-StorageGroupCopy.
  - There is no Exchange-aware backup mechanism to back up SCR target storage groups. That being said, you can suspend replication and take a flat file backup of the database and log files on the SCR target.
  - Log truncation is SCR-aware. For more information on how log truncation occurs, see "Log Truncation" later in this white paper.
  One of the benefits of using continuous replication is the ability to offload Volume Shadow Copy Service (VSS)-based backups from the active storage groups to the passive storage groups. possible by the Exchange Replica VSS Writer in the Replication service, and the Replication service has a copy of the data, but it can only get its data and modifications from the store. It can't independently modify its copy of the database; that would produce divergence. Therefore, it can't modify the header of its database copy.
  The solution is to have the Replication service coordinate its backups with the store. As soon as you start a backup on the passive copy, the Replication service contacts the store on the active and tells it that a backup is about to start. This is done to prevent the same storage group on both the active and the passive from being backed up simultaneously. Once the backup is finished, the Replication service contacts the store and lets it know that the backup completed.
  The database header modifications resulting from the backup are then made by the store on the active. This action generates a log record, which through continuous replication is copied to the passive. When it is replayed, the database header on the passive is then updated.
  This is a little more complex than traditional backups, and it has some interesting side effects. For example, if you back up the passive and then immediately after the backup has finished you look at the database on the passive, it will not reflect the backup. The database on the active node will however, reflect it.
  So if you are backing up databases in a continuous replication environment, looking at the database on the active is the most accurate way to determine what the last backup is.
  Another side effect is that, if.
  - The log file has been backed up (ignored if circular logging is enabled).
  - The log file generation sequence is below the log file checkpoint for the storage group.
  - The passive copy of the storage group is in a state that allows the log file to be truncated (in other words, the passive copy must have replayed the log file).
  In addition, if the LCR or CCR environment is a source for an SCR target, the following additional condition must be met.
  - All SCR targets have inspected the log file.
  In an SCR environment, if the following criteria are met, a log file will be truncated on an SCR target.
  - The log file generation sequence is below the log file checkpoint for the storage group.
  - The log file is older than ReplayLagTime + TruncationLagTime.
  - The log file must have been deleted on the source.
  Microsoft recommends using continuous replication for mailbox data availability over other replication solutions. Consider the following issues with respect to third-party replication solutions.
  - Because third-party replication solutions are not Exchange-aware, they do not know how to validate the data being copied at the application layer to ensure it is usable. In addition, because the solutions are not Exchange-aware, they can require more complex special steps to activate.
  - Third-party replication solutions must be synchronous in order to be supported by Exchange. Synchronous solutions require good latency between the active and passive copies.
  - Third-party replication solutions may maintain two copies that are not independent from each other. This means that corruption introduced in the many layers executing on the hardware (Exchange, the operating system, storage components, and so on) are replicated to the second copy, resulting in a very high Recovery Point Objective (RPO) because both copies end up with the corruption.
  By contrast, continuous replication offers the following solutions.
  - Continuous replication is integrated into Exchange Server providing a completely Exchange-aware copy with integrated cmdlets and processes to activate, manage, and monitor the copy. For example, when combining replication with clustering technology, CCR provides integrated server and data redundancy, providing automatic simultaneous server and data failover.
  - Uses asynchronous replication to ship closed transaction logs to the second copy, making it very efficient and resilient to latency issues.
  - Uses copies that are independent copies, so types of corruption that are replicated by third-party solutions are not replicated by continuous replication. For example, if a -1018 occurs on the active database, the passive copy will not suffer from the same corruption (assuming independent storage solutions).
  - The logs for database copies are independently validated before they are replayed into the database copy.
  - Activation of a database copy is relatively quick. For example, in a CCR environment, failover to the passive node with database copies is integrated into Exchange, and takes roughly two minutes.
  - For the LCR and CCR scenarios, when a lossy failure occurs, the only data that can be lost is data that does not go through a Hub Transport server. This small set of data only includes contacts, tasks, personal appointments, notes, and drafts. Anything that goes through Hub Transport is held in the transport dumpster for a configurable amount of time and resubmitted to the Mailbox server..
  - Extensible Storage Engine Architecture
  - Lost Log Resilience and Transaction Log Activity in Exchange 2007
  - Understanding Transaction Logging
  - Cluster Continuous Replication
  - Local Continuous Replication
  - Standby Continuous Replication
  - Exchange Server 2007 SP1 ESE Changes Part 1
  - Exchange Server 2007 SP1 ESE Changes Part 2