Exchange Server 软恢复和硬恢复介绍

ghosty

当使用Microsoft Exchange Server 2003的时候，必须注意recovery (恢复)和restore (还原)之间的区别。还原是指将数据库和日志文件还原到服务器上的动作，恢复是指重放事务日志到恢复过的数据库中的动作。 　　有两种形式的恢复：
　　软恢复 在当数据库意外停止后被重新加载时的日志重放过程，或当事务日志被重放到数据库的离线备份中。
　　硬恢复 事务日志重放过程发生在从在线备份恢复数据库后。
　　软恢复
　　在缺省的软恢复场景中，外部的事件意外终止了Exchange 服务器数据库，但是数据库和日志文件保持完好无损并仍在原来的位置。当数据库被重新加载的时候，Exchange阅读检查点文件，并开始重放被列在检查点日志中的事务日志。如果没有检查点文件存在的话，重放从存储组中事务日志文件夹中最老的可用日志文件开始。
　　Exchange 服务器将它们写到数据库中，完成那些日志文件中发现的还没有被写到数据库中的事务。Exchange 服务器从来不会将事务写进数据库文件中直到所有的操作组成的整体被安全放置到日志文件中。您不需要在数据库中物理地撤消或收回一个事务，当重放开始的时候如果所有的未提交的事务日志还在这时意外中止出现。
　　重要信息：软恢复过程的一个基本的假设是，由于故障或在故障之后，没有数据库或日志文件被管理员移动、删除或损坏。
　　如果您从重播序列中删除任何需要的事务日志，Exchange 服务器软恢复将立即失败。如果需要的日志丢失的话，您必须要么从旧的日志执行恢复，从数据库的备份(一个不需要那些日志副本)中还原，要么您必须使用Exchange 服务器数据库工具(Eseutil.exe)来修复这个数据库。
　　事务日志文件重播的一些基础规则
　　事务日志文件重播的一些基础规则有下面一些：
　　1. 您不能将日志文件从一个数据库重播到另一个数据库中。日志文件内部的操作是低级别的。您无法看到日志文件里面的东西像“传递邮件A到邮箱B”。日志文件操作的一个好的例子是“在数据库页面7890上写123字节的流到偏移量456字节”。
　　想像您要编辑一个文档给出一些指令，您的指令是“在第五页第四段的第三个句子中的第二个单词后插入 '将是或将不是'”。如果这些指令被应用到文档而不是您打算的地方，结果是将随机地损坏该文档。同样地，如果错误的日志文件被重播到一个Exchange 服务器数据库中，类似的结果将发生。Exchange 服务器因此必须有多个安全机制来阻止这样的损坏发生。如果您修复或整理Exchange 服务器数据库，以前和该数据库关联的事务日志不能在被重播到它里面。
　　如果您尝试重播日志在完全整理或修复之后，Exchange 服务器跳过这些不正确的事务日志。再一次考虑类似文档编辑。如果一个段被移动、编辑或删除由于指令被创建，应用过期的指令将具有毁坏性因为将它们变成了一个完全不同的文档。
　　2. 您不能重播日志文件除非所有未提交的日志文件从数据库上次运行的时候是可用的。您必须让所有的日志文件从检查点开始并且在那个时间数据库被备份。接着您才能从该点重播日志文件只要它们不存在中断的序列。如果中间或序列的开始有单个文件丢失的话，重播将停在那里。
　　3. 您不能重播日志文件如果数据库文件已经被移动到不同的文件路径(在Exchange 2000 Server SP2之前)。该限制不会应用如果您正在使用Exchange 2000 Server SP2 或后续版本，因为Eseutil.exe 处理重播即使路径已经发生更改。下面的部分将具体描述重播过程是如何工作的。
　　4. 您不能重播日志文件如果检查点指向了错误日志。Exchange 服务器对待检查点日志好象它是第一个可用日志并忽略所有旧的日志文件。如果您还原了数据库的旧文件备份，检查点将回到以前很远，Exchange 服务器尝试从一个很新的日志文件开始重播。您能够解决该问题通过删除检查点文件，这样强制Exchange 服务器扫描所有可用的日志文件。(如果您恢复一个在线备份，硬恢复将忽略检查点文件。)
　　5. 您不能重播日志文件如果存储组的任何数据库文件已经被删除。所有的以前正在运行的突然出现意外出现终止的数据库必须存在，这样才能保证软恢复成功。该限制能够被克服通过使用Eseutil.exe 来运行软恢复。
　　如果一个存储组中的其他数据库正在运行软恢复这时一个数据库丢失了，以后的日志重播将变的比较复杂。通过软恢复失败，Exchange 服务器给管理员一个机会来分析情况并决定是否不通过数据库来处理。
    高级软恢复场景
