丢失日志回弹
在有损耗故障的情况下，数据库的源活动和新的活动副本之间有分歧有潜在的可能，要求源活动上的数据库执行完整的重新设定种子当它恢复的时候。一个名为丢失日志回弹的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
群集连续复制
考虑这样的一个CCR环境，NodeA 拥有群集邮箱服务器，NodeB 是被动节点。NodeA 产生和关闭日志文件，NodeB 拷贝关闭的日志文件并重播它们到数据库的被动副本中。
NodeA 产生日志并发送它们到NodeB
现在假设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上的复制服务接着判断分歧发生在什么地方。分歧检测逻辑相对比较简单。复制服务将它自己的最高日志和源上的最高日志做比较，并比较头来决定它们是否是同一个日志文件。如果它们是相同的，没有分歧发生。如果它们不是相同的日志文件，接着复制服务将继续比较日志文件直到它找到一个日志文件和源上的日志文件匹配，这被称为分歧点。