Eseutil /R 恢复模式

  • 项目

 

上一次修改主题： 2006-06-09

恢复指的是将事务日志文件播放到数据库的过程。有两种类型的恢复：

  • 硬恢复：  从联机备份还原数据库之后发生的事务日志重播过程。
  • 软恢复：  在意外停止后重新装入数据库或将事务日志重播到数据库的脱机文件备份副本时发生的事务日志重播过程。

有关硬恢复和软恢复的详细信息，请参阅“事务日志文件重播：Exchange Server 2003 中的软恢复和硬恢复”(https://go.microsoft.com/fwlink/?linkid=68147)。

有关在恢复模式下运行 Eseutil 的说明的详细信息，请参阅如何在恢复模式下运行 Eseutil /R。

硬恢复

只有在必须将事务日志文件重播到已还原的联机备份时，才会执行硬恢复。在所有其他恢复方案中，将执行软恢复。硬恢复可以通过在还原模式 (/C) 下运行 Eseutil 来完成。

软恢复

在默认的软恢复方案中，外部事件意外停止了 Exchange 数据库，但数据库和日志文件仍保持原样并保留在原来位置。再次装入数据库时，Exchange 会读取检查点文件，并开始重播作为检查点日志列出的事务日志。如果不存在任何检查点文件，重播将从存储组事务日志文件夹中可用的最旧日志文件开始。

Exchange 将已完成的事务写入在日志文件中找到的尚未被写入的数据库文件，并撤消所有未完成的事务。除非与事务相关的所有操作都已记录到日志文件中，否则 Exchange 不会将事务写入数据库文件。如果在意外停止时存在的所有未提交事务日志在重播开始时仍然存在，则不必在数据库中物理撤消或停止事务。

important重要提示：
软恢复过程的一个基本假设是，没有任何数据库或日志文件由于故障被移动、删除或损坏，或者在发生故障后被管理员移动、删除或损坏。

版本差异

随着新版本的不断推出，Eseutil 始终在进行改进并增加新的功能。针对如下所示的 3 个主要 Exchange 版本中的每一个版本，当前有 3 个主要的 Eseutil /R 版本：

  • Exchange Server 版本 5.5
  • Exchange 2000 Server
  • Exchange Server 2003

Exchange Server 5.5

在 Microsoft® Exchange 2000 Server 和 Microsoft® Exchange Server 2003 中使用 Eseutil 执行软恢复的命令行语法与在 Exchange 5.5 中使用的命令行语法不同。使用 Eseutil 执行手动软恢复的规则和最佳实践也有所变化。

  • 在 Exchange 5.5 中，几乎从来没有使用 Eseutil 执行软恢复的必要。每次信息存储启动时，都会自动并正确地运行软恢复。在 Exchange 5.5 中，Eseutil 软恢复功能主要用于测试环境，在测试环境中，您可能希望在未安装 Exchange 的服务器上恢复数据库。
  • 在 Exchange 5.5 中运行 Eseutil /R 存在一个主要风险：在还原联机备份之后，运行软恢复通常会损坏数据库。联机备份需要硬恢复而不是软恢复。
  • 仅当同时满足以下两个条件时，在 Exchange 5.5 及以前版本中运行软恢复（而不是硬恢复）才是安全的：
    • 自备份完成后数据库路径未发生变化。
    • 联机备份集中的 .pat 文件大小正好是 8 K（这意味着它们仅由两个首页组成，其中没有任何实际的数据库页）。
      在所有其他环境中，运行软恢复（而不是硬恢复）都将损坏数据库，损坏程度与 .pat 文件大小成比例。
    note注意：
    如果将 .pat 文件的字节大小除以 4096，然后减去 2，得到的数字就是错误地运行软恢复后在数据库中将被逻辑损坏的页面数。

Exchange 2000 Server

在 Exchange 2000 中实施了相应的保护措施，可以始终避免在需要运行硬恢复时运行软恢复。

使用 Eseutil 运行软恢复还存在另一个风险。此风险在 Exchange 2000 或 Exchange 2003 中仍然存在：如果错误地指定了到日志文件、检查点文件或数据库文件的路径，则恢复可能会改变数据库或日志文件，并阻止再次执行恢复。

如果 Eseutil 在尝试运行恢复时找不到现有的事务日志文件，它将创建一个新的事务日志文件，并尝试将数据库附加到该文件。如果数据库“不一致”或处于“异常关闭”状态，数据库将变得不可启动。如果数据库处于“一致”状态，则会附加该数据库，然后将其从新日志文件中分离。

无论是哪一种情况，对数据库进行更改或将日志文件添加到服务器都存在风险，这将导致数据库变得不可启动，或者对进一步的恢复故障排除造成干扰。

note注意：
只是因为 Eseutil 恢复报告成功并不意味着恢复的数据库处于可装入状态。只要已将当前可用的所有可用事务日志数据应用到数据库文件，即成功完成恢复。恢复成功并不能表明可用数据是否足以将数据库还原为一致状态。

在 Exchange 5.5 中，将文件放在合适的位置，然后启动信息存储来完成恢复，这几乎始终是一种比较好的做法。在 Exchange 2003 中，Eseutil 恢复功能有两处改进，这使得 Eseutil 恢复方式明显优于那种装入数据库再运行恢复的方式：

  • 即使存在丢失的数据库，Eseutil 也可以强制完成恢复。在 Exchange 2000 中也提供此功能。

  • 如果存储组被意外停止，则此时运行的所有数据库都将变得“不一致”，并处于“异常关闭”状态。假定存储组停止的原因是数据库驱动器突然出现故障，并且无法访问该驱动器。在这种情况下，将丢失其中一个数据库。

  • 如果在数据库丢失时运行恢复，则可能会改变事务日志的状态，这样，当驱动器再次可以访问时，将无法成功恢复该数据库。

    note注意：
    如果从备份还原数据库，将能够成功完成恢复，这种情况仅适用于恢复在突然停止时被附加到当前日志的数据库。

  • 如果您知道丢失的数据库将无法恢复，则可以恢复存储组中其余的数据库，而不必先使用 Eseutil /I（忽略）开关从备份还原丢失的数据库。

在使用此开关对存储组的其余数据库运行恢复之前，应首先备份所有事务日志文件，包括当前日志 (Enn.log)。通过保留当前日志和所有其他日志的副本，在丢失的数据库突然变得可用时仍可恢复它。在恢复了其余数据库，并将更多信息写入 Enn.log 之后，将无法再使用该日志文件恢复丢失的数据库。

Exchange Server 2003

Eseutil 恢复可以恢复已被移动到不同路径位置的数据库。仅在 Exchange 2003 中提供此功能。

硬恢复始终能够成功完成，即使在备份完成后已将 Exchange 数据库移动到不同的路径位置。但在 Exchange 2003 之前，仅当数据库文件所在的驱动器路径与要重播的事务日志文件所定义的驱动器路径相同时，软恢复才能工作。

在 Exchange 2003 中，/D 开关被添加到恢复模式，以允许覆盖在事务日志文件中硬编码的数据库路径。将数据库的脱机副本还原到恢复存储组时，或者在恢复“丢失的”数据库（如上面的方案中所述）时，此新功能非常有用。

现在可以将数据库和一组事务日志复制到所需的任意文件夹中，并成功运行软恢复。数据库处于一致状态之后，即可将其移动到所需的任意其他路径中，并将其附加到不同的日志流。

详细信息

有关详细信息，请参阅 Exchange Server 数据库实用程序指南：