一周前，我们的 HP PROLIANT ML370 G5 服务器（配备 RAID5）中有一个硬盘变成琥珀色，我们将其移除，它一直在降级状态下运行，直到现在。
昨天早上，我们域中的用户抱怨说，邮件没有从连接到我们的 sbs 2003 exchange 的 OUTLOOK 发出。所有用户都配置了 psts，而不是 osts。检查 ESM 后发现，所有邮件都在队列中，并且互联网连接和 smtp 智能主机均可访问。因此，重新启动了 exchange 服务，这时我们发现，信息存储在最后一刻启动，并因错误 1068 而停止。
我们重新启动了服务器，花了很长时间才到达桌面，而且发现信息存储没有启动。观察到的情况是，当信息存储服务启动时，服务器完全挂起；我们在排除故障时不得不对服务器进行几次硬重置。
在互联网上搜索后，我们发现信息存储 edb 文件损坏导致此症状，链接如下http://support.microsoft.com/kb/313184
我们现在正在根据本文档修复数据库；它成功跨越了 priv1.edb，但在过去的 4 个小时里，pub1.edb 和 stm 扫描数据库目录正在进行中。
请告诉我下一步该怎么做，因为我明天早上必须准备好这个生产服务器
注意：数据库 priv1.edb 及其相关文件 - 9 GB ＆ pub1.edb 和 stm 文件 -2 GB
感谢和问候
斯瓦米纳坦
答案1
在我看来，您遇到了硬件问题（可能已经降级的 RAID 中存在更多错误）。
无论数据库文件有多“损坏”，信息存储服务都不会使服务器“完全挂起”。如果机器在尝试安装信息存储时确实挂起，则无法在该硬件上运行成功修复。
即使您确实设法修复了数据库，继续从已修复的数据库运行生产 Exchange 安装也不是一个好主意。如果您设法修复了它，最好将邮箱从服务器移到另一个 Exchange 实例，并丢弃已修复的数据库。
此时，我将执行 Exhcange 的灾难恢复安装，将您最近的 Exchange 备份还原到新服务器（虚拟机等），并远离可能导致问题的故障硬件。继续在已经导致停机和数据损坏的硬件上提供生产服务是一个坏主意。
如果您没有备份，那么至少我希望您在尝试修复数据库文件之前对其进行备份。您可以尝试在另一台机器上修复这些文件（无需安装 Exchange 即可运行 ESEUTIL - Exchange 中的“Bin”目录副本即可提供运行它所需的文件）。
如果您根本没有备份，那么您可能已经丢失了公共信息存储（pub1.edb 和 pub1.stm）。由于您说您的私人信息存储已成功修复（priv1.edb 和 priv1.stm），您可能仍能找回用户邮箱数据。
答案2
查看此链接的灾难恢复部分。
http://www.msexchange.org/tutorials/exchange-isinteg-eseutil.html
您将需要在最后运行 ISINTEG 以确保使用 ESEUTIL 进行了良好的修复。