连续复制（也称为日志传送和重播）是Microsoft Exchange Server 2007 中的一个新技术。它创建和维护数据库备份来为邮箱数据库提供完全的高可用性和灾难恢复解决方案。随着Exchange Server 2007 Service Pack 1 (SP1)的发布，现在有三种形式的连续复制。
本地连续复制（LCR） LCR是单服务器解决方案，在与主动存储组所在的服务器相连接的另一个磁盘集上创建并维护存储组的副本。
群集连续复制（CCR）CCR是 一项高可用性功能，它为电子邮件服务和邮箱数据提供故障转移功能，通过群集技术使用连续复制来为服务器冗余提供数据冗余的一个备份。
备用连续复制 (SCR) SCR是一个灾难恢复功能，它通过连续复制来创建和维护存储组的多个备份。SCR 实现了高可用性（包含服务和数据可用性）与站点弹性的分离。例如，SCR 可以与 CCR 相结合，以在主数据中心本地复制存储组（使用 CCR 实现高可用性），并在辅助或备份数据中心远程复制存储组（使用 SCR 实现站点弹性）。辅助数据中心可以在 SCR 目标所在的故障转移群集中驻有一个被动节点。这种类型的群集称作备用群集，因为它并不包含任何群集邮箱服务器，但是可以在恢复方案中为其快速提供一个替代群集邮箱服务器。如果主数据中心发生故障或丢失数据，可以在备用群集上快速激活该备用群集中的 SCR 目标。
连续复制基础
连续复制利用Exchange 服务器数据库恢复支持，来提供异步更新一个邮箱数据库的一个或多个副本技术。每个邮箱服务器记录主动数据库生成的数据库更新，将它以日志的形式记录在连续的1MB的事务日志文件中。这些文件的集合被当作日志流。日志流被用来备份和服务器崩溃后恢复。
在连续复制中，日志流也被用来异步更新一个数据库的一个或多个副本。这是通过传送日志到包含主动存储组副本的位置，然后重播它们到数据库副本中。如果来自主动数据库的所有日志都被重播到数据库的副本中，那么这两个数据库是相同的。
连续复制在存储组级别上配置和管理。然而，因为连续复制要求一个存储组只能包含一个数据库，连续复制有效地运行在数据库级别上。
该文章将深入研究连续复制的内部原理，解释使用连续复制成为可能的邮箱服务器角色的关键组件。
用简单的话来说，连续复制执行下面这些步骤：
复制组件
代表日志生成、日志传送和日志重播活动的两个关键服务是：
1. Microsoft Exchange Information Store service 代表服务用户和应用请求，执行写前面的日志，通过Extensible Storage Engine (ESE) 更新数据库文件。
2. Microsoft Exchange Replication Service 代表日志传送和重播数据库副本上的日志。
Information Store 服务功能
当数据库中的数据被检索、插入或修改的时候，ESE执行下面的步骤：
1. 一个操作发生于数据库（一个客户端发送了一个新的邮件），请求更新的页面从数据库中读出并被放到ESE的缓存（假设该页面不在内存中），而日志缓冲器被通知，它在内存中记录这个操作。
2. 这些更改被数据库引擎记录下来，但是这些更改没有被立刻写到硬盘上的数据库文件中 。实际 上，这些更改保存在ESE的缓存中，它们被称为使用过的页面，因为它们还没有被提交到数据库文件。存储版本被用来跟踪这些更改，这样可以确保被隔离，并且保持一致性。
3. 当数据库页面发生更改，日志缓冲器被通知来提交更改，事务被记录在事务日志文件中，它也许要求或不要求关闭现有的Exx.log文件并开始生成一个新的日志。（注意ESE也代表关闭一个日志文件一旦它达到最大值（1MB）并开始生成一个新的。）
4. 最终使用过的数据库页面被写到硬盘上的数据库文件中。
5. 检查点被增加。
复制服务功能
当连续复制被激活后，Microsoft Exchange 复制服务 （简称复制服务）用来检测当现有日志文件被ESE关闭的时候，拷贝它，检查它，然后重播它到数据库副本中。该服务在缺省情况下被安装在所有的已经安装邮箱服务器角色的服务器上。
复制服务的可执行文件是Microsoft.Exchange.Cluster.ReplayService.exe，在缺省情况下它位于<安装路径>\bin。复制服务依赖于Microsoft Exchange Active Directory Topology Service 。复制服务能够被停止和启动使用服务控制台或命令行，它也能够被配置为自动启动万一失败或意外发生。
复制服务存储它自己的关于诊断信息在注册表中下面的位置：
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchange Repl\Diagnostics
注意：通过Exchange Management Shell（例如，Get-EventLogLevel -Identity "MSExchange Repl"或 Set-EventLogLevel -Identity "MSExchange Repl" -Level High），您能够查询或设置复制服务的当前的诊断级别。
复制服务组件
复制服务使用几个组件来提供活动存储组和活动存储组的一个或多个副本之间的连续复制。下面的组件参与了连续复制过程。
LogCopier 代表拷贝关闭的日志从源存储组到包含副本存储组的目的服务器上。这是一个异步的操作，复制服务连续监视源存储组的日志文件目录。它通过订阅Windows 文件系统通知事件来完成该监视。当源服务器上一个新的日志文件被关闭，触发一个事件来通知复制服务一个新的文件存在。LogCopier将接着拷贝该日志文件到目标服务器上的检查位置。
LogInspector 代表验证日志文件是有效的。它周期性地检查目的检查目录。如果发现一个日志文件损坏或不能被重播，复制服务将请求重新拷贝该文件。
LogReplayer 代表重播被检查过的日志文件到数据库副本中。
LogTruncater 代表删除那些已经被成功重播到数据库副本中的日志文件。这相当重要，因为通常在一次完整或增量备份后，位于检查点以下的日志文件将被删除因为包含在这些日志文件中的日志记录已经被写入到数据库中。当连续复制被使用的话，LogTruncator 只删除那些不需要用于恢复和重播的日志文件。任何主动副本上还没有被复制和重播到数据库副本的日志文件不会被主动副本的在线备份删除。
Incremental Reseeder 代表确保主动数据库和数据库副本没有分歧在执行一次数据库恢复之后，或在CCR环境中发生一次切换之后。
Seeder 代表创建存储组的基线内容用于启动重播过程。复制服务为新的存储组执行自动种子设定，也为包含所有可用日志（包括第一个日志文件，它包含了CreateDB记录）的任何已经存在的存储组自动设定种子。
Replay Manager 代表跟踪所有复制的实例。它根据需要创建和销毁实例，基于存储组的在线状态。复制实例的配置是静态的。因此，当一个复制实例配置被更改，该复制将被重启同时更新配置。此外，在关闭复制服务的期间，复制实例配置是不被保存的。结果是，每次复制服务启动的时候有一个空的复制实例列表。在启动期间，重播管理器发现那些目前在线的存储组，并创建一个运行的实例列表。
重播管理器周期性运行一个名称为configupdater的线程来扫描新配置的复制实例。configupdater 线程运行在复制服务进程中，对于LCR或CCR每隔30秒，对于SCR每隔3分钟。它将基于当前的数据库状态创建和销毁复制实例（不管数据库是否在线）。configupdater 线程使用下面这些算法：
因此，重播管理器总是拥有复制实例的动态列表。
复制服务配置信息
每个激活了LCR的存储组和数据库有msExchHasLocalCopy 属性。复制服务使用下面的算法来查找活动目录中复制信息。
a) 对msExchHasLocalCopy 设置为true的每个存储组，检索系统文件、日志文件和数据库文件的源和目的路径。
在一个CCR的环境中，复制服务执行下面的任务来检索群集邮箱服务器的配置。
1. 建立到群集数据库的连接。
2. 判断哪个节点拥有群集邮箱服务器。
3. 枚举源和目的节点上所有的存储组，用于复制的不同设置有下面这些：
a) 系统文件、日志文件和数据库文件的源和目的路径。
b) 返回存储组的最后的拥有者（假设该存储组以前已经被加载）。
c) 用于日志发送的网络共享。
d) AutoDatabaseMountDial 设置。
e) ForcedDatabaseMountAfter 设置。
f) 决定正确的日志发送网络路径。
4. 验证源节点上的配置和目的节点一样。
对于SCR环境，复制服务使用msExchStandbyCopyMachines 属性来识别哪个存储组激活和复制，然后它执行下面的任务：
1. 使用计算机名称来查找Exchange 服务器对象。如果没有服务器对象的话就返回。
2. 枚举这台Exchange 服务器上所有的存储组。对含有msExchStandbyCopyMachines 设置的每个存储组，执行下面的操作：
a) 为每个目的服务器检索ReplayLagTime 和TruncationLagTime 参数。
b) 检索系统文件、日志文件和数据库文件的源和目的路径。
复制服务通信协调
主动实例和被动实例之间的复制服务通信通过下面三种机制来实现：
日志文件 特定的信息，像备份状态和数据库头变化，被记录在主动实例的日志文件中，并被复制到副本，从而更新数据库副本。
群集数据库或注册表 在群集数据库（CCR）或注册表（LCR/SCR）中，复制服务基于每个存储组存储重播状态数据。被写到这些地方和从这些地方读取的数据是永久状态信息，例如：
在Exchange 2007的RTM版本中，注册表和群集数据库被用来存储运行时间状态（准确地说我们处于复制过程中）。然而，在SP1中这个发生了变化以便管理任务直接通过RPC和复制服务通信来获得该信息。运行时间状态数据仍被写到注册表和群集数据库，然而管理任务不在从这些地方读取这些数据。
存储过程 复制服务将生成RPC 调用给活动实例上的存储过程用于配合日志截断。
日志发送和重播
现在我们对涉及到的核心组件有一个基本的了解，我们能够讨论日志发送如何工作的。在日志文件能够被发送到被动副本之前，主动数据库副本必须先被设置种子。这能够通过几种方法来完成。
1. 自动种子设定 自动种子设定将在目标中产生存储组数据库的副本。自动种子设定要求 所有的日志文件包括被存储组创建的第一个日志文件（它包含了数据库创建日志记录）在源中可用。自动种子设定只发生在新建服务器、新建存储组和数据库期间。
2. 使用 Update-StorageGroupCopy cmdlet 设定种子 可以在 Exchange 命令行管理程序中使用 Update-StorageGroupCopy cmdlet 将存储组副本设定为种子。您也能够使用Exchange 管理控制台中的Update Storage Group Copy 向导来将存储组副本设定为种子。
3. 手动复制脱机数据库 此过程卸除数据库并将数据库文件复制到被动节点的相同位置。如果使用此方法，会出现服务中断，因为此过程需要卸除数据库。
第二个选择是利用流备份API来将数据库从主动位置拷贝到目标位置。
注意： 您能够根据需要手动抑制速度通过修改位于HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Exchange\Replay\Parameters 中ESE Read Hint Size (KB)键值。支持的值的范围从24K到 (200*1024) KB，缺省值为1024KB。如果您决定改变该值，您应该在模拟生产环境的实验环境中验证该更改，并通过更改该值调整测试直到您找到满足您的要求的一个设置。缺省的值将给您一个最好的吞吐量，如果您考虑更改该值，它将只能使拷贝的速度减少。
复制服务也确保所有相关的路径为日志检查目录、日志目录和检查点文件目录创建。
在CCR或SCR环境中，有两个复制服务参与了拷贝存储组数据。一个在源节点上；另外一个在被动节点或目标上。源节点上的服务代表创建只读隐藏共享为每个存储组的日志目录。共享有下面的结构：
共享名称: <存储组 GUID>$
文件夹路径: <drive>:\<存储组日志文件夹路径>
共享权限: <根域>\Exchange Servers – 读
文件夹权限: <根域>\Exchange Servers –读, <计算机>\Administrators – 完全控制, SYSTEM –完全控制
注意：尽管文件能够被列出和拷贝，当您通过Windows Explorer 来查看共享的时候，您将发现Exchange Servers security group 的'Read' 权限选项没有被选中。这是由于一个访问标记没有被设置。
取决于环境，SCR目标的服务将使用特定的名称空间连接。
· CCR被动节点上的复制服务始终连接到\\nodenameActive 去拉日志到被动节点。
· SCR目标上的复制服务，当连接到CCR源环境，连接到\\nodenameActive 去拉日志到SCR目标。
· SCR目标上的复制服务，当连接到SCC源环境，连接到\\CMSName 去拉日志到SCR目标。
· SCR目标上的复制服务，当连接到独立邮箱服务器，连接到\\ServerName 去拉日志到SCR目标。
每次复制服务启动，它将检查保证邮箱服务器上的每个存储组有日志文件夹被共享。当新的存储组被创建，一个共享被创建。如果共享存在的话，它们不会被重建。如果共享上的权限被修改，复制服务将不会重新应用权限。对于这种情况，只要简单地删除共享然后回收源节点上的复制服务来重建它。
目标上的复制服务使用文件系统通知来检测新的日志文件当它们被关闭的时候。下面的步骤解释复制服务如何处理日志拷贝、检查和重播。对于这些步骤中的每一个，对应的标志被被目标节点上的复制服务更新和维护。这些被复制服务使用的标志用来跟踪它在日志复制过程（存储在群集数据库中，可以通过Get-StorageGroupCopyStatus和目标节点上的性能监视器来得到）中的位置。
注意：在LCR和CCR之间有两个关键的不同。首先，在LCR中只有一个单一的复制服务，由于LCR是单服务器解决方案。第二，LCR不会用到文件共享。实际上，复制服务简单使用文件系统通知来检测新的日志文件然后拷贝日志到被动实例位置。
1. 源日志目录中的一个日志文件被关闭。在源目录中看到的LastLogCopyNotified被最后生成的日志更新。
注意：存储过程每隔20秒更新群集数据库（或注册表）中的LastLogGenerated 字段。目标上的复制服务也观察日志更改通知，并更新它自己的反映在状态中的内部计数器。 作为结果，如果目标上的复制服务没有运行的话，接着LastLogGenerated 值将会被用作标记，它在20秒后过期。
2. 目标节点的复制服务在管理代码级别(LogCopier) 利用一个进程来拉日志文件到目的节点通过服务器消息块（SMB）。拷贝的日志文件接着被放置到位于存储组的日志文件中的检查目录。日志被放置到检查目录以便它们被隔离，同时不会因为意外重播到副本数据库中直到它们已经完成了检查。LastLogCopied 被更新当一个日志被成功拷贝到检查目录。
3. 日志文件通过LogInspector 被检查并被移动到被动日志目录。LastLogInspected 被更新当一个日志被成功检查。
a) 如果日志拷贝或日志检查失败，复制服务将企图重新拷贝日志文件并重新检查。复制服务在标记日志文件为不可恢复之前将执行三次，并要求数据库重新设定种子。
4. 日志文件被复制服务（LogReplayer）重播到数据库副本。LastLogReplayed 被更新当一个日志文件被成功地重播到数据库中。
注意：在RTM中，LCR利用一个计量器逻辑用于日志重播。在缺省情况下，日志重播队列组间隔设置为10。这是一次重播最小数量的日志数。如果在日志重播计量器期间（缺省60秒）没有日志收到，接着一个更小的队列被使用。该逻辑在SP1中已经被删除，由于结构更改保持被动数据库实例在日志反复重播之间被及时更新，它减少了被动实例上的I/O负载，从RTM负载 2-3倍主动实例到0.5-1倍主动实例。
日志检查
下面的动作被LogInspector 执行：
1. 物理的完整性检查 该验证利用ESEUTIL /K 对日志文件，验证日志文件中的校验和记录与内存中生成的校验和匹配。
2. 头检查 复制服务验证日志文件头的下面这些方面：
a. 对正被讨论的存储组生成不高于最高生成记录。
b. 日志头中的生成记录匹配日志文件名称中的生成记录。
c. 记录中日志头中的日志文件签名匹配日志文件的。
3. 删除Exx.log 在检查过的日志文件能够被移动到日志文件夹之前，复制服务需要删除任何Exx.log 文件。这些日志被放置到日志目录的另外一个子目录ExxOutofDate 目录。Exx.log 文件将只存在于目标上如果它以前作为源运行。Exx.log 文件需要被移动在日志重播发生之前。因为它包含旧的数据，已经被相同一代的完整日志文件取代。如果关闭的日志文件不是现有的Exx.log 文件的超集，接着我们将必须执行一个增量或完整的重设种子。
日志重播
在日志文件被检查后，它们被放置到日志目录以便它们能够在数据库副本中重播。在复制服务重播日志文件之前，它执行一系列的验证测试。
1. 重新计算要求的日志以便重播能够成功。它验证被检查数据库头需要的最高和最低日志文件。
2. 决定日志目录中出现的最高的日志来保证日志文件存在。如果没有日志文件，那么重播将不能继续。
3. 将日志目录中出现的最高的日志和要求的最高日志文件做比较。只要出现的最高日志等于或高于要求的最高日志，重播能够继续。
4. 确认日志组成了正确的顺序。检查目录中的所有的日志文件是一个慢的过程，因此只有要求的日志被验证。这个被执行用来决定如果恢复立刻失败（假设如果恢复在生成N的时候失败，数据库头将要求生成N-1）。此外验证所有要求的日志文件是可用的，下面额外的验证步骤被执行：
a. 确保日志文件的产生匹配预期的顺序。
b. 确保日志文件的签名是正确的。
c. 确保日志文件的创建时间组成了一个含有以前日志文件的顺序。
5. 查询检查点文件，如果存在的话。
a. 如果检查点文件太高的话，通过定义一个高于要求的最低日志的日志，接着该检查点文件将被删除。
b. 如果检查点太低并指向一个不存在的文件，那么该检查点文件将被删除。
一旦验证检查完成 ，复制服务将重播日志。这实际上是一个特定的恢复模式，它不同于ESEUTIL /R 执行的重播。通常当ESEUTIL /R 执行的时候，它重播所有可用的日志文件包括Exx.log文件，这样保证所有的事务要么被提交到数据库要么被退回。然而，由于在连续复制中，复制引擎总是在一个日志文件的后面（主动Exx.log 文件），恢复的撤消阶段（这里没有提交的事务叫做退回）被跳过用于保证数据库分歧不会发生。
在日志文件被重播后，下面的额外步骤被执行：
1. 验证数据库头中请求的日志被更新。有几种情况数据库头不会更新在一次日志重播事件后。当重播的日志只包含终止和初始的记录将会发生。在这种情况下，毕竟，数据库应该处于一致性状态。
2. 执行LogTruncater 阶段从被动和主动路径删除不需要的日志。这个调用读取完整和增量备份的数据库头信息，因此在这个期间重播被锁定。
计划中断
在计划中断期间，主动存储组实例以干净的方式卸载，被动实例被激活并成为新的活动存储组。在这种情况下，没有数据丢失会发生。当主动存储组被离线，打开的日志文件被关闭。复制服务拷贝任何剩余的还没有被拷贝的日志，它包含最高的生成的日志（打开的Exx.log 文件之前已经被关闭）对每个存储组。每个存储组的日志被检查，接着重播到对应的数据库副本中。数据库副本接着被激活，这样包含了和源一样的数据。
未计划中断
由于连续复制涉及发送关闭的日志文件，正在被ESE 写的活动的Exx.log 文件仍然被打开在发生故障的时候，不能被拷贝到被动节点。正如传输转储程序部分描述的这个打开的日志代表的数据大多数被中心传输服务器重新提交在发生故障后。如果我们考虑群集环境，有多种不同的故障能够发生，像服务器硬件故障、存储硬件故障和操作系统故障，还可以列举一些。在未计划中断事件发生，它影响主动节点，被动节点将使群集邮箱服务器实例上线，那个节点上的复制服务将尝试从遇到故障的节点拷贝丢失的日志文件。如果该拷贝过程成功了（例如，因为服务器是在线的，共享和必须的数据都可访问），接着存储将加载，不会有数据丢失。如果拷贝过程不成功，接着数据库将根据群集邮箱服务器的AutoDatabaseMountDial 设置来加载，对于每个存储组的日志复制在它之后有多少日志。对于服务器设置AutoDatabaseMountDial有三种可能的值：
a. Lossless Lossless表示丢失的日志数为零。该属性设置为"Lossless"时，大多数情况下，系统将等到故障节点重新联机后再装入数据库。尽管那样，故障的系统返回时其所有日志也都必须可访问并且未损坏。发生故障之后，被动节点会成为主动节点，并使 Microsoft Exchange Information Store 服务联机。它将检查是否可装入数据库而不造成任何数据丢失。如果可以，则装入数据库。如果不能，则系统会定期尝试复制日志。如果服务器返回时其日志保持原样，则该尝试最终会成功，数据库将进行装入。如果服务器返回时其日志未保持原样，则其余日志将不可用，受影响的数据库将不会进行装入。在这种情况下，需要强制加载数据库这时日志会丢失。
b. Good availability Good availability表示丢失三个日志。"Good availability"可在复制正在正常进行并以生成日志的速率复制日志时，提供完全自动的恢复。
c. Best availability Best availability表示丢失六个日志。"Best availability"是默认设置，其运行方式类似于"Good availability"，但允许在复制出现稍长的延迟时进行自动恢复。这样，在故障转移之后，新的主动节点的状态可能会稍微落后于旧的主动节点的状态，因此增加了数据库出现分歧的可能性，这需要完全重新设定种子来更正。
丢失日志回弹
在有损耗故障的情况下，数据库的源活动和新的活动副本之间有分歧有潜在的可能，要求源活动上的数据库执行完整的重新设定种子当它恢复的时候。一个名为丢失日志回弹的ESE特性提供了数据库源副本的保护，为了让执行完整数据库重设种子的可能性最小化。
在有损耗的故障中，每个存储组至少有一个日志文件丢失（Exx.log），但是也可能有其他关闭的日志丢失。这意味着如果数据库被加载上线，存储在NodeA（故障节点）上的数据和NodeB 上生成的数据不同。这个叫做分歧。
当存储组副本拥有的信息不在主动存储组中这叫分歧。分歧能够在数据库中或日志文件中。有损耗故障能够引起分歧，例如，管理员也能够引起分歧（通过执行离线整理或主动副本的硬修复）。
分歧是有问题的，因为它意味着数据已经丢失。数据库分歧是最坏的情形，因为它担保需要重新设定种子，在时间和可能的带宽方面它是一个昂贵的操作。日志文件分歧也意味着数据已经丢失。然而，日志文件分歧不一定会引起数据库分歧因为LLR。
记住Exchange 数据的写操作总是内存、日志文件然后是数据库文件。LLR通过推迟写到数据库直到特定数量的日志生成已经被创建生效。LLR将最近的更新推迟一个很短的时间才写到数据库文件中。写入延迟时间的长短取决于日志是多么快地被生成。
LLR提供强制数据库更改加载在内存中知道一个或更多其他的日志生成被创建的能力。简言之，它强制主动数据库文件在被创建的日志后面保留很少量的日志，这样减少了副本之间的数据库分歧的可能性，
注意：LLR只运行在主动存储组副本上。如果您分析被动副本，您将发现它的数据库总是最新的（根据被动节点上存在的日志文件）
LLR为日志文件使用一个新的标记。从日志重播角度出发，有两个关键的标记。
Committed 这个标记告诉ESE最后一个日志产生。该术语有点用词不当，因为它不意味着包含在日志文件中日的志记录实际上被写到数据库文件中。
Checkpoint 该标记告诉ESE对于重播来说要求的最小的日志文件数。检查点之前（下面）的所有日志文件包含的日志记录已经被写到数据库文件中。
Exchange 2007 为LLR和分歧检测增加了一个额外的标记。
Waypoint 该标记告诉ESE用于重播的要求的最大数量日志文件数。Waypoint 之前（下面）所有的日志都要求用于恢复因为这些日志中包含的数据已经被提交到数据库。Waypoint 之后（上面）所有日志都没有提交到数据库。
为了确保理解这些标记，让我们看一个没有干净关闭的数据库的输出的例子：
Initiating FILE DUMP mode...
Database: priv1.edb
...
State: Dirty Shutdown
Log Required: 2-12 (0x2-0xC)
Log Committed: 0-20 (0x0-0x14)
...
该EDB文件的输出告诉我们三个标记。
Committed是第20个日志（最后产生的一个日志列在“Log Committed”中）
Checkpoint是第二个日志（第一个产生的日志列在“Log Required”）
Waypoint 是第十二个日志（最后产生的日志列在“Log required”）
这意味着产生的第13个到第20个日志还没有提交到EDB文件。但是这究竟意味着什么？由于第13到20的日志还没有提交到数据库，它们能够被LLR丢弃。只要我们有第2个到12个日志，我们没有必要执行数据库重设种子。
LLR深度值取决于邮箱服务器配置。在运行SP1的CCR环境中，LLR深度值为10，它意味着在任何时间，最后10个日志文件中包含的数据还没有提交到数据库文件。对于所有其他的SP1邮箱服务器（SCC和独立邮箱服务器有LCR或没有），LLR深度值为1。
注意：在Exchange 2007 RTM版本中，CCR中的LLR深度值是不同的因为它取决于AutoDatabaseMountDial 设置，并等于AutoDatabaseMountDial+1。如果AutoDatabaseMountDial 设置为缺省的，在RTM版本中，CCR环境中LLR深度值为6+1 or 7。这意味着如果您在复制后面的七个日志文件之外，不但数据库不能在有损耗故障中加载，而且您也必须执行数据库重设种子。通过删除依赖于AutoDatabaseMountDial，在SP1中对于CCR来说LLR深度值为10，像数据库重设种子的可能性进一步减少，即使在数据库没有自动加载的情况下。
在没有用户或数据库活动的情况下，ESE也强制活动的日志文件关闭，这样确保如果该日志文件有数据的话，它将被复制到数据库的副本中。日志回滚行为基于LLR深度的基础。在系统经过一个计算的空闲时间之后日志回滚将发生。要计算什么时候日志回滚发生，系统使用下面的公式：
[15 (分钟) ÷ LLR 深度值] = 日志回滚活动的频率 (分钟)
下面的表格列出了为日志回滚动作的结果，一个空闲存储组每天生成的最大数量的事务日志文件
由于日志回滚动作每天生成的最大数量的事务日志文件
|
邮箱服务器配置 |
一个空闲存储组每天生成的最大数量的事务日志文件 |
|
独立 (有或没有LCR) 单个副本群集 |
96 |
|
群集连续复制 |
960 |
考虑这样的一个CCR环境，NodeA 拥有群集邮箱服务器，NodeB 是被动节点。NodeA 产生和关闭日志文件，NodeB 拷贝关闭的日志文件并重播它们到数据库的被动副本中。
NodeA 产生日志并发送它们到NodeB
如图1所示。
现在假设NodeA 出现故障，在上面的图中，我们看到NodeA 创建了第4个日志，并正在生成第五个日志文件对于存储组1来说，但是这两个日志在NodeA 发生故障之前都没有拷贝到NodeB。
NodeA 发生故障，NodB作为新的活动节点开始生成日志文件，从第4个日志开始。如图2所示：
作为故障的结果，在NodeB上将发生下面的事情：
1. 复制服务将企图从NodeA拷贝丢失的日志来阻止存储组的有损耗激活。
2. 如果拷贝企图失败，复制服务将计算日志丢失通过从LastLogGenerated 减去LastLogInspected 为每个存储组，并将该值和群集邮箱服务器的AutoDatabaseMountDial 值做比较。如果结果小于AutoDatabaseMountDial 值，那么存储组将加载。如果结果大于AutoDatabaseMountDial 值，那么存储组将不加载。
注意：根据丢失的日志如果数据库在AutoDatabaseMountDial 值之外，它们将不会自动加载。在这种情况下，复制服务将每隔30秒钟尝试联系被动节点（发生故障的原来的主动节点）来拷贝丢失日志文件。如果它能够拷贝足够多的日志文件来减少损耗到一个可接受的值，那么数据库将被加载上线。另外，有一个选项可以指定强制加载数据库的一个时间，通过设置ForcedDatabaseMountAfter ，然而，使用该特性要多加小心因为它能引起数据分歧。
对于加载的每个存储组，复制服务将初识化一个传输转储程序重新传递请求，用来恢复在故障之前即刻被提交到群集邮箱服务器的消息。我们将在传输转储程序中详细讲述这个。
也要注意存储组1被加载到NodeB上的结果，存储组将生成日志文件并将继续产生日志流，从第4个日志开始。可以从上述的图中看出，存储组1生成第4个到第6个日志文件。当NodeA返回，Exchange 如何处理已经存在于NodeA 和NodeB上的日志流，这部分将在增加的重设种子部分讨论。
传输转储程序
传输转储程序是Exchange 2007 内置的一个特性，设计用来减少数据丢失通过重新传递最近提交给邮箱服务器的邮件在一个有损耗故障之后。
如果我们返回到我们的NodeA/NodeB环境中，日志1、2和3已经被提交到NodeA上的数据库中。这些日志已经被复制到NodeB并且它们已经被重播到它自己的数据库。接着，NodeA 发生故障，日志4和5没有被复制到NodeB。NodeB接管了群集邮箱服务器，将存储组加载上线并初始化这部分讨论的传输转储程序重新传递进程。NodeA上生成的日志4和5，没有复制到NodeB可能包含实际的数据。例如，他们可能包含下面的信息：
1. 数据提交到传输服务器 (邮件或会议邀请)
2. 非传输相关的用户数据 (日历条目、联系人、任务、便签、草稿、属性更新等)
3. 数据库维护记录 (在线维护)
4. 日志回滚
现在我们将重点集中在第一个关键点。在Exchange 2007中，所有的邮件都必须经过中心传输服务器。这主要是为了满足遵从性（规定和要求），但是也提供了数据恢复的方法。
在Exchange 2007中，不管什么时候一个中心传输服务器接收到一个邮件，它要经过分类。分类进程的一部分涉及到查询活动目录来决定包含收件人邮箱的目的存储组是否启用了LCR或CCR。一旦邮件被传递到所有的收件人，该邮件被提交到中心传输服务器上mail.que 文件，并存储在mail.que 文件中的传输转储程序中。传输转储程序对于每个启用LCR或者CCR的活动目录站点中的每个存储组是可用的。有两个设置可以定义传输转储程序中邮件的周期。它们是：
1. MaxDumpsterSizePerStorageGroup 定义中心传输服务器上每个存储组可用的大小。建议是设置为平均邮件大小的1.5倍。缺省值为18MB。
2. MaxDumpsterTime 定义消息保留在传输转储程序中的时间的长短如果转储程序限制还没有达到。缺省值为7天。
如果时间或大小限制达到的话，邮件将根据先进先出的规则从传输转储程序中删除。
当故障（非计划中断）发生的时候，复制服务将企图拷贝丢失的日志文件。如果拷贝企图失败，那么这就叫着有损耗故障转移，将执行下面的步骤。
注意：在RTM中，传输转储程序只对CCR可用。在SP1中，传输转储程序被扩展到LCR带有一些警告，下面会将讲述这些。
1. 如果数据库在AutoDatabaseMountDial 值的范围内，它们将自动加载。对于LCR，转储程序触发会初始化当Restore-StorageGroupCopy 被执行。
2. 通过设置DumpsterRedeliveryRequired 为true，复制服务将记录群集数据库中存储组要求的传输转储程序重新传递（或在LCR的情况下在注册表中）。
3. 复制服务将记录在群集邮箱服务器的活动目录站点的群集数据库中心传输服务器（或在LCR的情况下在注册表中）的DumpsterRedeliveryServers设置。
4. 复制服务将计算丢失的窗口。这是通过使用LastLogInspected 标记作为起始时间和当前时间作为终止时间。由于传输转储程序是基于邮件传递时间，我们慷慨地通过向后展开12个小时向前展开4个小时来填充丢失的窗口。起始时间记录在DumpsterRedeliveryStartTime终止时间记录在DumpsterRedeliveryEndTime中。
5. 复制服务生成一个RPC调用给列在DumpsterRedeliveryServers的中心传输服务器请求转储程序重新投递给对于特定的丢失时间窗口。如果中心传输服务器不可用，CCR将每隔30秒发送同样的请求直到配置的MaxDumpsterTime 达到。对于LCR，该请求只发送一次。
注意：在RTM中，重新投递请求是硬编码的，重试达到7天。SP1基于MaxDumpsterTime 的基础使它不同。
6. 中心传输服务器将回应第一个重新投递请求通过一个重试响应。
7. 中心传输服务器将重新传递它自己的传输转储程序中拥有的邮件在指定的时间窗口。一旦邮件被重新提交用于传递，该邮件将从传输转储程序中删除。
8. 复制服务生成一个RPC调用给列在DumpsterRedeliveryServers的中心传输服务器请求转储程序重新投递给对于特定的丢失时间窗口。
9. 已经成功重新传递转储程序邮件的中心传输服务器将通过一个成功的响应来回应重新传递请求。在这点复制服务将从DumpsterRedeliveryServers中删除这些中心传输服务器。
10. 该过程将继续直到要么所有的中心传输服务器已经重新传递邮件或MaxDumpsterTime 已经到达。再一次，在LCR环境中，请求只会发送一次，因此那些不可用的中心传输服务器在Restore-StorageGroupCopy 被执行的时候将从不会重新传递转储程序条目对于这个丢失的窗口。
注意：如果多个有损耗故障发生，新的丢失窗口被添加到前一个中。
在这点，有一个问题传递转储程序能够处理多少丢失的数据。让我们看一个例子。
考虑一个环境使用15MB的转储程序，活动目录站点中有8个中心传输服务器，每个邮箱生成20MB的流量10个小时，每个存储组有100个邮箱。
15MB * 8 = 120MB per storage group
[20MB / 10 hours] * 100 mailboxes/SG = 200MB message traffic in 1 hour
60 minutes * 120MB/200MB = 36 minutes worth of data
在36分钟里，服务器上的每个存储组生成120+ 日志。
其他的问题是传递转储程序是否在保证的时间窗口到来。如果您的组织中没有消息大小限制（如果您没有参照MaxDumpsterSizePerStorageGroup 的最佳设置为您的环境），一个18MB的邮件将清除其他的邮件对于指定的中心传输服务器上的指定存储组。
增量式重新设定种子
考虑前面的场景：NodeA 在关闭出去的第4个日志并开始记录第5个日志后意外中断，但第4个日志之前的日志都复制到NodeB。NodeB 接管了群集邮箱服务器，将存储组上线，初始化传递转储程序重新传递进程来恢复在故障期间已经提交给群集邮箱服务器邮件。此外，由于存储组在线，它服务请求并生成它自己的第4个和第5个日志文件。
最终，管理员修复NodeA 上的问题，并使它重新在线。NodeA 将和群集通信并知道NodeB 拥有群集邮箱服务器。NodeA上的复制服务接着判断分歧发生在什么地方。分歧检测逻辑相对比较简单。复制服务将它自己的最高日志和源上的最高日志做比较，并比较头来决定它们是否是同一个日志文件。如果它们是相同的，没有分歧发生。如果它们不是相同的日志文件，接着复制服务将继续比较日志文件直到它找到一个日志文件和源上的日志文件匹配，这被称为分歧点。
查找分歧点
如图3所示：
在我们的场景中，NodeA上的复制服务将比较第5个日志，发现它与NodeB 上的不匹配。接着它发现第4个日志是相同的，但是它将判断第3个日志是否匹配。
现在复制服务知道对于这个存储组来说分歧发生在哪个地方，我们需要决定任何纠正它。对NodeA 上的副本重设种子将纠正分歧。然而，这是很昂贵的对于大型数据库从网络的角度、存储I/0和吞吐量以及从SLA角度。为了减少执行数据库重设种子的需要，Exchange 团队集中在通用的案例：当一个有损耗故障发生的时候，每个存储组只有少量的日志文件被丢失，同时有故障的节点将很快被修复。
对于通用的案例来说该团队的Exchange 2007解决方案分两个部分：
1. 事务日志文件从5MB减少到1MB。日志大小的减少确保对于每个日志文件来说只有很少量的数据丢失。
2. LLR 被增加到ESE中。
如果分歧点大于或等于waypoint （意味着分歧的日志高于列在数据库头中的“Logs Required” 部分），那么日志文件会被丢弃由于日志分歧只在日志文件中不在数据库中。记住被丢弃的日志确实包含数据，那些数据可能会丢失在这种情况下。如果分歧点小于waypoint （意味着分歧的日志位于列在数据库头中的“Logs Required” 部分中），那么会发生数据库分歧并需要重设种子。
如果我们在回到我们的NodeA，NodeB场景中，日志1、2和3已经被提交到NodeA上的数据库。这些日志也已经被复制到NodeB，并已经被重播到它自己的数据库。接着，NodeA 发生故障，日志4和5都没有复制到NodeB。NodeB接管了群集邮箱服务器，并将存储组加载上线，开始生成它自己的日志4和5，除了生成日志6以外。NodeA 重新上线，它自己的复制检查了分歧发生在第4个日志文件。NodeA上的复制服务咨询数据库头并判断日志4和5不在需要，它丢弃它们因为它们高于waypoint 标记。如果我们检查数据库头的话，我们将看到下面这些：
Initiating FILE DUMP mode...
Database: priv1.edb
...
State: Dirty Shutdown
Log Required: 2-3 (0x2-0x3)
Log Committed: 0-5 (0x0-0x5)
...
1. 提交的是第5个日志 (最后生成的日志列在 “Log Committed”).
2. 检查点是第2个日志 (第一个生成的日志列在 “Log Required”).
3. Waypoint 是第3个日志 （最后一个生成的日志列在 “Log required”).
4. 第4个和第5个日志在waypoint 之外。
复制服务接着从NodeB（参考日志发送和重播部分）拷贝新的日志文件（第4个和第5个）并将它自己的数据库副本更新到最新。
复制服务检查分歧点、删除对于数据库重播来说不需要的日志、并从主动实例拷贝需要的日志文件的过程被称为增量式重新设定种子。
数据库重新设定种子场景
在讨论哪些场景要求数据库重新设定种子之前，注意下面的场景不需要数据库重新设定种子。
1. 在计划中断场景中，主动日志文件被关闭所有要求的日志文件被发送到目标数据库副本确保副本激活是无损耗的。
2. 非计划中断，日志发送是健康的同时与主动节点上的日志生成是一致的，数据库副本没有产生分歧。这种情况能够被纠正通过增量式重新设定种子作为LLR 的结果强制数据库落后以更新的日志流能够刚好被应用和向前回滚。对于利用连续复制的环境来说，确保日志发送是健康的是很关键的。
3. 网络中断不需要数据库重新设定种子只要源节点上的日志流没有被截断。日志截断不会自动发生当连续复制处于不健康的状态或其他不可操作的状态。
4. 有多个群集复制主机名称被定义的网络中断不需要数据库重新设定种子，因为在定义的网络中将发生自动切换，这样会确保日志流被成功地拷贝到被动节点。
下面的场景需要重新设定种子：
1. 管理员执行脱机维护 (ESEUTIL 碎片整理, ISINTEG, ESEUTIL 硬修复) 对生产数据库。脱机维护操作像脱机碎片整理更改了数据库的结构并且这些更改不会被记录，因此，数据库需要重新设定种子。
2. 日志流中的一个日志文件损坏或被意外删除在它被拷贝到被动节点之前。在这种情况下，为副本传递该日志的唯一的方法就是执行数据库重新设定种子。
3. 数据库副本产生显著的分歧的时候发生切换。对于这种情况，数据库必须被加载上线要么通过管理员手动设置要么通过设置ForcedDatabaseMountAfter 值在群集邮箱服务器上。回忆当有损耗切换发生的时候，复制服务计算损失根据日志文件和将它和AutoDatabaseMountDial 值做比较。如果这个损失大于LLR 深度，那么节点之间的数据库分歧已经发生，并且这只能通过执行数据库重新设定种子来纠正。
4. CCR安装会自动指派群集邮箱服务器的拥有者对于主动和被动节点来说。然而，如果被动节点发生故障或其他原因不可用，被动节点能够从群集邮箱服务器的RedundantMachines 列表中删除来允许主动实例上的日志截断发生。然而，一旦被动节点被修复或重新加载上线，并被添加到RedundantMachines 列表，被动节点上的数据库将需要重新设定种子因为在日志序列中有一个间隙。
5. 使用 Failover Cluster Management 工具、 Cluster Administrator或 Cluster.exe 来管理CCR环境中的储存组资源能导致数据库分歧。Cluster Administrator 不包含在有损耗故障期间Exchange cmdlets 必须阻止和警告管理员注意的数据库分歧问题的任何逻辑。
6. 在RTM中，如果您启用页面清零功能，这只在联机流备份期间执行。作为结果，页面清零是不会记录操作，因此您将必须执行数据库重新设定种子来传播这些更改。这个问题在SP1中已经被纠正，通过允许页面清零成为联机维护任务的一个内置的选项。
备用连续复制
备用连续复制是一个灾难恢复特性它通过连续复制来创建和维护一个存储组的多个副本。它提供了管理站点弹性的功能。SCR利用与CCR和LCR一样的连续复制技术。下面是SCR和LCR或CCR几个关键的不同之处：
1. SCR目标上的有损耗激活将从不会调用传输转储程序。
2. LCR和CCR只支持1:1的复制模型。SCR支持多: 多（1:1、多:1和1:多）的复制模型。（一个源存储组能够被复制到多个SCR目标，尽管我们建议不要超过4个副本）
a) 当计划多:1的复制模型的时候，记住SCR有像CCR或LCR一样的相同路径要求。每个数据库必须被复制到对应的相同的驱动器和路径。当设计源服务器的时候，确保每个文件夹路径是唯一的。
3. 日志拷贝到SRC目标是连续的，然而SCR支持日志重播滞后和日志截断滞后。
a) 重播滞后被设计用来减少需要重设种子的机会当源也使用连续复制并且经历了有损耗故障。在缺省情况下，重播之后被设置为1天。
b) 截断滞后被设计以便目标上的日志能够从源上的损失中恢复。在缺省情况下，截断滞后被禁用。
c) 尽管有重播滞后选项存在，在恢复/激活期间，所有的日志文件都被重播（除非这些日志文件被手动从日志路径中删除）。
4. 对SCR目标初始化数据库重设种子不是立即发生的。在缺省情况下，数据库将不会被重设种子直到50个日志文件被复制后和重播滞后时间已经超过。然而，这个能够被覆盖通过执行Update-StorageGroupCopy 。
5. 没有Exchange 感知的备份机制来备份SCR目标存储组。那就是说，您能够挂起复制，然后对SCR目标上的数据库和日志文件执行平坦的文件备份。
6. 日志截断是SCR感知的。
连续复制和备份
使用连续复制的一个好处就是减少从活动存储组到被动存储组基于卷影复制服务的备份。在主动和被动存储组和数据库上Exchange 感知的VSS备份是支持的。微软提供的被动副本备份解决方法只是VSS。流备份只在主动存储组上被支持。您不能使用流备份API 来备份被动节点上的数据库。您也需要使用支持Exchange VSS的第三方备份应用程序，因为Windows Server 备份不是Exchange VSS感知的。
当您对被动副本执行VSS备份的时候，事务日志会发生什么情况呢？在Exchange 感知的备份期间一个通用的任务就是截断事务日志文件在备份被成功执行后。连续复制功能保证还没有复制的日志不会被删除。
在被动副本上执行备份的挑战是备份修改了数据库的头。例如，它们增加关于数据库上次备份的时间的信息。VSS备份通过复制服务中的Exchange Replica VSS Writer是可能的，复制服务有数据的副本，但是它只能得到它自己的数据和从存储中修改。它不能独立地修改数据库的副本，那将产生分歧。因此，它不能修改它自己数据库副本的头。
方法是让复制服务通过存储协调它自己的备份。只要您在被动节点上的开始备份，复制服务联系主动节点上存储并告诉它备份将要开始。通过执行它来阻止在主动和被动节点上相同的存储组被同时备份。一旦备份完成，复制服务将联系存储并告知备份已经完成。
从备份导致的数据库头修改接着在主动节点上的存储被修改。这个动作生成一个日志记录，它通过连续复制被拷贝到被动节点。当它被重播的时候，被动节点上的数据库头接着被更新。
这比传统的备份有疑点复杂，并且它还有一些有趣的影响。例如，如果您备份被动节点并在备份完成之后立即检查被动节点上的数据库，它将不会反映备份。然而主动节点上的数据库将反映它。
因此，如果您在连续复制的环境中备份数据库，判断上一次备份的最准确的方法是检查主动节点上的数据库。
另一个影响是，如果信息存储没有运行的话，您不能备份被动节点。运行信息存储是必须的以便备份能够被相互联系起来，并且数据库头能够被更新。
日志截断
日志截断如何发生，尤其当涉及到连续复制？在Exchange 中，信息存储服务有义务在主动数据库上截断日志文件要么通过ESE.DLL 要么通过ESEBACK.DLL 。使用哪个DLL取决于是否启用连续复制和是否启用循环日志。如果连续复制没有被启用，ESE.DLL有责任执行日志截断当循环日志被启用。否则，ESEBACK.DLL用于日志截断。
当连续复制被启用，ESE以“不执行循环日志”标记被初始化，不管存储组的循环日志设定。执行这个是因为基于ESE的循环日志是不知道连续复制的。为了让连续复制生效，日志连续性是必须的。因此，日志不能被覆盖直到它们不在被复制引擎所需要了。然而，您
可以将循环日志记录和连续复制组合使用。在此配置中，将获得称为连续复制循环日志记录 (CRCL) 的新型循环日志记录，它不同于 ESE 循环日志记录。ESE 循环日志记录由 Microsoft Exchange Information Store 服务执行和管理，而 CRCL 由 Microsoft Exchange 复制服务执行和管理。
复制服务（目的节点上如果CCR或SCR部署的话）和信息存储服务通过RPC通信关于哪些日志文件能够被删除在源节点上，ESEBACK.DLL 接着执行日志截断。复制服务负责为数据库副本截断日志。
在LCR或CCR环境中，为了让日志能够被截断，下面的条件必须满足：
1. 日志文件已经被备份（如果循环日志被启用的话忽略）。
2. 日志文件生成序列位于存储组的检查点日志文件之下。
3. 存储组的被动副本允许日志文件被截断（换句话说，被动副本必须已经重播过这些日志文件）。
此外，如果LCR或CCR是SCR目标的源，下面的额外条件必须满足：
1. 所有的SCR目标已经检查过日志文件。
在SCR环境中，如果下面的条件满足的话，SCR目标上的日志文件将被截断。
a) 日志文件生成序列位于存储组的日志文件检查点之下。
b) 日志文件比 ReplayLagTime + TruncationLagTime 旧。
c) 日志文件必须在源上已经被删除。
注意：有一个已知的问题，日志截断不会发生在SCR目标上如果TruncationLagTime大于ReplayLagTime （即使TruncationLagTime过去之后）。这将影响SCR目标机器的日志驱动器的容量分配。只有两种规避的方法。要么删除不需要的日志文件（这有一点复杂因为您必须确保它们在ReplayLagTime和 TruncationLagTime之外），要么确保TruncationLagTime小于ReplayLagTime（或禁用它）。为了改变这两个参数中的任何一个您需要先禁用SCR然后接着重新启用它使用新的值。该问题期望在将来的SP1的汇总更新中被修复。
将连续复制和其他复制方法做比较
微软建议为邮箱数据库可用性使用连续复制而不是其他的复制方法。对于第三芳复制方法要仔细考虑下面这些问题。
1. 因为第三方复制方法不是Exchange 感知的，它们不知道如何在应用层去验证被拷贝的数据来确保它们是可用的。此外，因为该方法不是Exchange 感知的，它们要求更复杂的特别的步骤来激活。
2. 为了被Exchange 支持第三方复制方法必须是同步的。同步方案要求活动和被动副本之间有好的延迟。
3. 第三方复制方法也许要维护两个并不是相互独立的副本。这意味着在硬件（Exchange 、操作系统、存储组件等）上执行的许多层中有一层出现损坏的话将被复制到第二个副本中，导致很高的恢复点目标（RPO）因为两个副本最终都损坏了。
通过对比，连续复制提供了下面这些方案。
1. 连续复制被集成到Exchange 服务器中提供了一个完整的Exchange 感知的副本通过集成的cmdlets和过程来激活、管理和监视副本。例如，当将复制和群集技术结合起来，CCR提供了集成的服务器和数据冗余，提供了自动服务器和数据同时切换。
2. 使用异步复制来发送关闭的事务日志到第二个副本，使它非常有效率同时对延迟问题有很好地弹性。
3. 使用的是相互独立的副本，因此像第三方解决方法复制的故障问题不会被连续复制复制。例如，如果主动数据库上产生-1018错误，被动副本将不会遇到相同的问题（假设独立的存储解决方案）。
4. 数据库副本的日志被单独验证在它们被重播到数据库副本中之前。
5. 数据库副本的激活是相当地快。例如，在CCR环境中，数据库副本切换到被动节点被集成到Exchange 中，大约只要花两分钟。
6. 对于LCR和CCR场景来说，当发生有损耗故障，唯一丢失能够被丢失的数据是没有经过中心传输服务器的数据。这些数据的小集合只包含联系人、任务、私人邀请、便签和草稿。任何已经经过中心传输的数据被保存在传输转储程序中以一段可配置的时间，并被重新提交到邮箱服务器。
结论
连续复制通过异步复制或日志发送维护数据的副本来为Exchange 2007 提供数据可用性。复制是基于ESE日志，关闭的日志文件被复制、验证然后接着被重播到数据库的副本中。
由于连续复制是异步日志复制模型，Exchange 2007 中的ESE被增强用于减少要求数据库重新设定种子的可能性在非计划中断事件中。丢失的日志弹回延迟提交更改到数据库直到一个或多个日志文件被复制后，因此减少了需要执行数据库重新设定种子的需要如果两个副本出现分歧。
此外，连续复制也通过传输转储程序来重新传递那些最近被提交给邮箱服务器在故障事件之前的邮件。这允许邮箱服务器恢复那些可能被记录但还没有复制到被动副本的电子邮件数据。
| 自由广告区 |
| 分类导航 |
| 邮件新闻资讯: IT业界 | 邮件服务器 | 邮件趣闻 | 移动电邮 电子邮箱 | 反垃圾邮件|邮件客户端|网络安全 行业数据 | 邮件人物 | 网站公告 | 行业法规 网络技术: 邮件原理 | 网络协议 | 网络管理 | 传输介质 线路接入 | 路由接口 | 邮件存储 | 华为3Com CISCO技术 | 网络与服务器硬件 操作系统: Windows 9X | Linux&Uinx | Windows NT Windows Vista | FreeBSD | 其它操作系统 邮件服务器: 程序与开发 | Exchange | Qmail | Postfix Sendmail | MDaemon | Domino | Foxmail KerioMail | JavaMail | Winwebmail |James Merak&VisNetic | CMailServer | WinMail 金笛邮件系统 | 其它 | 反垃圾邮件: 综述| 客户端反垃圾邮件|服务器端反垃圾邮件 邮件客户端软件: Outlook | Foxmail | DreamMail| KooMail The bat | 雷鸟 | Eudora |Becky! |Pegasus IncrediMail |其它 电子邮箱: 个人邮箱 | 企业邮箱 |Gmail 移动电子邮件:服务器 | 客户端 | 技术前沿 邮件网络安全: 软件漏洞 | 安全知识 | 病毒公告 |防火墙 攻防技术 | 病毒查杀| ISA | 数字签名 邮件营销: Email营销 | 网络营销 | 营销技巧 |营销案例 邮件人才:招聘 | 职场 | 培训 | 指南 | 职场 解决方案: 邮件系统|反垃圾邮件 |安全 |移动电邮 |招标 产品评测: 邮件系统 |反垃圾邮件 |邮箱 |安全 |客户端 |