干货分享之一次Exchange 2003 数据恢复的历程

前几天有一个客户的公司Exchange Server出现硬件问题，管理员在危机关头非常幸运的Copy出了Exchangeinstall目录中的所有文件。非常糟糕的是这家公司的DC和Exchange在同一台Server上，并且没有其他的DC。

由于客户对邮件的应用比较敏感，管理员在第一时间重新安装了DC，并且又安装了Exchange在上面，我了解他的想法，先可以收发邮件以后再说...

管理员曾经尝试几次恢复AD并且恢复Exchange未能成功，后来找到了我们... ...

通过我们对客户状况的调研，核心信息如下

1、客户单台使用Exchange 2003作为邮件服务器，上一次通过NTbackup备份的邮箱存储已经间隔达三个月之久，基本无利用价值。

2、客户已经搭建了一个新的Exchange环境，已经使用了一周，但是旧的数据一直没有导过来。

3、用户都是使用MAPI的方式收发邮件，用户邮件都是存放在服务器上，本机使用MAPI的缓冲模式，本机的OST文件，有一部分人已经Copy到PST保存，但仍有用户OST目前无法打开。

经过以上信息汇整得出，用户最为迫切的需求是恢复旧的邮件，并且重新架构目前的Exchange环境，并做好备份体系避免类似故障的发生。

重新架构Exchange和建立备份体系的问题，可以另外开文章去写，我这里想记录的是Exchange恢复的过程。那么恢复邮件客户有两个可以利用的资源一个是本地的OST文件，另外是Exchange 2003的离线备份文件。

客户规模比较小，想尽量降低恢复数据的成本。我首先建议他们利用OST2PST这样的工具把用户的邮件导出到PST中，但是非常遗憾的是，我们使用了OST2PST以及AdvancedExchangeRecovery等工具，但是有一个最重要的用户的OST文件一到70%就报错，并且有部分用户本机并没有OST文件，所以这个方法只是解决了部分用户的问题。

这样我们将重点转移到了恢复Exchange脱机备份的文件上，客户的数据库在20G左右，我将MDBData下的文件Copy到我的Exchange测试环境中对数据库的状态进行数据恢复测试，这里有两个KB给了我很大帮助，

http://support.microsoft.com/kb/q296788/

http://support.microsoft.com/kb/313184

经过数据整理，数据库的状态变为Clear Shutdown

然后我将DB Mount到我的存储中，无法加载，日志中记录了1088的错误

事件 ID：1088
源：MSExchangeIS
类型：错误
类别 General
说明：
The information store could not be loaded because the distinguished name (DN) of the message database
/O=OldOrg /OU=OldSite /CN=RECIPIENTS /CN=
does not match the DN of the directory
/O=OldOrg /OU=OldSite /CN=RECIPIENTS /CN=

The database may have been restored to a computer that is an organization or site different than the original database.

组织名称和管理组不一致的问题，因为我这个是测试环境，所以我就用Legacydn.exe 的forcewrite的模式将我的Exchange环境DN修改成为这个DB当时的组织名称，如何下载Legacydn.exe可以访问

http://support.microsoft.com/kb/324606/zh-cn

如果你不确定旧组织的名称，也可以通过这个方式查看，虽然KB是写给Exchange 5.5的，经过我测试在03下一样适用

http://support.microsoft.com/kb/155509/zh-cn

修改完成之后，唱出一口气，DB Mount成功。

下面就是在我的环境中重建DB中的账号，如果账号少你当然可以新建然后关联账号，但是如果账号很多的话，你可以通过这个Mbconn.exe 这个工具重建DB中的AD账号，详细的说明请参考:

http://support.microsoft.com/kb/271886/en-us/文章

然后将账号重新管理之后，使用Exmerge这个工具将邮箱导出到PST文件。