一. Exchange的备份与恢复概谈
Exchange备份分为联机备份和脱机备份两种。顾名思义，当运行exchange时执行的备份为联机备份，这类备份往往需要支持exchange的程序来完成，如NTBACKUP以及第三方备份软件针对exchange的数据库提供的解决方案。这类程序按逻辑备份数据，也就是说，备份所有与信息存储相关的数据和所有与目录服务相关的数据。脱机备份则是在服务停止时执行的文件级的备份。
联机备份
Exchange 支持四种类型的联机备份：常规或完全、复制、增量和差异。常规备份先备份您的数据库文件，然后备份事务日志文件，之后再从目录中删除事务日志文件。这意味着您可禁用循环日志记录，因为您的备份软件会删除日志文件。因此如果执行常规备份，您就不会遇到日志文件充满驱动器的问题。要还原常规备份，只需要还原上次常规备份集并启动该服务即可。
增量备份只作用于日志文件，因此仅适用于禁用循环日志记录的情况。象常规备份一样，增量备份也会在备份后将日志文件清除。因此，它提供了在不损害可恢复性的情况下去掉日志文件的另一种方法。要还原增量备份，必须返回到上次常规备份集（其中包含您的数据库文件）。还原这些数据库文件，再还原常规备份后的每个增量备份集，然后启动该服务。请注意，只有当您还原所有的备份集之后，才能启动该服务，否则在备份集之后还原的任何日志都不能向前运行。
象增量备份一样，差异备份也作用于日志文件，因此若要使用它，就必须禁用循环日志记录。然而与增量备份不同的是，差异备份不删除日志文件。要还原差异备份集，请返回到上次常规备份并还原您的差异备份集（它包含上次常规备份后产生的所有日志文件）。使用增量备份时，只有当您还原了所有的备份集之后，才能启动该服务。
脱机备份，任何备份软件都可以执行脱机备份。不过，在还原时脱机备份不能象对应的联机备份一样自动放出所有日志文件。因此，Microsoft 不推荐使用脱机备份进行每日备份。但是，当联机备份失败后，脱机备份就非常重要。
恢复
恢复数据的方式取决于您是返回到联机备份还是返回到脱机备份，而还原联机备份比还原脱机备份要容易一些。在每日常规备份中，您只是简单地还原上次常规备份并启动该服务。在常规加增量备份中，您将还原上次常规备份和所有增量集并启动该服务，而 Exchange 会放出所有日志文件。在常规加差异备份中，您将还原上次常规备份，还原上次差异备份，并启动该服务。
在脱机备份中，您将执行还原目录服务的一个步骤和还原信息存储的另一个步骤。对于目录服务，应还原 DSADATA 目录，必要时使用 Windows NT 注册表在各个不同的驱动器上找到多个 DSADATA 目录。然后，启动该服务。对于信息存储，应还原 MDBDATA 目录（其位置也出现在注册表中），然后运行 Microsoft Exchange Server 下 bin 目录中的 ISINTEG.EXE 程序，并给此程序提供 -patch 命令行选项。然后，停止该服务，它自己应当再次启动。
二. 如何做
联机备份
要使用“备份向导”对 Exchange Server 计算机执行联机备份，单击开始，指向程序，指向附件，指向系统工具，然后单击备份。或者，在命令提示符处键入 ntbackup。
在“要备份的内容”对话框中，选择“备份选定的文件、驱动器或网络数据”，然后单击下一步。这将启动联机备份。
在“要备份的项目”对话框中，展开 Exchange Server 树，选择单位中要备份的任何或所有 Exchange Server 计算机，然后单击下一步。
备注：您不能选择词语“Microsoft Exchange”旁边变灰的框。必须双击 Microsoft Exchange 或单击加号 (+) 展开 Exchange Server 树。您可以将此树向下展开到任何服务器的目录或信息存储区。确认“备份媒体或文件名”框中列出的文件是您要将数据备份到的文件，然后单击下一步。 单击完成继续进行备份。
要不使用向导备份 Exchange Server 计算机，请按照以下步骤操作：
单击开始，指向程序，指向附件，指向系统工具，然后单击备份。或者，在命令提示符处键入 ntbackup。
在“欢迎使用 Windows 2000 备份及故障恢复工具”对话框中，单击备份选项卡，然后展开 Microsoft Exchange 树。选择单位中要备份的任何或所有 Exchange Server 计算机。备注：您无法选择词语“Microsoft Exchange”旁边变灰的框。您必须双击 Microsoft Exchange 或单击加号 (+) 展开 Exchange Server 树。您可以将此树向下展开到任何服务器的目录或信息存储区。
确认“备份媒体或文件名”框中列出的文件是您要将数据备份到的文件，然后单击开始备份。 验证备份作业信息对话框中的信息，然后单击开始备份.
脱机备份与恢复
检查工作:
确定是否为存储组启用循环日志(不要启用）。(exchange系统管理器存储组-属性-通用，不钩选启用循环日志。)
确定 Exchange 数据库、流、事务日志和检查点文件的路径位置以及存储组的日志文件前缀。(exchange系统管理器存储组-属性-通用,记录日志文件前缀（E0n）,事务日志位置 (E0n*.log)系统路径位置 (E0n.chk), 数据库路径列在每个 database_name 对象的 Database 属性中,*.stm,*.edb)Dismount 要备份的数据库。
脱机备份
1. 验证验证数据库文件（.edb 和 .stm 文件）一致且相互匹配。为此，请对每个文件运行以下命令
eseutil /mh database（*.edb） file | find /i "DB Signature"
eseutil /mh database file (*.stm)| find /i "DB Signature"
若两个文件DB签名相同，则说明属于同一文件集。
eseutil /mh database file ,state=clean shutdown
2. 将*.edb,*.stm文件备份。
3. 装入已备份的数据库。
4. 若稍后要钱滚，则备份所有带编号的事务日志文件（E0nxxxxx.log 文件）。不要备份 E0n.log、Res1.log 和 Res2.log 文件。
5. 查看检查点文件的标头，以确定可以安全删除的编号最大的日志文件。如果数据库异常停止，检查点将跟踪自动恢复所需的编号最小的日志文件。要查看检查点文件，运行以下命令:eseutil /mk E0n.chk
6. 令验证已备份日志文件的完整性：eseutil /ml E0n
脱机恢复
“时点”恢复。日志文件不会重放到数据库中。备份后所创建的所有数据都将丢失。存储组中的所有已停止数据库必须一致，并且必须存在有效的检查点文件。不要删除当前的检查点文件或任何现有的日志文件。
“前滚”恢复。备份后所创建的日志文件将被播放到数据库中。如果所有日志文件都可用，则备份后所创建的全部数据都可保存下来。如果启用了循环记录，则必须对脱机备份执行“时点”恢复，而不能选择“前滚”恢复。存储组中的所有数据库必须停止且一致，并且生成备份后创建的所有日志文件都必须存在（包括当前的 E0n.log）。必须删除检查点文件。
“时点”恢复
1. 卸除掉要恢复的数据库，并验证其一致,匹配，且检查点有效。
eseutil /mk E0n.chk | FIND /i "checkpoint"
eseutil /ml E0n.log | FIND /i "lgeneration" 看检查点是否位于日志中。
2. 将已备份的 .edb 和 .stm 文件复制到适当的数据库和流式文件位置。
3. 在Exchange 系统管理器中数据库对象的“数据库”属性内单击以选中 This database can be overwritten by a restore（可以用恢复覆盖此数据库）复选框。
4. 装入已恢复的数据库。
“前滚恢复”
1. 卸除掉要恢复的数据库。
2. 检查一致性。
3. 检查每个数据库标头中记录的日志签名是否为低锚定日志的签名。运行以下命令：
eseutil /mh database_name | find /i "Log Signature"
eseutil /ml low_anchor_log | find /i "Signature"
4. 检查当前数据库路径位置是否与创建备份时的路径位置相同。
eseutil /ml "Last_Consistent"_log | find /i "database name or pattern"
5. 从连续序列中尽可能靠前的低锚定编号开始，收集所有日志，并将这些日志复制到当前的事务日志路径中。
6. 验证所有日志是否共享同一日志签名并处于连续序列中。
eseutil /ml E0n 20049995942.htm.txt
7. 如果高锚定日志尚未命名为 E0n.log，则重命名它。
8. 从“系统路径”文件夹中删除 E0n.chk 文件。
9. 作为装入存储组前的最后一步检查，请验证以下几个方面：
%26#61692; 所有数据库文件都存在于其运行路径中。
%26#61692; 运行事务日志路径中仅有的日志文件从低锚定日志开始，并至少持续到高锚定日志，其中编号最大的可用日志名为 E0n.log。
%26#61692; “系统路径”文件夹中没有 E0n.chk 文件。
10. 如果信息存储尚未运行，请启动它，然后至少在存储组中装入一个数据库。
三. 数据库故障处理
当无法mount上数据库时，按下列步骤操作
1. 尝试启动信息存储，看错误提示和事件日志。
2. 检查一致性
eseutil /mh databasename
3. 若state=dirty shutdown,则不要remove log
若state=clean shutdown,则把log移出，转到第11步。
4. 不一致执行软恢复eseutil /r
成功再检查一致性，转到第9步。
5. 若磁盘空间不足，执行碎片整理(eseutil /d)
6. 数据库不一致并且软恢复不成功
删除mdbdata中的所有Log文件，还有chk文件，以及temp.edb文件。
7. 执行eseutil /p,恢复到一致状态。
8. 将数据库装入一次，并马上卸除。
9. 使用 Isinteg.exe 修复 Pub1.edb 数据库和 Priv1.edb 数据库(isinteg -s (servername) -fix -test alltests)
10. 如果能够启动信息存储服务，而且信息存储较为稳定，并且在多次运行 Isinteg.exe 后仍报告同样的错误和警告，请使用 ExMerge 实用工具，通过将数据导出为 .pst 格式，然后将其重新导入新的或干净的数据库结构中来重建信息存储。
11. 重新启动信息存储,mount 存储。
12. 做一次全备份。
四. 其它信息
.edb 和 .stm 文件是所有数据库信息的最终储存库。在大多数情况下，应将这两个文件视为一个文件；请一前一后地备份和恢复这两个文件。这两个文件必须在时间上相互保持同步；在某一天备份的 .edb 文件不能匹配在另一天备份的流式文件。为避免对哪些日志文件属于各个存储组产生混乱，以唯一的日志前缀命名属于指定存储组的 Exchange 日志，该前缀是文件名的前三个字符，存储组的当前日志文件总是 E0n.log。事务日志的大小统一为 5 MB。如果当前日志文件已满，将用十六进制序列号（称为日志生成编号）将其重命名，并生成新的当前日志文件。日志文件被编号为 E0n00001.log、E0n00002.log，依此类推。带编号的日志文件一般被指定为 E0nxxxxx.log。
如果数据库异常停止，则检查点文件 (E0n.chk) 将记录作为恢复起点的事务日志，恢复必须从此起点处开始重放，以恢复数据库一致性。该过程称为“软恢复”。软恢复与“硬恢复”相对，后者是在恢复联机备份后重放日志文件的过程。软恢复和硬恢复之间最重要的区别是：在硬恢复期间，将修补文件数据插入了日志文件重放过程。不一致的 Exchange 数据库文件是没有将所有未完成事务全部写入其中的文件。在正常操作期间，Exchange 数据库文件是不一致的，因为在缓存中存在尚未物理写入该文件的信息。通常，只有数据库服务正常关闭后，Exchange 数据库文件才被认为是一致的。不过，数据库作为一个整体（该整体被认为是事务日志和数据库文件中的信息总和）始终是一致的，除非所需的日志文件被过早删除。
处理数据库签名与路径不匹配问题
与日志文件一样，数据库也有自己的签名。不同的是，虽然自创建 E0n000001.log 文件之后日志签名不会再更改，但每当数据库的物理拓扑改变时，数据库签名将会更改，并且不通过日志文件对这些更改进行跟踪。使用 Eseutil 对数据库进行脱机碎片整理或修复时，会更改 DB 签名。经过这样的事件后，数据库可以附加到先前的同一日志流，但它将不接受数据库具有先前签名时所执行的所有事务的重放。数据库的以前副本不接受数据库签名更改后所执行的任何事务的重放。由于数据库签名以这种方式重置，因此强烈建议您在对数据库进行脱机碎片整理或修复后，立即创建完全数据库备份。如果您以后恢复具有旧签名的数据库副本，将会成功重放到签名更改点，但您将会丢失该点之后的所有更改。如果在日志流中间更改了数据库路径，其效果与更改签名类似：重放将在更改点中断。（联机备份 API 提供了一种手段，可以在恢复过程中重新映射路径；因此，即使在创建备份后更改了路径，联机备份 API 也可以完全重放日志。）
,
