在过去的几周里，我们的 Exchange 服务器出现了备份作业无法完成的问题，这导致我们通常为空的日志驱动器被填满，以至于 Exchange 卸载了数据库并记录了有关重放日志文件的各种错误。遗憾的是，备份团队中没有人正确地完成他们的工作，所以在周末我们遇到了一个故障情况，由于日志大约有 100GB，而通常只有 3GB，因此卸载了大约 40 个数据库。这导致周末工作的每个人都没有查看问题的历史记录，他们没有联系其他人，而是在团队中每个人都被告知不要这样做之后启用循环日志记录，重新安装所有数据库并结束一天的工作。
我们还没有听说任何用户遇到数据丢失的情况，但事实上所有数据库都遇到了这种情况，并且有关于日志记录失败、重播失败和意外卸载的投诉，我担心可能会出现这种情况。
除了解雇备份团队、周末监控员和管理员（在两次备份之间经过相当长一段时间后决定启用循环日志记录，而不在任何地方保存日志，以防需要从备份中恢复并取回我们可以恢复的任何东西）之外，我最好的行动方案是什么来确定我们是否丢失了什么？
在发生这种情况时，是否有特殊事件可能隐藏在长达六小时的 3,000,000 条日志条目中？建议执行完整性检查吗？碎片整理，在线还是离线？
在 Exchange 服务器上，通常会发生以下情况，我删除了事件源和 ID，因为一切似乎都是通用的，对于确定事情是否真的出了问题或者只是毁了我的星期一没有多大帮助：
在 'TIME'，此服务器上的 Microsoft Exchange 信息存储数据库 'DATABASE' 副本遇到严重错误，导致其终止其功能活动。重新安装尝试返回的错误是“此邮箱数据库 (DATABASE) 只有一个副本。无法自动恢复。”。有关故障的更多具体信息，请参阅服务器上的其他存储和“ExchangeStoreDb”事件的事件日志。
信息存储 - 数据库 (9564) 数据库：尝试将 0 (0x000000000100000) 字节写入文件“F:\Logs\DATABASE\E0Etmp.log”，偏移量为 1048576 (0x000000000100000)，0.000 秒后失败，系统错误 112 (0x00000070)：“磁盘空间不足。”写入操作将失败，错误代码为 -1808 (0xfffff8f0)。如果此错误持续存在，则文件可能已损坏，可能需要从以前的备份中恢复。
信息存储 - 数据库 (9564) 数据库：无法创建新的日志文件，因为数据库无法写入日志驱动器。驱动器可能是只读的、磁盘空间不足、配置错误或损坏。错误 -529。
信息存储 - 数据库 (9564) 数据库：由于致命错误，“F:\Logs\DATABASE\”中的日志文件序列已停止。使用此日志文件序列的数据库无法进一步更新。请更正问题并重新启动或从备份中恢复。
信息存储 - 数据库 (9564) 数据库：数据库恢复/还原失败，出现意外错误 -510。
Microsoft Exchange 邮箱复制服务无法处理邮箱数据库中的作业。数据库：DATABASE 错误：MapiExceptionMdbOffline：无法打开邮件存储。（hr=0x80004005，ec=1142）诊断上下文：
在 'TIME'，此服务器上数据库 'DATABASE' 的副本在安装操作期间遇到错误。有关详细信息，请查阅服务器上的事件日志中的“ExchangeStoreDb”或“MSExchangeRepl”事件。将自动重试安装操作。
这是一台独立服务器，因此似乎只会出现一次复制错误。发生这种情况时还记录了大量客户端访问错误，我已将其省略。
答案1
我倾向于认为您的数据丢失很少，如果有的话。我知道这听起来很极端，但我的观点的基础是当磁盘已满时，新数据停止输入。即使您确实丢失了数据，丢失的也几乎肯定是服务器在磁盘已满之前立即收到的数据。
当磁盘写满时，可扩展存储引擎 (ESE) 会在卸载数据库之前将日志数据刷新到每个数据库的备用事务日志中。
Exchange 卸载了存储。任何来自互联网的邮件都会被你的辅助 MX（或发件人，如果你没有）排队并稍后发送，或者被发件人的服务器 NDR（在这种情况下，发件人会意识到失败）。我想有一个机会发件人可能会从队列中删除一条消息而不进行 NDR，但这并不是您的问题。
Outlook 客户端无法连接到其信息存储数据库，因此来自内部客户端的新电子邮件可能不会丢失。
您提到了事务日志重播失败。这听起来确实有点令人不安，但如果不知道这些失败的程度，就很难说。由于事务日志重播的性质（即向数据库提交最近写入的未提交数据），重播失败对较旧的存储数据产生影响的可能性相当低。如果用户没有发现邮箱中的最新数据存在问题，那么他们以后可能也不会发现。
磁盘已满的情况确实与数据库碎片无关。数据库的写入模式不会因为事务日志卷已满而改变。在线碎片整理仍将正常进行。Microsoft 通常不再需要或推荐离线碎片整理。
可以想象，如果数据库存储在已填满 EDB 文件的卷上，则可能会出现文件系统碎片，但一般来说，Microsoft 不建议对包含 Exchange 数据库的卷进行碎片整理。您可以使用contig.exe如果你想确定的话，可以分析它们的碎片。
ESE 是真的强健。我想你可能没事。