　　在大多数情况中，运行软恢复的最好的方法是在一个存储组中加载任何一个数据库。因为一个存储组中的所有数据库共享同一个日志文件流，软恢复发生在整个存储组级别而不是单个数据库级别。
　　在一些特定的环境中，使用Eseutil.exe运行软恢复有好处。下面的场景是最通用的实例。
　　1. 您想恢复一个丢失数据库的存储组。
　　2. 您想恢复一个“超出空间”的单独数据库而不影响其他的数据库或存储组的日志文件。
　　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来运行软恢复：
　　1. 如果您不指定任何文件路径在命令中，Eseutil.exe 使用您当前的命令行目录作为日志文件和检查点文件的缺省的目录。
　　2. 数据库文件不一定必须在日志文件路径中。日志文件记录数据库路径，因此Eseutil.exe 发现所有的数据库路径通过阅读日志文件。使用/D开关来覆盖存储在日志文件中的路径只有当您确定日志文件的路径是不正确的。
　　3. 如果检查点文件不与事务日志文件在相同的路径，所有被扫描的日志文件都要重播，而不是从检查点开始重播。您能够临时拷贝一个已经存在的检查点文件到日志文件路径。在软恢复完成之后，Exchange 不在使用检查点的副本在正常的数据库操作中。如果检查点文件中的信息是不正确的，软恢复将失败但是不会损害数据库。您能够尝试在恢复在删除检查点文件或找到正确的检查点文件。检查点文件对成功运行恢复来说不是最根本的，但它能够节省大量的时间如果您有大量的日志文件。

ghosty

如果您想开始恢复当一个数据库从存储组丢失，您能够使用下面的命令：
　　ESEUTIL /r Enn /i
　　/i 开关意味着忽略丢失的数据库。如果您使用该开关然后加载丢失的数据库，Exchange 服务器提示您创建一个新的数据库。如果您打算恢复旧数据库在一些点，您将不能重播新的数据到它里面。您现在有同一个逻辑数据库的两个单独的版本。
　　这种情况，存储组中一个数据库已经被一个空的数据库替换，是恢复存储组能够帮助的那种。您能够加载额外的数据库在恢复存储组中，并使用邮箱合并向导(ExMerge.exe)来增加一个数据库的内容到其他的数据库。
　　如果您想开始恢复“超出空间”来恢复一个数据库而不影响存储组中的其他数据库，您应该创建一个新的空文件夹并移动您想恢复的数据库文件，您想重播的事务日志，和检查点文件(如果需要)到该路径。该路径一定不能包含其他的数据库文件。
　　在您将数据库和日志一起隔离到一个文件夹，运行下面的命令从那个文件夹：
　　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 服务器和后续版本之间的唯一区别是恢复将在日志重播结束的时候失败而不是在开始的时候。
    硬恢复
