2006年10月17日
川俣晶の縁側ソフトウェア技術雑記 total 5517 count

まさに疲労困憊・ほんとんど復旧に1日を費やしたファイルサーバHDDトラブルの顛末

Written By: 川俣 晶連絡先

 完全に1日仕事が止まった感があります。

 ファイルサーバのトラブルについて、顛末を簡単にメモっておきます。

前提 §

 Windows 2000 Server SP4のファイルサーバ。

 IDE HDD×3のRAID5 (Windowsの機能で実現)

 1日1回早朝に自動リブートを実施。

トラブルの発覚 §

 本日の朝、一部のファイルの読み書きを行うとエラーが起こる現象が発生。

 テスト的にファイルを作成すると正常に読み書きできる。

イベントログの調査 §

 以下のような記録をシステムログに確認。

ディスクのファイル システム構造は壊れていて使えません。 chkdsk ユーティリティをボリューム N: で実行してください。

 更に遡ると、1日前の日付で以下のような記録をシステムログに確認。

dmboot: ボリューム Raid1 (マウントポイントなし) は失敗した冗長モードで開始しました。

chkdsk実行 §

 chkdskしろというので、chkdsk n: /fを実行。

 結果として、大量の修復メッセージが出たものの、サルベージされたファイルは1つのみ。

 しかし、内容を確認すると、昨日作成、または修正されたファイルには以下の問題があった。

  • ファイルの一部または全体が別のファイルの内容に置き換わっている
  • ファイルそのものが存在しない

対策 §

 問題は昨日以降の作成されたファイルでのみ発生しているので、それに該当するファイルをバックアップより復旧。

整理 §

 時系列で見ると以下のようになる。

  • 10/16 05:00 自動リブート実行
  • 再起動後、イベントログに「dmboot: ボリューム Raid1 (マウントポイントなし) は失敗した冗長モードで開始しました。」という記録が残る
  • その後、問題なく使用することができていた。
  • 10/17 05:00 自動リブート実行
  • 一部のファイルが壊れ、利用できなくなっていた。該当ファイルは、10/16 05:00以降に新規作成された、または修正されたファイル/ディレクトリと推定

疑問 §

 10/16 05:00~10/17 05:00にシステムを問題なく使用することができた。その間に読み書きしたファイルの量はメモリ上のキャッシュで対処できるサイズではない。従って、ディスクシステムは本来の機能を発揮していたことになる。

 それにも関わらず、10/17 05:00の自動リブートだけで全て壊れてしまうのはなぜか?

 もしや、10/16 05:00の自動リブートで3本のHDDのうちの1本が認識されず、2本だけで稼働していたのだろうか? (RAID5なら不可能ではない)

 そして、次のリブート時に認識されなかったHDDが再認識され、3本体制に戻ったのだろうか? その際、1日分のファイルが更新された2本のHDD+1日分のファイルが未更新のHDD1本の組み合わせとなって、結果としてファイルシステムが壊れた形になったのだろうか?

その他 §

 過去、非常にレアな頻度で同様のファイル破壊が起きたことがあるが、同じ原因だろうか?

 有意義な対策として考えられるものは何だろうか? イベントログを監視して、当該エントリが記録された場合は管理者に通知するシステムが有効だろうか? しかし、同様の問題が起きたとき、常に同じイベントがログに記録されるのだろうか?

結論 §

 結論は無し!

 メモのみ。