在默认软恢复情形中，外部事件意外地停止 Exchange 数据库，但数据库和日志文件保留完好并处于正确的位置。当再次装入数据库时，Exchange 读取检查点文件并开始重播作为检查点日志列出的事务日志。如果不存在检查点文件，重播开始时会使用存储组事务日志文件夹中最早的可用日志文件。

Exchange 将在日志文件中发现的没有写入的已完成事务写入数据库文件，并反转任何未完成事务。在撰写事务的所有操作被保护到日志文件之前，Exchange 从不会开始将事务写入数据库文件。如果在意外停止时存在的所有未提交的事务日志在重播开始时仍存在，不需要物理撤消或停止数据库中的事务。

重要信息：
软恢复过程的基本假定条件是数据库或日志文件未被移动或删除，也没有被故障所损害并且在发生故障后没有被管理员所损害。

如果从重播序列中删除了任何必需的事务日志，Exchange 会立即中止软恢复。如果所需的事务日志缺失，则必须使用更早的数据库（不要求这些日志）还原副本来执行恢复，或者使用 Exchange Server 数据库实用程序 (Eseutil.exe) 工具修复数据库。

事务日志文件重播的一些基本规则是：

• 不能将来自一个数据库的日志文件向不同数据库重播。   日志文件内部的操作是低级的。在日志文件内部看不到诸如“传递邮件 A 到邮箱 B”之类的说法。日志文件操作的一个更好示例是“将此 123 比特的数据流写入数据库 7890 页的字节偏移 456 处”。
  假设您向某人提供有关编辑文档的指令，而您的指令是“在第五页第四段第三句的第二个词后，插入短语‘生存还是死亡’”。如果将这些指令应用到非关联文档，其结果将是文档的无序损坏。同样，如果对某个 Exchange 数据库播放了错误的日志文件，也会出现类似结果。因此，Exchange 采取多个安全措施以防止此类损坏。
  如果对 Exchange 数据库执行了碎片整理或修复操作，就再也不能将以前与其相关联的事务日志重播到该数据库中。在碎片整理或修复后，如果尝试重播日志文件，Exchange 就会跳过不适当的事务日志。再一次考虑与编辑文档类比。在创建指令后，如果段落被移动、编辑或删除，那么应用这些过时指令与应用这些指令到完全不同的文档具有同样的破坏性。
  
• 除非从数据库上次运行时间之后所有的未提交日志文件都可用，否则无法重播日志文件。   必须具有从数据库备份时那个检查点开始的所有日志文件。只要日志文件遵循连续序列，就可以从该点重播它们。如果在序列中间或起始处缺少一个日志文件，重播就会在那停止。
  
• 如果已经将数据库文件移动到其他文件路径位置，将无法重播日志文件   如果使用 Exchange 2000 Server SP2 或更高版本，此限制将不再适用，因为 Eseutil.exe 能够在路径已更改的情况下处理重播。下面部分更详细地描述了重播进程如何工作。
  
• 如果检查点文件指向错误的日志，将无法重播日志文件   Exchange 会将检查点日志视为第一个可用日志，并忽略所有更早的日志文件。如果还原更早的数据库文件副本，该检查点就过于超前，并且 Exchange 会尝试从很新的日志文件开始启动日志文件重播。可以通过删除检查点文件解决此问题，因为这会强制 Exchange 扫描所有可用日志。（如果恢复联机备份，硬恢复将忽略检查点文件。）
  
• 如果删除了任何存储组数据库文件，都将无法重播日志文件   意外停止时运行的所有数据库必须仍然存在，以便成功进行软恢复。通过使用 Eseutil.exe 来运行软恢复可以解决此限制。
  如果在一个数据库缺失时软恢复还对存储组中其他数据库运行，将来的日志文件重播情况可能会很复杂。如果软恢复失败，Exchange 会给管理员一个机会，以分析情况并决定是否在没有数据库的情况下继续运行。
  

高级软恢复方案

在大多数情况，运行软恢复的最佳方法是装入存储组中的任何数据库。因为存储组中的所有数据库共享多个日志文件的一个流，所以软恢复发生在整个存储组级别而不是单个数据库级别。

在某些特殊情况中，使用 Eseutil.exe 运行软恢复会有一些优势。最常见的情况是：

• 要恢复缺失一个数据库的存储组。
  
