本文介绍一些方法，通过这些方法，可以手动备份和恢复 Exchange 信息存储数据库，而不必使用联机备份应用程序编程接口 (API)。如果在一台 Exchange 服务器上有多个存储组，则必须将每个存储组视为独立的、自治的存储单位，以便进行脱机备份和恢复。
更多信息
本文包含以下章节：
开始之前
Exchange 数据库文件如何相互关联
脱机备份 Exchange 数据库
恢复 Exchange 数据库的脱机备份
处理 1216 错误
脱机备份的时点恢复
脱机备份的前滚恢复
处理数据库签名与路径不匹配问题
开始之前
在执行脱机备份之前，请确保具有以下信息：
1、确定是否为存储组启用循环记录。（在 Exchange 中，默认情况下禁用循环记录。）要确定是否启用循环记录，请在 Exchange 系统管理器中打开 storage_group 对象的属性，然后查看常规页。要禁用循环记录，请单击以清除循环记录复选框。在您停止存储组中的每个数据库后，对循环记录所做的更改才会生效。
执行脱机备份时，无需禁用循环记录。但是，如果要将事务日志重放到已恢复的脱机备份中，必须禁用循环记录。
2、确定 Exchange 数据库、流、事务日志和检查点文件的路径位置以及存储组的日志文件前缀。
要找到此信息，请在 Exchange 系统管理器中打开 storage_group 对象的属性，然后查看常规页。记录下面三个框中的值：
日志文件前缀（E0n，此处 E0n 可以是 E00、E01、E02 或 E03）
事务日志位置 (E0n*.log)
系统路径位置 (E0n.chk)
数据库路径列在每个 database_name 对象的 Database 属性中。记录存储组中每个数据库的以下两个字段的值：
Exchange 数据库 (.edb)
Exchange 流数据库 (.stm)
如果无法使用 Exchange 系统管理器，则可以使用 ADSIEDIT 或 LDIFDE 之类的工具直接从 Active Directory 读取原始属性，来找到上述所有信息。可以使用下面的 LDIFDE 命令来输出 Active Directory 林中所有 Exchange 服务器的信息。
注意：为提高可读性，对此命令的文本进行了换行处理。
LDIFDE -F EXPATHS.TXT -D "CN=CONFIGURATION,DC=configuration_container_domain,DC=top_level_domain" -L MSEXCHESEPARAMLOGFILEPATH,MSEXCHESEPARAMSYSTEMPATH,
MSEXCHESEPARAMBASENAME,MSEXCHESEPARAMCIRCULARLOG,MSEXCHSLVFILE,
MSEXCHEDBFILE -R"(|(MSEXCHESEPARAMLOGFILEPATH=*)(MSEXCHESEPARAMSYSTEMPATH=*)(MSEXCHESEPARAMBASENAME=*)(MSEXCHESEPARAMCIRCULARLOG=*)(MSEXCHEDBFILE=*)(MSEXCHSLVFILE=*))"
下面是前述命令的一个输出示例：
D:/exchsrvr/mdbdata>ldifde -f con -d "cn=configuration,dc=test,dc=com" -l msexch eseparamlogfilepath,msexcheseparamsystempath,msexcheseparambasename,msexchesepar amcircularlog,msexchslvfile,msexchedbfile -r "(|(msexcheseparamlogfilepath=*)(ms excheseparamsystempath=*)(msexcheseparambasename=*)(msexchslvfile=*)(msexchedbfi le=*)(msexcheseparamcircularlog=*))"
Connecting to "dc1.child.test.com"
Logging in as current user using SSPI
Exporting directory to file con
Searching for entries...
<输出被截断>
.dn:CN=First Storage Group,CN=InformationStore,CN=Exchange1,CN=Servers,CN=First Administrative Group,CN=Administrative Groups,CN=Organization,CN=Microsoft Excha nge,CN=Services,CN=Configuration,DC=Test,DC=com
changetype:add
msExchESEParamCircularLog: 0
msExchESEParamLogFilePath:D:/exchsrvr/MDBDATA
msExchESEParamSystemPath:D:/exchsrvr/MDBDATA
msExchESEParamBaseName:E00
.dn:CN=Public Information Store (EXCHANGE1),CN=First Storage Group,CN=Informati onStore,CN=Exchange1,CN=Servers,CN=First Administrative Group,CN=Administrative Groups,CN=Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Tes t,DC=com
changetype:add
msExchEDBfile:D:/exchsrvr/MDBDATA/PUB.EDB
msExchSLVfile:D:/exchsrvr/MDBDATA/PUB.stm
.dn:CN=Private Information Store (Exchange1),CN=First Storage Group,CN=Informat ionStore,CN=Exchange1,CN=Servers,CN=First Administrative Group,CN=Administrative Groups,CN=Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Te st,DC=com
changetype:add
msExchEDBfile:D:/exchsrvr/MDBDATA/PRIV.EDB
msExchSLVfile:D:/exchsrvr/MDBDATA/PRIV.stm
要成功重放事务日志，必须将数据库文件（.edb 和 .stm）恢复到从中备份这些文件的同一路径位置。例如，如果从 E:/Mdbdata 文件夹备份数据库文件，并且从 F:/Mdbdata 文件夹备份流式处理数据库文件，则必须将这些文件分别恢复到 E:/Mdbdata 和 F:/Mdbdata。即使您希望将数据库恢复到完全不同的服务器（例如在恢复单个邮箱的情况下），此限制也适用。
如果在上一次备份后更改了数据库路径，则只能部分重放事务日志，并且只能在将路径重新更改为原始位置后才能获得部分重放。如果还原为旧路径，则可以将日志一直重放到路径被更改的时刻。
可以将事务日志文件 (E0n*.log) 恢复到除原始备份位置以外的其他路径。这是因为，事务日志会记录其附加到的数据库的位置，但数据库不记录事务日志的位置。在重放期间，日志使用存储在事务日志标头中的路径信息“找到”数据库。（联机备份 API 在内部校正数据库路径的更改，因而此限制不适用。）
您无需备份或恢复检查点文件 (E0n.chk)，但必须知道检查点文件的当前位置，因为在恢复期间可能需要检查该文件或将其删除。
Exchange 数据库文件如何相互关联
.edb 和 .stm 文件是所有数据库信息的最终储存库。在大多数情况下，应将这两个文件视为一个文件；请一前一后地备份和恢复这两个文件。这两个文件必须在时间上相互保持同步；在某一天备份的 .edb 文件不能匹配在另一天备份的流式文件。
Exchange 2000 或 Exchange 2003 服务器最多可支持四个存储组，而每个存储组最多可支持五个数据库。存储组是一组共享公用事务日志文件集的数据库。Microsoft Exchange Server 5.5 最多可支持一个存储组，而该存储组最多可支持两个数据库（专用和公用信息存储）。
当对数据库进行更改时，这些更改将被首先写入当前事务日志文件，然后写入内存中的缓存。更改一旦出现在缓存中，用户就可以看到它们。在适当的时候，缓存中的页将刷新到数据库文件中。检查点将对日志文件序列中的某个点进行标记，在该点之前的日志文件中的所有事务都已物理刷新到数据库文件。检查点通常滞后当前日志文件三个或更多的日志文件。
为避免对哪些日志文件属于各个存储组产生混乱，以唯一的日志前缀命名属于指定存储组的 Exchange 日志，该前缀是文件名的前三个字符。在 Exchange 2000 或 Exchange 2003 服务器上，用于所支持的四个存储组的有效日志前缀是 E00、E01、E02 和 E03。在本文内，存储组的日志前缀被指定为 E0n。存储组的当前日志文件总是 E0n.log。
事务日志的大小统一为 5 MB。如果当前日志文件已满，将用十六进制序列号（称为日志生成编号）将其重命名，并生成新的当前日志文件。日志文件被编号为 E0n00001.log、E0n00002.log，依此类推。在本文内，带编号的日志文件一般被指定为 E0nxxxxx.log。
如果数据库异常停止，则检查点文件 (E0n.chk) 将记录作为恢复起点的事务日志，恢复必须从此起点处开始重放，以恢复数据库一致性。该过程称为“软恢复”。软恢复与“硬恢复”相对，后者是在恢复联机备份后重放日志文件的过程。软恢复和硬恢复之间最重要的区别是：在硬恢复期间，将修补文件数据插入了日志文件重放过程。
不一致的 Exchange 数据库文件是没有将所有未完成事务全部写入其中的文件。在正常操作期间，Exchange 数据库文件是不一致的，因为在缓存中存在尚未物理写入该文件的信息。通常，只有数据库服务正常关闭后，Exchange 数据库文件才被认为是一致的。不过，数据库作为一个整体（该整体被认为是事务日志和数据库文件中的信息总和）始终是一致的，除非所需的日志文件被过早删除。
脱机备份 Exchange 数据库
脱机备份 Exchange 数据库：
1、卸除要备份的数据库。不必卸除存储组中的所有数据库，只需要卸除要备份的一个或多个数据库。
2、验证数据库文件（.edb 和 .stm 文件）一致且相互匹配。为此，请对每个文件运行以下命令：
eseutil /mh database file | find /i "DB Signature"
注意：Exchange 2000 Service Pack 2 及更高版本不是将数据库状态报告为“Consistent”或“Inconsistent”，而是报告为“Clean Shutdown”或“Dirty Shutdown”。“Clean Shutdown”的含义与“Consistent”相同，而“Dirty Shutdown”的含义与“Inconsistent”相同。对于 Exchange 2000 Service Pack 2 或更高版本，请运行下面的命令以确定每个数据库的状态：
eseutil /mh database_name | find /i "Shutdown"
下面是前述命令的一个输出示例：
D:/mdbdata>eseutil /mh priv.edb | find /i "DB Signature"
DB Signature:Create time:04/02/2001 16:59:32 Rand:2746771 Computer:
D:/mdbdata>eseutil /mh priv.stm | find /i "DB Signature"
DB Signature:Create time:04/02/2001 16:59:32 Rand:2746771 Computer:
在上一示例中，DB 签名都相同，从而证明 .edb 和 .stm 文件属于同一文件集。（两个签名行必须逐字符地完全匹配，才能认为这两个签名匹配。）
不仅 DB 签名必须匹配，而且文件也必须相互同步并一致。对每个文件运行下面的命令：
eseutil /mh database file | find /i "consistent"
下面是前述命令的输出示例：
D:/mdbdata>eseutil /mh priv.edb | find /i "consistent"
State:Consistent
Last Consistent:(0x2CC7,1F14,1F7) 04/04/2001 18:07:14
D:/mdbdata>eseutil /mh priv.stm | find /i "consistent"
State:Consistent
Last Consistent:(0x2CC7,1F14,1F7) 00/00/1900 00:00:00
在上一示例中，两个文件都报告“State:Consistent”。括号中相应于每个文件的十六进制编号 (0x2CC7,1F14,1F7) 也必须匹配。“Last Consistent”时间戳不必匹配。这两个文件既一致又相互匹配。
如果其中一个文件报告“State:Inconsistent”或者“Last Consistent”日志位置不同步，则表示数据库没有干净地卸除。装入该数据库，然后再次卸除它。如果这两个文件仍然没有正确地匹配或者不一致，请与 Microsoft 产品支持服务 (PSS) 联系以获得进一步的帮助。
3、将每个 .edb 数据库文件及其相应的 .stm 流式数据库文件复制到备份位置。
4、装入已备份的数据库。
5、如果启用了循环记录，请跳过该步骤。如果禁用了循环记录，并且稍后要“前滚”，则必须备份所有带编号的事务日志文件（E0nxxxxx.log 文件）。不要备份 E0n.log、Res1.log 和 Res2.log 文件。
可以在任何方便的时候备份带编号的日志文件，甚至在创建后即可进行备份，这是因为日志文件已经从 E0n.log 重命名为 E0nxxxxx.log，Exchange 不再更改该文件。但是，只能根据步骤 6 中的说明清除已备份的日志文件。
日志文件备份与数据库备份并不一一对应。每个日志文件备份都是日志文件链中的一个环节，它们可以在任意多个不同的数据库备份上播放。只要您有从数据库标头“Last Consistent”（最后一致）行中列出的日志开始的完整日志流，就可以从特定的数据库备份前滚。在本文中，Last Consistent 日志称为“低锚定日志”。
如果参考上一示例，则 Last Consistent 项为 (0x2CC7,1F14,1F7)。这三个编号分别指定日志文件、该日志文件中的页和该页的字节偏移量。每个日志文件大约包含 10,000 个页，每个页为 512 个字节。页偏移量使您能清楚地知道日志文件的填满程度（上一示例中的日志文件大约为 80% 满，因为 0x1F14 等价于十进制的 7956），但与恢复无关。恢复始终从日志文件开头处开始。
在本例中，低锚定日志文件是 E0n02cc7.log。
磁盘上的 Last Consistent 日志可能并不总是带编号的日志，因为 Last Consistent 日志的名称可能仍然为 E0n.log。当数据库停止时，检查日志文件的标头时会看到最终将指定序列号 E0n.log（数据库运行时，对 E0n.log 文件头的访问将被拒绝）。
要查看内部日志生成编号，请运行以下命令：
eseutil /ml [log file] | find /i "lGeneration"
下面是前述命令的一个输出示例：
E:/mdbdata>eseutil /ml E00.log | find /i "lgeneration"
lGeneration:11463 (0x2CC7)
在许多情况下，确保日志文件备份完好比确保每个数据库备份完好更重要。这是因为，每个数据库备份可以为其他备份提供冗余，但根据任何数据库备份进行的完全恢复依赖于相应的备份以及进行该备份后每个日志文件的保存情况。
6、如果启用了循环记录，请跳过该步骤。查看检查点文件的标头，以确定可以安全删除的编号最大的日志文件。如果数据库异常停止，检查点将跟踪自动恢复所需的编号最小的日志文件。要查看检查点文件，请运行以下命令：
eseutil /mk E0n.chk
下面是前述命令的一个输出示例：
D:/exchsrvr/mdbdata>eseutil /mk e00.chk | find /i "checkpoint"
Checkpoint file:e00.chk
LastFullBackupCheckpoint:(0x0,0,0)
Checkpoint:(0x2CC7,9607,256)
第三行是 Checkpoint（检查点）行，它包含相关信息（LastFullBackupCheckpoint 项由联机备份使用，如果从未对数据库执行联机备份，则该项保留为全零）。Checkpoint 日志位置的格式与数据库标头中的 Last Consistent 项相同。在本例中，检查点位于 E0002cc7.log 内。
如果禁用了循环记录，将累积日志文件，直到手动将它们删除或由联机备份过程自动将其删除。如果启用了循环记录，不需要特别管理旧日志文件，因为在检查点经过它们后，数据库服务会自动将其删除。
备份所有带编号的日志文件后，您可以通过删除检查点日志之前的所有带编号日志文件（但不包含检查点日志）回收磁盘空间。
重要说明：不要删除检查点日志。
在本例中，可以删除 E0002cc6.log 之前的所有日志。
7、这一步可选。可以使用 Esefile 工具验证已复制数据库在页级别上的完整性。
Exchange Server 5.5 Service Pack 3 CD-ROM、Exchange 2000 Server 安装 CD-ROM 或 Exchange Server 2003 安装 CD-ROM 上的 Support 文件夹中提供了 Esefile.exe 文件。还可从 Microsoft PSS 获取 Esefile.exe 文件。Esefile 工具处理来自 Exchange Server 5.0 及 5.5、Exchange 2000 和 Exchange 2003 的 .edb 文件。
除联机备份外，当前没有其他方法可以验证 .stm 文件的每一页的校验和。.stm 文件包含原始数据。所有用来组织这些数据的索引和指针都位于 .edb 文件内。.stm 文件中的问题会导致某些特定客户端数据丢失，但不会危及数据库整体的结构或逻辑完整性。
要验证 Exchange 数据库的页校验和，请运行下面的 Esefile 工具命令：
esefile /s database_name
下面是前述命令的一个输出示例：
E:/mdbdata>esefile /s priv.edb
Checksumming
0 10 20 30 40 50 60 70 80 90 100
|----|----|----|----|----|----|----|----|----|----|
...................................................
23042 pages seen
0 bad checksums
241 uninitialized pages
0 wrong page numbers
esefile completes successfully after 10 seconds
未初始化的页是可以接受的，但在正常的数据库中有 0 个错误校验和和 0 个错误页编号。
如果数据库未通过 Esefile 工具完整性检查，最好的选择是恢复已知完好的先前备份，并前滚数据库。如果没有这样的备份，请与 PSS 联系获取修复或挽救数据库的建议。
8、这一步可选。可以使用下面的命令验证已备份日志文件的完整性：
eseutil /ml E0n
下面是前述命令的一个输出示例：
k:/backups>eseutil /ml E00
必须从包含已备份日志文件的文件夹中运行此命令。还可以对当前正运行的日志文件夹运行此命令，但如果 Eseutil 试图在存储组中有任何数据库正在运行时读取 E0n.log 的标头，将会收到 -1032 错误 (JET_errFileAccessDenied)。
此命令检测日志文件中的损坏数据，并且当序列中间的日志文件丢失时，或者当任何日志文件之间存在签名不匹配的情况时，此命令都会警告您。
恢复 Exchange 数据库的脱机备份
本节介绍两种恢复脱机备份的方法：
1、“时点”恢复。日志文件不会重放到数据库中。备份后所创建的所有数据都将丢失。
2、“前滚”恢复。备份后所创建的日志文件将被播放到数据库中。如果所有日志文件都可用，则备份后所创建的全部数据都可保存下来。如果启用了循环记录，则必须对脱机备份执行2“时点”恢复，而不能选择“前滚”恢复。
所恢复的文件集必须满足以下最低条件：
1、对于时点恢复，存储组中的所有已停止数据库必须一致，并且必须存在有效的检查点文件。不要删除当前的检查点文件或任何现有的日志文件。
2、对于前滚恢复，存储组中的所有数据库必须停止且一致，并且生成备份后创建的所有日志文件都必须存在（包括当前的 E0n.log）。必须删除检查点文件。
如果文件集不满足上述条件，恢复和重放不一定会失败，但在软恢复过程中可能会收到 -1216 错误信息 (JET_errAttachedDatabaseMismatch)。
处理 -1216 错误
如果 Exchange 检测到已被手动篡改的数据文件，并且确定对当前数据集运行恢复操作会导致以前存在的数据丢失，则 Exchange 2000 及更高版本中的其他软恢复保护机制将导致发生 -1216 错误。
在以前版本的 Exchange 中，如果文件集不完整，但对于成功重放有效，则软恢复启动时不会进一步警告管理员。在 Exchange 2000 及更高版本中，管理员必须使用 Eseutil 专门覆盖 -1216 错误。
脱机备份的时点恢复
对脱机备份执行时点恢复：
1、如果当前装入了要恢复的数据库，请卸除它。如果卸除了存储组中的任何其他数据库，则这些数据库的数据库文件和流式文件（.edb 和 .stm）每一个都必须一致且匹配。（要验证一致性和匹配性，请参见本文“脱机备份 Exchange 数据库”一节中的步骤 2。）
如果卸除了存储组中的所有数据库，则所有数据库都必须一致，并且还必须存在有效的检查点文件。有效的检查点文件是满足以下条件的检查点文件：存储组中的任何数据库上次运行时，这些文件正处于使用状态，并且其标头将 E0n.log 列为检查点。如果存储组中的任何数据库仍然处于装入状态，则有效的检查点文件是当前正由系统使用的检查点文件。如果存储组中的任何数据库正在运行，则存在有效的检查点。
要在所有数据库已停止时验证检查点文件，请运行下面的命令：
eseutil /mk E0n.chk | FIND /i "checkpoint"
eseutil /ml E0n.log | FIND /i "lgeneration"
下面是前述命令的一个输出示例：
D:/mdbdata>eseutil /mk e00.chk | find /i "checkpoint"
Checkpoint file:e00.chk
LastFullBackupCheckpoint:(0x0,0,0)
Checkpoint:(0x2cc7,1B59,1A)
D:/mdbdata>eseutil /ml e00.log |find /i "lgeneration"
lGeneration:11463 (0x2cc7)
在上一示例中，检查点位于 lGeneration 为 0x2cc7 的日志中，即 e00.log。因此，可以认为检查点有效。
如果检查点无效，则当试图装入存储组中的任何数据库时，可能收到 -1216 错误信息 (JET_errAttachedDatabaseMismatch)。即使存储组中的所有数据库都一致，此问题仍然可能发生。
2、将已备份的 .edb 和 .stm 文件复制到适当的数据库和流式文件位置。（要找到这些位置，请参考本文中的“开始之前”一节。）验证已恢复的文件一致并匹配。
注意：如果要恢复的数据库文件的副本在服务器上已存在，请在恢复数据库之前备份这些文件（即使现有文件不可启动）。这些文件可能是可修复的，并且您可能能够使用 Exmerge 工具从其中挽救数据。
3、装入已恢复的数据库。数据库将自身附加到 E0n.log 文件的结尾处。在数据库成功启动后，先前存在的日志文件将无法重放到该数据库中。对于在层次结构中包含成千上万个文件夹的公用文件夹数据库而言，可能要花很长的时间才能启动。对于层次结构中的每 1,000 个文件夹，请至少准备一分钟。
在较早版本的 Exchange Server 中，恢复信息存储数据库的脱机备份后，通常需要运行 ISINTEG -patch 命令将信息存储数据库与目录进行同步。当需要修补 Exchange 数据库时，由系统自动完成此修补操作，除非将该数据库恢复到其他服务器、存储组或逻辑数据库对象，或者已删除该数据库的 Active Directory 对象并在 Active Directory 中重新创建了该对象。在这些情况下，将在“应用程序”事件日志中记录下面的错误信息。
Event Type: Error
Event Source: MSExchangeIS Mailbox Store
Event Category: General
Event ID: 1087
Date: 5/4/2001
Time: 8:33:42 PM
User: N/A
Computer: EXCHANGE1
Description:The information store was restored from an offline backup.In the Microsoft Exchange System Manager, indicate that the database "First Storage Group/Private Information Store" is allowed to be restored to, so that it can be patched.
要解决此问题，必须在 Exchange 系统管理器中数据库对象的“数据库”属性内单击以选中 This database can be overwritten by a restore（可以用恢复覆盖此数据库）复选框。
脱机备份的前滚恢复
要完全成功地将日志文件重放到已恢复的数据库中，请执行以下步骤：
保留自最早完全备份以来创建的所有事务日志的副本。
如果更改了数据库路径，应立即创建一个新的完全备份。
如果运行了 ESEUTIL /p 或 ESEUTIL /d，应立即创建一个新的完全备份。
如果在存储组中添加或删除了数据库，应立即创建该存储组中所有数据库的完全备份。
开始恢复过程：
1、如果装入了要恢复的数据库，请卸除它，然后将要恢复的数据库文件复制到服务器上的相应路径中。如果要恢复的数据库文件的副本在服务器上已存在，请在恢复数据库之前备份这些副本（即使现有文件不可启动）。这些文件可能是可修复的，并且您或许能够使用 Exmerge 工具挽救这些文件中的数据。
2、卸除存储组中的所有数据库，然后对当前存储组中的每个数据库以及每个已恢复的数据库文件运行下面的命令：
eseutil /mh database_file_name | find /i "consistent"
注意：Exchange 2000 Service Pack 2 及更高版本不是将数据库状态报告为“Consistent”或“Inconsistent”，而是报告为“Clean Shutdown”或“Dirty Shutdown”。“Clean Shutdown”的含义与“Consistent”相同，而“Dirty Shutdown”的含义与“Inconsistent”相同。对于 Exchange 2000 Service Pack 2 或更高版本，请运行下面的命令以确定每个数据库的状态：
eseutil /mh database_name | find /i "Shutdown"
下面是前述命令的一个输出示例：
D:/mdbdata>eseutil /mh PRIV.EDB | find /i "consistent"
State:Consistent
Last Consistent:(0x2cc7,2692,1ED) 04/12/2001 20:07:46
I:/mdbdata State: Consistent
Last Consistent: (0x2cc7,2692,1ED) 00/00/1900 00:00:00
E:/mdbdata>eseutil /mh PRIV2.edb | find /i "consistent"
State:Consistent
Last Consistent:(0x2cc7,2685,171) 04/12/2001 20:07:41
J:/mdbdata>eseutil /mh PRIV2.stm | find /i "consistent"
State:Consistent
Last Consistent:(0x2cc7,2685,171) 00/00/1900 00:00:00
F:/mdbdata>eseutil /mh PRIV3.edb | find /i "consistent"
State:Consistent
Last Consistent:(0x2ac8,87,1FC) 04/12/2001 20:05:04
K:/mdbdata>eseutil /mh PRIV3.stm | find /i "consistent"
State:Consistent
Last Consistent:(0x2ac8,87,1FC) 00/00/1900 00:00:00
G:/mdbdata>eseutil /mh PRIV4.edb | find /i "consistent"
State:Consistent
Last Consistent:(0x2cc7,268C,19B) 04/12/2001 20:07:43
L:/mdbdata>eseutil /mh PRIV4.stm | find /i "consistent"
State:Consistent
Last Consistent:(0x2cc7,268C,19B) 00/00/1900 00:00:00
H:/mdbdata>eseutil /mh PUB.EDB | find /i "consistent"
State:Consistent
Last Consistent:(0x2cc7,2699,181) 04/12/2001 20:07:46
M:/mdbdata>eseutil /mh PUB.stm | find /i "consistent"
State:Consistent
Last Consistent:(0x2cc7,2699,181) 00/00/1900 00:00:00
此命令具有三个目的：
检查每个数据库文件是否都一致。
检查每个数据库的 .edb 和 .stm 文件是否成对匹配。
标识低锚定日志文件和高锚定日志文件，它们分别是成功恢复所有数据而不会生成 -1216 错误所需的第一个和最后一个日志文件。在所有数据库中，最低的 Last Consistent 值表示低锚定日志，而最高的 Last Consistent 值表示高锚定日志。
在上一示例中，低锚定日志文件是 E0002ac8.log，而高锚定日志文件是 E0002cc7.log。
3、检查每个数据库标头中记录的日志签名是否为低锚定日志的签名。运行以下命令：
eseutil /mh database_name | find /i "Log Signature"
eseutil /ml low_anchor_log | find /i "Signature"
下面是前述命令的一个输出示例：
D:/mdbdata>eseutil /mh priv.edb | find /i "Log Signature"
Log Signature:Create time:12/29/2000 21:6:38 Rand:24842 Computer:
E:/mdbdata>eseutil /mh PRIV2.edb | find /i "consistent"
Log Signature:Create time:12/29/2000 21:6:38 Rand:24842 Computer:
F:/mdbdata>eseutil /mh PRIV3.edb | find /i "consistent"
Log Signature:Create time:12/29/2000 21:6:38 Rand:24842 Computer:
G:/mdbdata>eseutil /mh PRIV4.edb | find /i "consistent"
Log Signature:Create time:12/29/2000 21:6:38 Rand:24842 Computer:
H:/mdbdata>eseutil /mh PUB.EDB | find /i "consistent"
Log Signature:Create time:12/29/2000 21:6:38 Rand:24842 Computer:
D:/exchsrvr/mdbdata/save>eseutil /ml e0002ac8.log | find /i "Signature"
Signature:Create time:12/29/2000 21:6:38 Rand:24842 Computer:
Signature:Create time:12/29/2000 21:6:40 Rand:67798 Computer:
Signature:Create time:12/29/2000 21:6:41 Rand:58314 Computer:
日志文件可能会报告多个签名。第一个签名始终是日志文件本身的签名，其余签名是创建日志文件时运行的数据库的签名。在上一示例中，数据库文件中记录的日志签名确实匹配低锚定日志中的日志签名。
如果无法定位低锚定日志，则无法将日志向前播放到此数据库中。如果找不到低锚定日志文件，则无法将任何日志文件重放到任何数据库中。有两种方法可用于处理丢失的低锚定日志：
可以删除所有日志文件。由于数据库都一致，因此可以在没有任何日志文件的情况下启动它们，但将无法恢复数据库文件中尚未存在的数据。
可以删除具有最低的 Last Consistent 值的数据库，直到您可以从低锚定到高锚定构建出连续的日志系列为止，然后对剩余的数据库运行恢复操作。将已删除的数据库放回存储组中后，无法将其他数据重放到数据库中。
4、检查当前数据库路径位置是否与创建备份时的路径位置相同。
虽然在创建备份后可以更改事务日志路径或工作路径，但仅当数据库文件位于其备份时所在的位置时，才能执行日志文件重放。如果不能肯定原始位置，请运行下面的命令：
eseutil /ml "Last_Consistent"_log | find /i "database name or pattern"
下面是前述命令的一个输出示例：
N:/mdbdata>eseutil /ml e0002cc7.log |find /i ".edb"
1 f:/MDBDATA/PRIV3.edb
2 g:/MDBDATA/PRIV4.edb
3 d:/MDBDATA/PRIV.EDB
4 e:/MDBDATA/PRIV2.edb
5 h:/MDBDATA/PUB.EDB
d:/mdbdata>eseutil /ml e0002cc7.log |find /i ".stm"
streaming file:k:/MDBDATA/PRIV3.stm
streaming file:l:/MDBDATA/PRIV4.stm
streaming file:i:/MDBDATA/PRIV.stm
streaming file:j:/MDBDATA/PRIV2.stm
streaming file:m:/MDBDATA/PUB.stm
注意：如果低锚定日志为 E0n00001.log，它的标头中将没有路径信息，因为在将首个数据库附加到日志系列中的首个日志之前，就已生成该日志的标头。在这种情况下，必须访问下一个日志的标头才能查看数据库路径信息。在少数情况下，首个日志后的日志也会出现此情况，因为在创建该日志后数据库才创建或附加到日志流中。
从连续序列中尽可能靠前的低锚定编号开始，收集所有日志，并将这些日志复制到当前的事务日志路径中。在覆盖服务器上已存在的日志时，首先要备份这些日志。为此，可能需要从多种类型备份媒体中恢复日志文件。
在上一示例中，低锚定日志是 E0002ac8.log，而高锚定日志是 E0002cc7.log。在检查可用日志时，可以找到的最大日志编号可能比所需的编号小 1（如 E0002cc6.log，而不是 2cc7）。发生这种情况的原因通常是：尚未填充 E0n.log 并将其重命名为序列中的相应编号。要确定 E0n.log 是否为实际的高锚定日志，必须使用下面的命令检查日志文件标头中的 lGeneration 值：
eseutil /ml E0n.log | find /i "lGeneration"
下面是前述命令的一个输出示例：
N:/mdbdata>eseutil /ml e00.log |find /i "lGeneration"
lGeneration:11463 (0x2cc7)
注意：要用 Eseutil 工具查看日志文件的标头，请使用 /ml 开关；要查看数据库文件标头，请使用 /mh 开关。如果将这两个开关搞混了，命令的输出将不正确。
通常，高锚定日志同时也是编号最大的可用日志，但在下列情况下不成立：
日志文件已在灾难中损坏。
- 或者 -
您正在一次性恢复存储组中的所有数据库。
在第一种情况下，在恢复过程中可能遇到 -1216 错误；在第二种情况下，只要日志文件仍在 lGeneration 序列中，即可向前播放日志文件，甚至越过高锚定日志。
6、验证所有日志是否共享同一日志签名并处于连续序列中。运行以下命令：
eseutil /ml E0n > filename.txt
下面是前述命令的一个输出示例：
d:/mdbdata>eseutil /ml E00 > logverify.txt
d:/mdbdata>type logverify.txt
Microsoft(R) Exchange Server(TM) Database Utilities
Version 6.0
Copyright (C) Microsoft Corporation 1991-2000. All Rights Reserved.
Initiating FILE DUMP mode...
Verifying log files...
Base name:e00
Log file:D:/exchsrvr/mdbdata/save1/E0000001.log
Log file:D:/exchsrvr/mdbdata/save1/E0000002.log
Log file:D:/exchsrvr/mdbdata/save1/E0000003.log
Log file:D:/exchsrvr/mdbdata/save1/E0000004.log
Log file:D:/exchsrvr/mdbdata/save1/E0000005.log
Log file:D:/exchsrvr/mdbdata/save1/E0000006.log
Log file:D:/exchsrvr/mdbdata/save1/E0000007.log
Log file:D:/exchsrvr/mdbdata/save1/E0000008.log
Log file:D:/exchsrvr/mdbdata/save1/E0000009.log
Log file:D:/exchsrvr/mdbdata/save1/E000000A.log
Log file:D:/exchsrvr/mdbdata/save1/E000000B.log
Log file:D:/exchsrvr/mdbdata/save1/E00.log
No damaged log files were found.
Operation completed successfully in 3.305 seconds.
此 Eseutil 命令完成三项任务：检查每个日志文件是否损坏；报告日志文件序列中的任何缝隙；以及检测日志签名是否存在不匹配的情况。
作为重放候选的所有日志文件的所有日志签名之间都必须匹配。在重放开始之前，必须删除签名不匹配的所有日志。
此时，当您删除未通过这些验证测试的文件后，“事务日志”文件夹中的事务日志文件均将符合以下条件：
处于连续的 lGeneration 序列中，该序列从低锚定日志文件开始，至少持续到高锚定日志文件（如有可能则超过它）。
具有匹配的日志签名。
7、如果高锚定日志尚未命名为 E0n.log，则重命名它。
8、从“系统路径”文件夹中删除 E0n.chk 文件。
在缺少检查点文件时，Exchange Server 开始从“事务日志”文件夹中可用的、带有最小编号的日志文件重放日志，该日志文件即为：低锚定日志。如果 E0n.chk 文件存在，Exchange Server 将从该文件所记录的检查点开始重放。如果 E0n.chk 检查点超过低锚定日志，则重放操作对于已恢复的文件集完全失败。在许多情况下，如果搞错了检查点文件，则必须重新开始从备份恢复数据库文件。
9、作为装入存储组前的最后一步检查，请验证以下几个方面：
所有数据库文件都存在于其运行路径中。
运行事务日志路径中仅有的日志文件从低锚定日志开始，并至少持续到高锚定日志，其中编号最大的可用日志名为 E0n.log。
“系统路径”文件夹中没有 E0n.chk 文件。
您现在应能够成功装入存储组，并开始使用该文件集重放事务日志。即使在恢复操作完成且数据库启动之后，也可能因重放过程中遇到的 DB 签名和路径问题，而无法实际恢复所有日志文件中的所有数据。本文中的“处理数据库签名与路径不匹配问题”一节提供了有关这些问题的其他信息。
10、如果信息存储尚未运行，请启动它，然后至少在存储组中装入一个数据库。这样会针对存储组中的所有数据库运行软恢复。
在较早版本的 Exchange Server 中，恢复信息存储数据库的脱机备份后，通常需要运行 ISINTEG -patch 命令将该数据库与目录进行同步。当需要修补 Exchange 数据库时，由系统自动完成此修补操作，除非将该数据库恢复到其他服务器、存储组或逻辑数据库对象，或者已删除该数据库的 Active Directory 对象并在 Active Directory 中重新创建了该对象。在这些情况下，将在“应用程序”事件日志中记录下面的错误信息。
Event Type: Error
Event Source: MSExchangeIS Mailbox Store
Event Category: General
Event ID: 1087
Date: 5/4/2001
Time: 8:33:42 PM
User: N/A
Computer: EXCHANGE1
Description:The information store was restored from an offline backup.In the Microsoft Exchange System Manager, indicate that the database "First Storage Group/Private Information Store" is allowed to be restored to, so that it can be patched.
要解决此问题，必须在 Exchange 系统管理器中单击以选中“This database can be overwritten by a restore”（可以用恢复覆盖此数据库）复选框。
在 Microsoft Windows NT 事件查看器中检查“应用程序”事件日志，查看在数据库启动时是否发生了错误或异常现象。对重放的每个日志文件，都显示一个 301 事件。仔细查看恢复过程中的错误和警告。
处理数据库签名与路径不匹配问题
与日志文件一样，数据库也有自己的签名。不同的是，虽然自创建 E0n000001.log 文件之后日志签名不会再更改，但每当数据库的物理拓扑改变时，数据库签名将会更改，并且不通过日志文件对这些更改进行跟踪。使用 Eseutil 对数据库进行脱机碎片整理或修复时，会更改 DB 签名。经过这样的事件后，数据库可以附加到先前的同一日志流，但它将不接受数据库具有先前签名时所执行的所有事务的重放。数据库的以前副本不接受数据库签名更改后所执行的任何事务的重放。
由于数据库签名以这种方式重置，因此强烈建议您在对数据库进行脱机碎片整理或修复后，立即创建完全数据库备份。如果您以后恢复具有旧签名的数据库副本，将会成功重放到签名更改点，但您将会丢失该点之后的所有更改。
如果在日志流中间更改了数据库路径，其效果与更改签名类似：重放将在更改点中断。（联机备份 API 提供了一种手段，可以在恢复过程中重新映射路径；因此，即使在创建备份后更改了路径，联机备份 API 也可以完全重放日志。）
当在重放过程中遇到 DB 签名或 DB 路径问题时，会在“应用程序”事件日志中报告这些问题，并与每个日志文件的 301 重放事件一致。问题点之后的日志文件看起来可能成功播放，但这只是因为未重复记录同一个不匹配警告。一般原则是，当遇到引用某个特定数据库的第一个数据库签名错误或路径错误时，将截断到该数据库的重放。
这篇文章中的信息适用于:
Microsoft Exchange Server 2003 Enterprise Edition
Microsoft Exchange Server 2003 Standard Edition
Microsoft Exchange 2000 Server
联系客服
