Exchange2013データベースでのログの失敗によるデータ損失を特定します

Question

数週間にわたって、Exchangeサーバーでバックアップジョブが完了しないという問題が発生し、通常は空のログドライブがいっぱいになり、Exchangeがデータベースをマウント解除し、ログファイルの再生に関するさまざまなエラーをログに記録しました。残念ながら、バックアップチームの誰も適切に仕事をしていなかったため、週末に失敗した状況で、最大100GBのログ（通常は最大3GB）が原因で最大40のデータベースがマウント解除されました。これにより、週末に働くすべての人が問題の履歴を確認せず、他の人に連絡するのではなく、チームの全員が指示された後に循環ログを有効にし、すべてのデータベースを再マウントして1日と呼びます。

どのユーザーからもデータの損失についてはまだ聞いていませんが、すべてのデータベースでこれが発生し、ログの失敗、再生の失敗、予期しないマウント解除に関する苦情があるという事実があります。

バックアップチームを解雇する以外に、週末のモニターと管理者は、バックアップから復元して何でも取り戻す必要がある場合に備えて、バックアップの間にかなりの時間が経過した後、ログをどこにも保存せずに循環ログを有効にすることを決定しました。私たちが何かを失ったかどうかを判断するための私の最善の行動方針は？

これが行われている間、6時間のセクションにまたがる3,000,000のログエントリに埋め込まれる可能性のある特定のイベントはありますか？整合性チェックを実行することをお勧めしますか？デフラグ、オンラインまたはオフライン？

Exchangeサーバーでは、通常、次のことが発生します。すべてが一般的であり、実際に南に移動したのか、月曜日を台無しにしたのかを判断するのにほとんど役立たないため、イベントソースとIDを削除しました。

'TIME'に、このサーバー上のMicrosoftExchangeインフォメーションストアデータベース 'DATABASE'コピーで重大なエラーが発生し、機能アクティビティが終了しました。再マウントの試行によって返されたエラーは、「このメールボックスデータベース（DATABASE）のコピーは1つだけです。自動回復は使用できません。」でした。他のストレージについてはサーバーのイベントログを、障害に関するより具体的な情報については「ExchangeStoreDb」イベントを参照してください。
インフォメーションストア-DATABASE（9564）DATABASE：オフセット1048576（0x0000000000100000）のファイル "F：\ Logs\DATABASE\E0Etmp.log"に0（0x00000000）バイトで書き込もうとしましたが、0.000秒後にシステムエラー112（0x00000070）で失敗しました）： "ディスクに十分な容量がありません。 "。書き込み操作はエラー-1808（0xfffff8f0）で失敗します。このエラーが続く場合は、ファイルが破損している可能性があり、以前のバックアップから復元する必要がある可能性があります。
インフォメーションストア-DATABASE（9564）DATABASE：データベースがログドライブに書き込めないため、新しいログファイルを作成できません。ドライブが読み取り専用であるか、ディスクスペースが不足しているか、構成が間違っているか、破損している可能性があります。エラー-529。
インフォメーションストア-DATABASE（9564）DATABASE：「F：\ Logs\DATABASE \」のログファイルシーケンスは、致命的なエラーのために停止されました。このログファイルシーケンスを使用するデータベースでは、これ以上の更新はできません。問題を修正し、バックアップから再起動または復元してください。
インフォメーションストア-データベース（9564）データベース：データベースの回復/復元が予期しないエラー-510で失敗しました。
Microsoft Exchangeメールボックスレプリケーションサービスは、メールボックスデータベース内のジョブを処理できませんでした。データベース：DATABASEエラー：MapiExceptionMdbOffline：メッセージストアを開くことができません。（hr = 0x80004005、ec = 1142）診断コンテキスト：
「TIME」で、このサーバー上のデータベース「DATABASE」のコピーで、マウント操作中にエラーが発生しました。詳細については、サーバーのイベントログで「ExchangeStoreDb」または「MSExchangeRepl」イベントを参照してください。マウント操作は自動的に再試行されます。

これはスタンドアロンサーバーであるため、1つのコピーエラーのみが予想されるようです。また、これが発生している間にログに記録されたクライアントアクセスエラーも多数ありますが、省略しました。

Evan Anderson · Accepted Answer

データの損失は最小限に抑えられていると思う傾向があります。それはかなり極端に聞こえますが、私の意見の根拠は、ディスクがいっぱいになると新しいデータが入ってきなくなったということです。データが失われたとしても、失われるのはほぼ確実に、ディスクがいっぱいになる直前にサーバーが受信したデータです。

ディスクがいっぱいになった時点で、Extensible Storage Engine（ESE）は、データベースをマウント解除する前に、ログデータを各データベースの予約トランザクションログにフラッシュしていました。
Exchangeは店舗を降ろしました。インターネットから着信するメールはすべて、セカンダリMX（または送信者がない場合は送信者）によってキューに入れられて後で送信されるか、送信者のサーバーによってNDRされます（この場合、送信者は障害を認識します）。 chance送信者が、NDRを使用せずにキューからメッセージをドロップする可能性があると思いますが、それはほとんど問題ではありません。
Outlookクライアントはインフォメーションストアデータベースに接続できないため、内部クライアントからの新しい電子メールが失われることはありませんでした。

トランザクションログの再生の失敗についておっしゃいました。それは少し不安に聞こえますが、それらの失敗の程度を知らなければ、言うのは難しいです。トランザクションログの再生（つまり、最近書き込まれたコミットされていないデータをデータベースにコミットする）の性質により、古い保存データに影響を与える再生の失敗の可能性はかなり低くなります。ユーザーがメールボックス内の最新のデータに問題がない場合は、おそらく後で問題が発生することはありません。

ディスクの満杯状態に関連するデータベースの断片化に関連する懸念は実際にはありません。トランザクションログボリュームがいっぱいになったため、データベースへの書き込みパターンは変更されません。オンラインでの最適化は、通常どおりに行われます。オフラインでの最適化は、通常、Microsoftによって不要または推奨されていません。

EDBファイルがファイルシステムの断片化を引き起こす可能性があることを埋めたボリュームにデータベースが格納されている場合、考えられますが、一般的に、MicrosoftはExchangeデータベースを保持するボリュームの最適化を推奨していません。 .EDBファイルを contig.exe 確認したい場合は、断片化を分析します。

ESEは本当に堅牢です。おそらく大丈夫だと思います。