对于邮件平台而言，邮件的收发对于企业来说是一种沟通方式和手段，但是对于企业而言从另一个方面又需要保证邮件收发的正确性及合规、合法性，这时就需要邮件平台有能力对来往邮件均进行记录审计，以备出现问题时可以调取，而很多企业也会购买专门的归档软件，如赛门铁克的EV归档一类的产品，对于我所服务过的所有互联网公司对这部分的审计可能更为重要，前段时间我就发现一个很有意思的事情，日记功能时不时就失效了，邮箱登录正常，但是没有任何审计后的邮件？是什么原因产生的？可能真的不是那么好去判断，对于Exchange而言自身的日记功能就是干审计这件事情的，那么为何会出现不稳定呢？当然不论哪个技术方向大家都会去看日志，典型的微软产品我们一般看系统日志和应用程序日志来分析出现问题时究竟有什么报错或警告，而网络设备出现运行不正常时，会进行Debug方式来查看生效情况。我在问题发生时查看日志，发现了如下一个日志报错，这里也分享给大家看看，如下图所示：
从这个错误来看，日记所在的磁盘空间不足，而实际去看，确实也不够了，尽管我有使用赛门铁克的NBU对日志进行备份，按理说不会出现这种磁盘满的问题，OK，暂时不去管为什么没有正常备份，先来看看，日记邮件被之前的管理员建立在了一个磁盘空间仅有600G的磁盘，而要命的是Exchange也被安装在了这个盘……实话说不太理解为何会建在这里把日记邮箱数据库，但后来一想，可能是图形化界面默认时会选择安装在Exchange程序所在盘中造成的，所以对于我们邮件管理员来说，实话说决对不能犯这种低级的错误呀……，这时候如何处理呢？而且此时如果不尽快处理，接下来可能会影响Exchange服务器正常运行。
我处理时按如下思路进行操作：
1、删除日记邮箱数据库中30天前的日志文件（当然如果你发现的早，而且未影响前，也可以先备份一份出来再删除，因为偶发现这个问题的时候，实话说已经很紧急了，来不及备份了，这也是NBU不备份给我带来的悲惨呀……，所以大家用NBU进行备份时还是要多看看备份是否正常了每天的）。
2、如果如自己推断和日志报错是由于磁盘空间不足导致日记邮箱失效的话，那么就重新建立新的日记邮箱数据库，将原日记邮箱移至新库中。
PS：由于用的EV归档，最好不要换日记邮箱，如果换了后期查邮件比较麻烦，会带来邮件查询的不连续性。
3、所有操作结束后，删除旧的日记邮箱数据库。
在上述第一步操作执行过程中发现有新的日记邮件进入日记邮箱，小小开心一下，那么接下来要做的就是在正确的邮箱数据库存储目录建立新的日记邮箱数据库，等日志清理完后开始移动日记邮箱至新的数据库中，同时重新配置NBU备份日记邮箱数据库功能及EV归档对日记邮箱的配置也要重新配置一下。
这件事情，可能处理上非常容易，只要找到问题的原因，可是从另一个侧面也反映出了管理员在做这种建库操作时的专业度，对于日记邮箱所在数据库可能比其它库更为要谨慎，毕竟日记邮箱收取的是所有来往邮件，而一但出现不备份日志文件，那么磁盘很快会被占满，所以尽可能把日记数据库存放在单独盘下，这样不影响其它库的正常运行和邮件服务正常运行。
本文转自wangtingdong 51CTO博客，原文链接：http://blog.51cto.com/tingdongwang/1532785，如需转载请自行联系原作者
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