　　硬恢复必须完成在从在线备份还原后。硬恢复是有点类似软恢复的日志重播过程，但是有一些重要的不同之处。在硬恢复中，这些不同包括：
　　1. Patch信息必须应用到数据库在日志文件重播期间。
　　2. 检查点文件被忽略。使用Restore.env 而不是检查点来决定恢复应该从哪个日志文件开始。
　　Exchange 服务器5.5 管理员可能比较熟悉过程注册表中的还原。Restore.env 替换了Exchange 2000 服务器中那个键的功能。您能够查看Restore.env 文件的内容通过运行Eseutil /cm 命令。
　　1. 如果数据库已经被还原到一个和以前备份时不同的路径，日志文件重播成功，忽略列在日志文件中的数据库路径。
　　2. 还原的事务日志文件在正常的事务日志文件夹restore. Log文件也有可能被重播之前先从管理员指定的临时文件夹重播。
　　3. 硬恢复不会失败如果存储组中的其他数据库丢失的话。
　　从在线备份集还原的数据库文件(.edb and .stm)被还原到指定的数据库正常路径。还原通过覆盖现有的数据库文件开始。如果有机会在将来您可能需要现有的数据库文件，您必须移动它们或备份它们在从在线备份还原之前。考虑在线备份的还原可能会因为其他原因而失败。即使在那时现有数据库文件不能启动，它们仍可能被修复，如果需要的话数据仍可以被利用。
　　当您开始在线备份还原时，Exchange 服务器提示您提供一个临时文件夹位置。备份程序还原事务日志从备份集到该位置，而不是到正常的事务日志文件路径。备份程序也在临时文件夹中创建Restore.env 文件。
　　硬恢复中的Restore.env 的功能类似于软恢复中的检查点文件。Restore.env 定义应该出现在临时文件夹中用于硬恢复的事务日志文件的范围。如果您放置了额外的日志在临时文件夹-它们超出了Restore.env 中列出的范围-它们不会被重播并且恢复进程可能会自动删除它们。
　　您也许有不在在线备份集中的额外的日志文件要重播。在这种情况下，将这些日志放置到存储组的正常事务日志文件夹而不是临时文件夹。在硬恢复完成从备份集中重播日志还原之后，该进程检查正常的事务日志文件夹来看序列中的下一个日志是否可用。
　　注意：如果您还原到备用的服务器，或您已经删除并重新创建了原来的数据库，只有临时文件夹中的事务日志被重播。正常数据库文件夹中的事务日志不会被重播。该特征是避免事务日志重播引起冲突万一Exchange 服务器知道还原的数据库与备份的不同。在这种情况下还原的数据库称为“删除的”数据库。
　　您能够为删除的数据库播放额外的事务日志通过将它们放置到临时文件夹中。在这种特殊的情况中，恢复过程不会删除或忽略它们，而重播它们。如果您怀疑要还原的环境，将额外的事务日志的副本同时放置到临时文件夹和正常数据库文件夹中。不管数据库的删除状态，恢复过程将重播一个或其他日志集。当您还原到恢复存储组，重播一样生效就像您还原到源存储组。您能够放置额外的日志在恢复存储组数据库文件夹中，并且临时文件夹中的额外的日志将被忽略和删除。
　　例如，假设有6个日志文件，E0000003.log 到 E0000008.log，从备份中还原到临时文件夹。在这些日志文件已经被播放后，恢复现在检查运行日志文件夹的属于相同日志序列的E0000009.log 文件。日志文件中的内部标记验证它们为共同拥有。保持重播的决定只在日志文件名称的基础上不会被执行。
　　如果日志文件9找到的话，重播继续只要序列中的下一个日志是可用的。如果日志文件9不存在的话，恢复过程创建一个名称为E00.log的新日志文件在临时文件夹中。该日志文件只用于记录数据库中需要以一致状态关闭它的更改。在这点上，数据库被完全恢复。它自动重启，并将存储组中最新的日志文件附上。恢复过程接着删除临时目录中的所有文件。

转载自：http://windows.chinaitlab.com/Exchange/756262_1.html