本番環境のディスク破損からの復旧：ハードウェア障害のケーススタディ

本番サーバーが故障すると、プレッシャーは非常に大きくなります—特にそのサーバーが実験装置にとって重要なデータベースをホストしており、ダウンタイムが永久的なデータ損失を意味する場合はなおさらです。多くのエンジニアにとって、実際のハードウェア破損に初めて直面することは、OSIモデルの物理層の脆弱性に対する警鐘となります。

本稿では、WindowsベースのMS SQLサーバー上でハードドライブが破損した実際のシナリオを取り上げ、根本原因を特定するために取った診断プロセスと、データ復旧に使用した非従来型の手法について検証します。

症状：バックアップ失敗とデータ損失

この問題は最初、システムのバックアッププロセスが失敗する形で現れました。当初、チームはMS SQLの内部バックアップシステムを使用してデータベースをダンプすることで迅速な対処を試みました。これにより一時的に機能しましたが、ユーザーからは特定の解析がもはや利用できなくなったとの報告がすぐに上がってきました。

Windows Event Viewer を調査したところ、チームは低レベルのディスクエラーを発見しました。本番環境では、これは重大な警告サインです。コミュニティの専門家が指摘しているように、システムイベントログに記録されたディスクエラーは通常、I/O層や低レベルクラスドライバ（例：msahci.sys）から発生し、ファイルシステムやアプリケーション層より下位に問題があることを示しています。

診断の旅路

ハードウェア障害の根本原因を特定するには、しばしば除外法が用いられます。このケースでは、調査は主に4つの方向性に沿って進められました：

1. EDR 仮説

1週間前に新しいエンドポイント検知・応答（EDR）システムが導入されたため、当初はセキュリティエージェントがバックアッププロセスに干渉しているのではないかと疑われました。しかし、EDR エージェントを無効化し完全にアンインストールしても結果は得られませんでした。

2. ボリュームシャドウコピーサービス（VSS）

さらにログ解析を進めると、ボリュームシャドウコピーサービス（VSS）がスナップショットを読み取れないことが判明しました。VSS はバックアップ用にディスクボリュームのスナップショットを管理する Windows のフレームワークです。スナップショットを読み取れないことは、バックアップソフトウェア自体ではなく、基盤となるストレージに問題があることを強く示唆しています。

3. システムファイルの破損

Windows のシステムファイルが破損している可能性を疑い、チームは dism /Online /Cleanup-Image /RestoreHealth と sfc /scannow を実行しました。ツールは問題を検出したものの、修復できず、破損が OS レベルよりも深いことを示唆しました。

4. 「SQL パッチ」トリガー

タイムライン分析の結果、技術者が新しいクライアントアプリケーションバージョン向けにデータベースをパッチする SQL スクリプトを最近実行したことが判明しました。T‑SQL が直接ディスクに不良セクタを書き込むことはできませんが、このパッチにより長らくアクセスされていなかった監査ページへの大量 I/O が発生したと考えられます。この動作により、磁気信号が減衰したセクタが露呈し、ディスクの故障を無視できない状態となりました。

解決策：「ハードウェア修復」のメカニズム

ディスクが保証対象であったため、ベンダー（Dell）は交換用ドライブを提供しましたが、データ復旧に関する支援は行いませんでした。その後、チームはさまざまなソフトウェアソリューションを試み、最終的に HDD Regenerator というツールで成功を収めました。

ソフトウェアがハードドライブを「修復」する仕組み

ソフトウェアが物理的なディスクを修復できるとは直感に反するように思えるかもしれません。しかし、このプロセスは主に2つのメカニズムに依存しています：

シグナル復元: 多くの「不良」セクタは物理的に傷があるわけではなく「磁化が弱い」状態です。特定の磁気パターンでセクタを繰り返し読み書きすることで、ソフトウェアはシグナルをドライブのエラー訂正が確実にデータを回復できるレベルまで復元できます。
ファームウェアによるリマッピング: セクタが実際に物理的に損傷している場合、ドライブ内部のファームウェアがそれを不良としてマークし、予約プールの予備セクタへ論理アドレスをリマップします。

破損が物理的なプラッタレベルではなく磁気シグナルレベルで発生していたため、チームはセクタを復元し、データベースを新しいディスクへ正常に移行することができました。

技術的事後検証と学んだ教訓

RAID は万能ではない

一般的な誤解として、RAID（Redundant Array of Independent Disks）はすべてのデータ損失を防ぐと考えられています。RAID 1（ミラーリング）は全ドライブ故障からは保護しますが、「サイレント」な破損や読み取りエラーとして報告される不良ブロックを必ずしも防げません。あるコミュニティ貢献者が指摘したように、真のハードウェア RAID コントローラはメタデータ上で不良ブロックをマークできますが、ミラーされた欠陥のリスクは残ります。

SMART 監視の重要性

このケースで最も重大な見落としの一つは、事前のハードウェア監視が欠如していたことです。S.M.A.R.T.（Self-Monitoring, Analysis, and Reporting Technology）診断は、しばしば故障前の警告を提供します。「Current Pending Sectors」（C5）や「Reallocated Sectors Count」（05）といった属性を監視していれば、本番データベースがアクセス不能になる前に故障ドライブをチームに警告できた可能性があります。

システム管理者への重要なポイント

リストアの検証、バックアップだけでなく: バックアップが成功してもリストアが成功するとは限りません。リストアしたデータの整合性を定期的にテストしましょう。
パッチは大きな変更として扱う: ベンダーが本番データベース上で実行するスクリプトはすべて高リスクイベントとして扱い、実行前にバックアップし、実行中は監視し、実行後に検証してください。
ハードウェアライフサイクル管理: 現代の本番環境では、SSD/NVMe への移行はパフォーマンス向上だけでなく、可動部品や磁気劣化に伴う故障率が大幅に低減する点でも推奨されます。
好奇心を持ち続ける: 標準ツールが失敗したとき、たとえ古く見える専門的な復旧ツールを探求することが、重要なデータを復旧する鍵になることがあります。