• 要在不影响其他数据库或存储组日志文件的情况下恢复单个“不在适当位置”的数据库。
  

Eseutil.exe 软恢复功能的完整语法，且列出了所有可能的开关，即是：

ESEUTIL /r enn /L[path to log files] /s[path to checkpoint file] /d[path to database file] /i

示例： ESEUTIL /r e01 /Lf:\mdbdata /sc:\exchsrvr\mdbdata /dg:\mdbdata /i

注意：
Eseutil.exe 命令行参数不区分大小写；之所以要在上述情况中混合使用大小写，是为了避免混淆“L”和“I”字符。

上面的示例说明了对存储组数据库的恢复，其中日志文件的前缀是 E01，日志文件位于 f:\mdbdata 目录，检查点文件位于 c:\exchsrvr\mdbdata 目录，数据库和流式文件位于 g:\mdbdata 目录，并且忽略了缺失的数据库（因为命令末尾使用了 /i 开关）。

运行软恢复所需的最短 Eseutil.exe 命令行是：

ESEUTIL /r Enn

仅在从设置为事务日志目录的提示符运行时该命令才有效。使用 Eseutil.exe 来运行软恢复时还应注意以下事项：

• 如果命令行上未指定任何文件路径，Eseutil.exe 使用当前命令提示符目录作为日志文件和检查点文件的默认目录。
  
• 数据库文件不必位于日志文件路径。日志文件记录了数据库路径，因此，Eseutil.exe 可以通过读取日志文件发现所有数据库路径。只有在确信日志文件中的路径不正确的情况下，才可以使用 /D 开关来覆盖存储在日志文件中的路径。
  
• 如果检查点文件与事务日志不存在于同一路径中，在重播期间将扫描所有日志文件而不会从检查点日志开始重播。可以将现有检查点文件临时复制到日志文件路径。软恢复完成后，Exchange 在正常数据库操作中将不再使用此检查点文件副本。
  如果检查点文件中的信息不正确，则软恢复会失败但不会损害数据库。在删除检查点文件或找到正确的文件后，可以尝试再次恢复。检查点文件对于成功恢复不是必需的，但如果日志文件数量很大，它可以节省大量时间。
  

如果要在存储组中的一个数据库缺失时开始恢复，请使用此命令：

ESEUTIL /r Enn /i

/i 开关意味着忽略缺失的数据库。如果使用此开关后装入缺失的数据库，Exchange 会提示您创建新数据库。如果想要还原某个时刻的旧数据库，将不能将新数据重播到其中。现在有了同一逻辑数据库的两个独立版本。

在这种情况下，存储组中的一个数据库已被一个空数据库替代，并且恢复存储组能够发挥作用。可以在恢复存储组中装入额外数据库，并使用 ExMerge 将一个数据库的内容添加到另一个数据库。

如果要在不影响存储组中其他数据库的情况下开始“不在适当位置”的恢复来恢复单个数据库，应该创建一个新的空文件夹，并将要恢复的数据库文件、要重播的事务日志和检查点文件（如果需要）移动到此路径。此路径必须不包含其他数据库文件。

一旦将数据库和日志一起隔离到一个文件夹，从该文件夹运行以下命令：

ESEUTIL /r Enn /i /d

通过使用 /d 开关而不指定路径，可以覆盖日志文件中设置的数据库路径。此外，因为在此文件夹中没有其它可用数据库，因此会通过此特定恢复进程隐藏服务器上的其他数据库。

如果不正确地使用 /d 参数，恢复过程可能影响服务器上的其他数据库。即使在最坏情况下，恢复过程都不会损害其他数据库。但是，在正在使用的数据库上，恢复可能失败。恢复操作甚至可能影响未来对其他数据库的日志文件重播功能。

注意：
在命令行变得更加复杂的同时，错误的可能性也会增加。一条通用的准则是：使用 Eseutil.exe 时，尽可能地减少命令行上的特定路径信息。在此情况下，更改到这些文件所在的目录，并将 \exchsrvr\bin 目录包含到系统路径中。

要运行软恢复，重播序列中最后一个日志文件必须命名为 Enn.log。如果最终日志文件已经关闭和编号，则必须在软恢复成功之前将日志重命名。此要求并不意味着当前 Enn.log 文件已损坏或破坏，可以忽略它并将序列 Enn.log 中的前一个日志重命名。在 Exchange 2000 中，数据库头中的 Logs Required 值列出了恢复所需的最低日志序列，它从检查点日志开始一直延续到当前日志。在 Exchange 的早期版本中，尽管不存在 Logs Required 值以实施当前的必需日志，但是如果没有找到所需的最后一个日志，恢复仍然会失败。Exchange 2000 和更高版本的唯一区别是恢复会在日志重播末尾失败，而不是在开头。

