运维案例 | Exchange2010数据库损坏的紧急修复思路

​​关注嘉为科技，获取运维新知

 

Exchange后端数据库故障，一般都会是比较严重的紧急故障，因为这会直接影响到大面积用户的正常使用，而且涉及到用户数据。一旦遇到这种级别的故障，管理员往往都是在非常紧张、压力非常大的状态下进行恢复操作，需要在高压状态下迅速做出决策，下一步应该如何做。本文将总结数据库紧急故障下的恢复思路，希望对遇到这种紧急情况的邮件系统管理员有所帮助。

注：以下案例仅针对Exchange 2010版本。

 

一般邮件数据库的紧急故障，首先判断数据库状态是否正常，是否可以挂载使用；数据库无法挂载使用则可以通过命令判断是否需要进行数据库修复；使用如下图的命令，如果数据库状态并非Clean Shutdown则需要进行修复操作。

 

如果数据库需要进行修复，则管理员需要判断，是等待数据库完全修复好之后再进行恢复邮件服务？还是优先恢复用户邮箱使用，邮箱数据则等待数据库修复之后再进行恢复？

因为有的时候数据库修复时间较长，用户无法等待这么久的时间。笔者就曾遇到过修复600GB数据库的案例，首先软修复耗费3个多小时，硬修复耗费1个多小时的情况。

 

如需要紧急优先恢复用户邮箱使用，后续再恢复数据的场景，则可以使用以下两种方案。两种方案基本大同小异，大家可以参考使用。

 

 

方案一，在原先的数据库挂上空库使用，后续合并数据

1、剪切目录中所有原始