Exchange使用正常的恢复无法恢复的问题

 

                                    Exchange使用正常的恢复无法恢复的问题

因为在Windows2003 上安装的Exchange2007 是32 位的测试版本, 所以在进行还原的时候在所有设置和步骤都正确的情况下依然无法正常还原. 目前经过一天的摸索, 使FileMon 进行文件的追踪的时候发现文件没有问题. 经过反复尝试. 终于发现了问题的所在, 现提供解决思路供参考:

 

1 首先在没有备份数据前, 先打开C:\Program Files\Microsoft\Exchange Server\Mailbox\First Storage Group 目录, 查看目录下包含的文件:

如上图所示, 共有E0000000001.log 到E000000009.log 的9 个文件, 这些都是Exchange 的初始数据库信息. 同时注意观察, 目录中还存在一个E00.chk 文件, 这个文件是这里非常重要的一个文件, 它可以称为一个检查点文件.

这个文件默认情况下只能通过cmd 命令提示符的方式来进行查看, 我们通过eseutil 实用工具来查看E00.chk 文件的具体内容. 操作方法如下图:

从上图可以看出, 当前的CheckPoint( 检查点) 检查到的是 E0000…9.log 文件. 而Fullbackup( 完全备份) 的起始文件还是0 文件. 这说明什么呢? 这说明目前的系统还没有进行备份工作.

那么这里我们要多了解的一点是在Exchange2003 中日志文件都是使用5M 为一个单位进行存储. 而到了Exchange2007 中为了提高效率将日志文件大小都改为了1M, 那么为了验证日志文件确实是记录了邮件的内容, 我们来使用OWA 给administrator 自己发送几封测试邮件. 接受到测试邮件的OWA 如下图:

 

这时候我们回到刚才的数据库的存放目录, 查看一下日志文件的情况, 如下图:

 

 

通过上图可以发现在目录中出现了E00000…A.log 的日志文件, 这个文件也就是用来记录我们刚才我们生成的两封邮件信息的.

 

这时候再此通过Eseutil 实用工具来查看一下E00.chk 检查文件的状态. 如下图:

 

通过上图可以发现CheckPoint 检查点已经变为了0xA 的样子了. 说明状态已经变到了E000…A.log 的日志状态了.

下面我们使用Ntbackup 来进行一下备份工作. 备份中不需要做任何特殊操作, 按照提示进行即可. 备份完成后如下图:

 

 

备份完成后, 我们使用Eseutil.exe 进行检查点文件的查看. 发现检查点文件, 和完整备份的起始位置都没有变化. 如下图所示, 这时候还原是无法完成的.( 估计原因是因为2007 对于硬件配置较高, 同步速度较慢的问题)

 

这时候重要的一步到来了 . 请你重新启动你的 Exchange2007服务 器 .

 

( 当然, 如果你的时间很充裕, 不妨去抽袋烟, 等上半小时, 也会有奇异的效果出现).

在经过漫长的等待后, 哇塞, 终于可以登陆了. 我们再使用eseutil 实用工具查看一下检查点文件, 如下图:

 

注意观察上图,Fullbackup 的内容已经从0x0 变为了0xC 的表示方法

 

为了保险起见, 我们再来备份一下邮箱的数据.( 当然这步可能是多余的, 但是时间原因, 没有仔细想, 建议可以尝试一下). 在备份以后,Exchange 会将备份过的日志文件自动删除掉. 这个时候, 再来查看一下Exchange 的数据库的内容. 如下图:

 

 

从上图可以看出之前存在的从表面上看A 到C 的文件全部消失了. 而多增加了E0000..10.log 和E0000…11.log 的文件. 这时候我们可以再查看一下检查点文件, 如下图:

 

 

已经变为了0x10 和0x11. 好了, 下面我们来看恢复的操作.

 

首先彻底删除邮件. 如下图所示:

 

接着打开Exchange 管理控制台, 找到邮箱服务器角色, 做如下操作:

然后就可以卸载数据库了. 请如下图所示操作:

 

下面使用NTbackup 工具进行还原操作, 操作如下图, 选择正确的备份数据信息.

 

( 注意啦, 这里为了保证成功率, 可以单击” 工具”—“ 编录一份备用文件”, 然后确定.)

开始还原, 还原的时候如下图做选择即可.

完成还原后, 我们来c:\temp7 目录下看一下, 可以看到如下信息：

 

这里的文件代表要使用resotre.env 来恢复E0000…F.log 和E0000….10.log 的日志信息( 这两个日志中恰好记录的就是之前的邮箱信息的变动情况.)

( 如果没有这些文件, 那么你的恢复一定会失败, 请查看这些文件是否齐全.)

下面可以尝试装入数据库, 这时候会有相应的报错提示如下图:

 

上图中提示了544 的报错信息, 这证明服务器的数据库状态有问题, 需要使用实用工具eseutil 来进行修复. 修复方法如下图:

从上图可以看出来当前的状态是未完成状态, 所以需要使用eseutil /p 的命令进行修复, 这里的过程省略.

修复完成后, 开始挂载数据库, 如下图:

挂载完成后, 再次使用OWA 登陆, 出现如下图的结果:

 

 

经过总结发现, 最主要的原因可能是服务器的相应不是很及时, 这是32 位版本存在的一个比较明显的问题, 在实际生产环境中还没有发现此类问题. 在实验中应加以注意.

 

如果遇到其他问题, 推荐使用Filemon 软件, 该软件支持对于文件变动的追踪. 一般比较方便发现问题.

有写的不对的地方还请各位多多指教！！！