在几周内，我们的Exchange服务器的备份作业无法完成，导致我们正常的空日志驱动器填满了Exchange卸载数据库和logging重放日志文件的各种错误的问题。 令人痛心的是，备份团队中没有人能够正确地工作，所以周末我们有一个失败的情况，由于有大约100GB的日志，一般在〜3GB左右，所以卸载了大约40个数据库。 这导致每个周末工作的人都不去看这个问题的历史，而不是联系其他任何人，在团队中的每个人被指示不要重新安装所有的数据库并且每天打电话之后，启用循环日志logging。
我们还没有听说过任何用户的数据丢失，但是所有的数据库都遇到这种情况，而且有关于日志logging失败，重播失败和意外失败的抱怨，我担心可能会有一些。
除了解雇备份团队之外，周末的监控人员和pipe理员决定在备份之间花费大量时间来启用循环日志logging，而不需要将备份日志保存到任何地方，以备需要从备份中恢复并获得我们可能支持的任何内容，我最好的行动来确定我们是否失去了什么？
在发生这种事情的时候，是否有可能埋藏在长达六小时的300万条logging中的特殊事件？ 正在执行完整性检查build议？ 碎片整理，在线还是离线？
在Exchange服务器上，下面是典型的事情，我已经剥离了事件源和ID，因为一切似乎都是通用的，对于确定事情是否真的超级南，或者只是毁了我的星期一，
在“时间”在此服务器上的Microsoft Exchange信息存储数据库“数据库”副本遇到一个严重的错误，导致它终止其function活动。 重新安装尝试返回的错误是“这个邮箱数据库（DATABASE）只有一个副本，自动恢复不可用”。 有关其他存储和“ExchangeStoreDb”事件，请参阅服务器上的事件日志以获取有关故障的更多特定信息。
信息存储 – 数据库（9564）数据库：尝试写入文件“F：\ Logs \ DATABASE \ E0Etmp.log”偏移量为1048576（0x0000000000100000）0（0x00000000）字节失败0.000秒后系统错误112（0x00000070 ）：“磁盘空间不足”。 写操作将失败，错误-1808（0xfffff8f0）。 如果此错误仍然存在，则文件可能已损坏，可能需要从以前的备份中恢复。
信息存储 – DATABASE（9564）数据库：无法创build新的日志文件，因为数据库无法写入日志驱动器。 该驱动器可能是只读的，磁盘空间不足，configuration错误或损坏。 错误-529。
信息存储 – DATABASE（9564）DATABASE：“F：\ Logs \ DATABASE \”中的日志文件序列由于致命错误而被暂停。 使用此日志文件序列的数据库不能进一步更新。 请更正问题并重新启动或从备份中恢复。
信息存储 – 数据库（9564）数据库：数据库恢复/还原失败，出现意外错误-510。
Microsoft Exchange邮箱复制服务无法处理邮箱数据库中的作业。 数据库：数据库错误：MapiExceptionMdbOffline：无法打开邮件存储。 （hr = 0x80004005，ec = 1142）诊断上下文：
在'TIME'时，该服务器上的数据库'DATABASE'的副本在装载操作期间遇到错误。 有关更多信息，请参阅服务器上的“ExchangeStoreDb”或“MSExchangeRepl”事件的事件日志。 安装操作将被自动重试。
这是一个独立的服务器，所以唯一的一个复制错误似乎是预料之中的。 在发生这种情况时，也logging了很多客户端访问错误，我省略了这些错误。
如果有的话，我倾向于认为你的数据丢失最小。 我意识到这听起来非常极端，但我认为的基础是，当磁盘填满时，新数据停止进来。 即使你丢失了数据，丢失的数据也几乎可以肯定是服务器在磁盘满状态之前收到的数据。
当磁盘被填满时，可扩展存储引擎（ESE）会在卸除数据库之前将日志数据刷新到每个数据库的备用事务日志。
交易所拆除了商店。 从互联网进入的任何邮件将由您的辅助MX（或发送方，如果没有）进行排队，并在稍后发送，或由发送方的服务器进行NDR（在这种情况下发送方将意识到失败）。 我猜想有一个机会 ，发件人会从队列中删除一个消息，但不是你的问题。
Outlook客户端将无法连接到他们的信息存储数据库，所以没有任何来自内部客户的新邮件可能会丢失。
您提到了事务日志重播失败。 这听起来有点令人不安，但不知道这些失败的程度，很难说。 由于事务日志重放的性质（即，向数据库提交最近写入的未提交数据），重播失败对旧的存储数据有影响的机会相当低。 如果用户没有看到邮箱中最新数据的问题，那么他们可能不会晚些时候。
实际上没有与磁盘满的情况有关的数据库碎片相关的问题。 写入数据库的模式不会因为事务日志卷被填满而改变。 在线碎片整理仍然会正常进行。 脱机碎片整理通常不再需要或由Microsoft推荐。
可以想象，如果数据库存储在填充EDB文件的文件系统可能具有碎片的卷上，但一般来说，Microsoft不build议对容纳Exchange数据库的卷进行碎片整理。 如果你想确定，你可以用contig.exe打你的.EDB文件来分析它们的碎片。
ESE 非常强大。 我想你可能没关系。