错误是：
eseutil（2860）JetDBUtilities – 3928：日志文件\？\ GLOBALROOT \ Device \ HarddiskVolumeShadowCopy84 \ Program Files \ Microsoft \ Exchange Server \ V14 \ Mailbox \ Mailbox数据库0501047257 \ E000000B4E0.log已损坏，无效或无法访问（错误-501 ），不能使用。 如果需要此日志文件进行恢复，则需要备份日志文件才能成功完成恢复。
Exchange目前似乎运行良好。
我看了这个错误，看起来像指定的日志文件可能会永久损坏（我认为这是一个错误 – 501意味着什么）。 不幸的是，该日志文件的一个很好的版本太旧，不能在我们的备份上。
在互联网上有各种build议运行eseutil / mh来检查数据库，看看它是在什么状态，看看是否实际需要该日志文件。 由于这一切都需要卸载数据库，我正在寻找最好的第一步，以避免任何问题，例如，如果数据库不会重新安装。 有没有办法，例如，在卸载数据库之前备份所有人的电子邮件，而不必closurespst路由？
我刚刚在虚拟机上做了一个实验，试图模仿你的情况。 我故意破坏了其中一个事务日志文件，并且使用Windows Server Backup作为备份应用程序。 我在下面所说的一切都是基于这个实验，但现实应该不会太多。
即使你说现在一切正常，你也很关心这个错误，通过问这个问题，你可能已经救了你自己一些悲伤和恐慌。
首先，为什么你应该关心一些背景。 当Exchange成功完成备份时，它会刷新（删除）提交的事务日志，因此如果您的备份实际上失败并显示此消息，您的事务日志实际上不会被刷新并正在build立。 如果旧的交易logging没有被刷新，那么不幸的是你的手上会有一个可能随时爆炸的定时炸弹（对不起，听起来如此戏剧化，但实际上相当严重）。 当事务日志的容量已满时，关联的邮箱数据库将自行卸载，直到有足够的空间存储新的事务日志为止。 根据您累积的事务日志数量，将决定您的邮箱数据库由于空间不足而自行卸载的时间。
你将不得不卸下数据库来执行我的build议，但是它应该卸载没有问题，当我卸载我的数据库时，它是在一个Clean Shutdown状态，这是个好消息。
卸载数据库，只需执行完整性检查并运行eseutil /mh <edb file name>以确保数据库处于“ Clean Shutdown状态。 接下来，将除了E00.log和E00tmp.log之外的所有*.log文件E00tmp.log到某个安全的地方（不要删除它们，如果全部都是一致的话，您将需要它们）。 一旦全部移动完毕，再次安装数据库并尽快尝试数据库的完全备份（它应该是完整备份，而不是增量式备份）。 该过程在我的VM中工作，并希望能解决您的问题。
警告：除非你确定你知道你在做什么，否则不要___删除事务日志文件 。 如果您需要从等式中删除事务日志， 请将其移动到其他地方，而不要删除它。