从联机备份还原后必须完成硬恢复。硬恢复是类似于软恢复的一种日志文件重播进程，但两者有一些重要差异。在硬恢复中：

• 在日志文件重播期间，修补程序信息必须应用到数据库。
  
• 忽略检查点文件。使用 Restore.env 而不是检查点文件来确定从哪个日志文件开始恢复。
  Exchange 5.5 管理员可能熟悉 Restore in Progress 注册表项。在 Exchange 2000 中，Restore.env 替代了此注册表项的功能。通过运行 Eseutil /cm 命令可以查看 Restore.env 文件的内容。
  
• 如果将数据库还原到不同于其备份时源路径的路径中，日志文件重播会忽略日志文件中列出的数据库路径并成功运行。
  
• 在还原之前，还原事务日志文件首先从管理员指定的临时文件夹重播。也可能重播来自正常事务日志文件夹的日志文件。
  
• 如果存储组中的其他数据库缺失，硬恢复不会失败。
  

从联机备份集还原的数据库文件（.edb 和 .stm）被还原到为数据库定义的正常路径。通过改写现有数据库文件开始还原。如果将来有可能需要现有数据库文件，则必须在从联机备份还原之前移走或者备份它们。需要考虑到联机备份还原可能因各种原因失败。即使现有数据库文件在此时无法启动，它们仍然可能是可以修复的，如果必要，仍然可以抢救数据。

在开始还原联机备份时，Exchange 会提示您提供一个临时文件夹位置。备份程序将事务日志文件从备份集中还原到此位置，而不是正常的事务日志文件路径。备份程序还会在临时文件夹中创建 Restore.env 文件。

硬恢复的 Restore.env 功能类似于软恢复中检查点文件的功能。Restore.env 为硬恢复定义了应存在于临时文件夹的事务日志文件的范围。如果将额外的日志（这些日志超出 Restore.env 列出的范围）放到临时文件夹，将无法重播这些日志，并且恢复过程可能自动删除它们。

您可能需要重播联机备份集以外的额外日志文件。在此情况下，将这些日志放置到存储组的正常事务日志文件夹，而不是临时文件夹。在硬恢复完成了对从备份集还原的日志重播后，此过程将检查正常事务日志文件夹以查看序列中的下一个日志是否可用。

注意：
如果正在还原到备用服务器，或者已删除并重新创建了原始数据库，则只有临时文件夹中的事务日志会被重播。正常数据库文件夹中的事务日志不会被重播。在 Exchange 知道正在还原的目标数据库与备份的源数据库不一致的情况下，这种区别会避免事务日志重播发生冲突。在这种情况中还原的数据库称为删除的数据库。

注意：
可以通过将删除的数据库的其他事务日志放置在临时文件夹中来播放它们。在此特殊情况下，恢复过程既不会删除也不会忽略它们，只是重播它们。如果不清楚还原的目标环境，可以将其它事务日志的副本同时放到临时文件夹和正常数据库文件夹。不管数据库的删除状态如何，恢复过程要么重播这个日志集，要么重播另一个日志集。还原到恢复存储组时，重播就会像还原到原始存储组一样工作。可以在恢复存储组数据库文件夹放置其他日志，位于临时文件夹的其他日志将被忽略并删除。

例如，假设将六个日志文件 E0000003.log 到 E0000008.log 从备份还原到临时文件夹。播放这些日志文件之后，恢复即会为属于同一日志序列的 E0000009.log 文件查找运行日志文件夹。日志文件中的内部标记会确定它们的共同归属。保留重播的决定不只建立在日志文件名称的基础上。

如果找到日志文件 9，只要系列中的下一个日志可用，重播就会继续。如果日志文件 9 不存在，恢复过程会在临时文件夹中创建名为 E00.log 的新日志文件。此日志文件仅用于记录数据库在一致状态下关闭所需的数据库更改。此时，数据库已完全恢复。它自动重新启动并附加到存储组中的最近日志文件中。然后恢复过程删除临时目录中所有的文件。