誰は私なのか

私は ICT エンジニアとして、スイスに拠点を置く魅力的な小型バイオ医薬品企業にて 4 年間勤務しています。その会社には非常に賢い人々が多く集まっており、何より、素晴らしい IT チームが在籍している点が一番の強みです :) 私はソフトウェア工学とサイバーセキュリティについて強い情熱を持っています。

問題の概要

2023 年終盤、バックアップシステムにおいてサーバの一つに不具合があることが検出されました。その結果、バックアップ作業が完了しませんでした。当該サーバの役割は、複雑な分析を行う実験室全体で利用されているデスクトップクライアントからデータを取得・保存する MS SQL データベースをホストすることでした（当社のような技術者にとってはあまり関心の対象とならない複雑な分析を行います）。ここで重要な点は、このサーバの許容できる停止時間（downtime）が短かったという事実です。ランニングが完了後でもデスクトップクライアントがデータベースサーバに結果を送信できない場合、すべてのデータが失われてしまいます（あるいは、ソフトウェア設計の欠陥かもしれませんが……）。なお、我々が扱うのは細胞や生物学分野であり、各回の実験は極めて重要であることを付け加えておきます。

Event Viewer を Windows で起動したところ、以下のエラーが発生していました。一時的な対策として、MS SQL のバックアップシステムを使用してデータベースをダンプし始めましたが、暫くはうまくいきました。ところが、やがて某ユーザーがチームに「一部の分析結果がアクセスできなくなった」と報告してくることになりました。

ハードディスクに不良セクタが存在するのは非常に怖い現象ですが、問題の根本原因を知ることは復旧のために有用です。

調査活動

仮説 1：EDR（これもまた、通常は AV のせいにされるものではないか？）

ちょうど 1 週間前に新しい Endpoint Detection and Response (EDR) システムの設定と導入を完了した直後であったため、私はこの問題は EDR エージェントがバックアッププロセスを過剰に分析・妨害している可能性があると考えました。つまり、単純な解決策はエージェントを無効化してバックアップを試みることです。ところが予想外に、それは機能しませんでした。さらに、EDR エージェントを完全にアンインストールしても同様でした。その時点で、私はこの問題の深層に進もうとすると、予想もしなかった冒険に巻き込まれていることに気づきました。

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

大量のエラーコードとログを精査した結果、問題の根源は VSS（Volume Shadow Copy Service）プロバイダがスナップショットを読み取れなかったことにあることが判明しました。「読み取れない」という記述を目にした時点で、多くの警戒サインが鳴り響くはずです。

VSS にご馴染みのない方のために簡潔に述べると、これは Windows がディスクボリュームのスナップショットの管理方法（どのようにバックアップを実行するか）を正確に設定・制御するための仕組みです。Microsoft のアーキテクチャ図はこちら：[ダイアグラム画像プレースホルダー]

結論として、当社のバックアップソフトウェアである Synology 製 Active Business Backup が「バックアップ」ボリュームの一部を読み取れない状態にあったと考えました。「もしかして、バックアップ自体が破損しているのか？」と推測し、バックアップサービスを停止し、VSS ボリュームのコピーを削除して再度バックアップを試みましたが、これも成功しませんでした。

仮説 3：Windows が私を救ってください

この時点で、バックアップソフトウェアは無実であり、VSS の設定もクリーンではあったにもかかわらず、スナップショットが機能しなくなっていました。VSS は内部で複数の Windows コンポーネントに依存しているため、次なる考察は「Windows 自体に問題があるのではないか」というものでした。おそらく、VSS が依存するシステムファイルの一つが破損しており、アプリケーション層で行ったどんな措置も効果が得られなかったのではないかとの考えに至りました。

過去の経験から、Windows の不具合を疑う際は以下のコマンドを実行して修復を試みるのが一般的です：

dism /Online /Cleanup-Image /RestoreHealth

また、破損ファイルの検出のためにも以下のようなコマンドでスキャンを行うことができます： [コマンドプレースホルダー]

したがって、試行は行われましたが、確かに何らかの問題を検出したものの、修復することができませんでした。

仮説 4：怪しい SQL パッチ

そこで、私は一度後退して、直近数月の間このサーバでどのような変更があったかを把握することにしました。その際、保守担当者の方がデータベースを「パッチ適用」するための SQL スクリプトを実行してきたことを思い起こしました。日付の照合を行うと、問題が顕在化した時期とパッチ適用時期が驚くほど一致していました。当時の私の仮説は、

DROP/CREATE

の呼び出しが何らかの原因で破損をトリガーしたというものでした。 hindsight に立ち返れば、SQL Server がページを破損させるメカニズムとしては T-SQL が直接不良セクタを書き込むわけではないため、この説明は厳密には正しくありませんでした。しかし、タイミングは確かに現実的でした。おそらくそのパッチは auditing ページに対する重い I/O 操作を行っており、長らくアクセスされてこなかったページが対象となっていました。それによって、磁気信号が既に弱体化していたセクタが浮き彫りになったのです。ディスク自体が寿命を迎えていたのです。パッチ適用という行為が、それを無視できない状態に追い込んだと言えます。

解決策

問題の原因を特定した今、破損したディスクページを修復するためにはオフラインツールを使用する必要があることが明らかになりました。同時に、当該ディスクの交換も検討すべきだろうと考えました。そこで、当該サーバのハードウェアベンダーである Dell に連絡し状況説明を行いました。その結果、Dell 側は「はい、もちろん新しいハードディスクをお送りできますが、それ以上のサポートは致しかねます」という回答をいただきました（なお、このサーバはまだ保証期間内にありました）。これは予想外でしたが、仕方ありませんでした。

方針としては、データベースがページを書き込み中に破損させた不良セクタを修復し、その後データを新しいディスクへ移行することを目指しました。ちょうど同時に、このディスクからデータを回復させることへの希望もほぼ失いました。

それでも、いくつかのソフトウェアを試み、以下の有料製品にも投資しました：

• EaseUS: 有名な EaseUS 社製ツールです。有料版では修復に失敗しましたが、ご参照のために購入しました :)
• HDD Regenerator (Dmitriy Primochenko): 探索の結果、このツールが磁気ディスクの不良セクタからデータを回復するための特殊アルゴリズムを使用することが記載されていました。ウェブサイトの雰囲気は詐欺のような印象を受けましたが、もはや失うものが何もない状況だったため試してみることにしました。そして、なんと成功したのでした。

その仕組みが理解できませんでした。不良セクタとは、物理的に損傷しているか、読み取れないデータを保持している状態です。ソフトウェアがハードウェア問題を修復する方法があるのでしょうか。「RAM を追加する」ような感覚さえ覚えました。さらなる調査を行った結果、同様の疑問を持つ他のユーザーも存在することが判明し、その共通認識は以下の通りでした：ソフトウェアは物理的にプラッタ（ディスク本体）を修復するわけではありません。実際に行うのは、特定の磁気パターンを用いてセクタを繰り返し読み取り書き込みを行うことです。多くの「不良」とされるセクタは物理的に破壊されたわけではなく、弱磁化しており、ドライブのエラー訂正機能がデータを信頼性高く復元できないレベルまで信号が衰えているという状態です。強力な清潔な信号でセクタを書き直すことで、再び読み可能な状態に回復させられます。もしセクタが物理的に破損している場合、ドライブのファームウェアは最終的に予備プールからの自由空間へ再マップし、OS は健全なセクタとして認識することになります。

では、どうやってデータベースとその内部データを回復することができたのでしょうか？大部分のデータはまだ完形で保存されていた可能性が高く、読み取れないのはごく一部のセクタに限られていたと考えられます。これらのセクタが修復された（強力な信号で書き直された）か、またはドライブファームウェアによって再マップされた後、ファイルシステムとデータベースエンジンがファイル全体を読み込むことが再び可能になりました。SQL Server ページにはチェックサムも設定されているため、ページが「読み取れない」ではなく「誤ったデータ」として戻ってきた場合でも、すぐに検知できていたはずです。幸運にも、破損は磁気信号レベルの現象であり、「プラッタ自体が傷ついている」ような致命的な物理損傷ではありませんでした。

結論

このディスクは恐らく寿命を迎えていたのです。調査の結果、RAID でもこれを救うことはできなかったことが判明しました。RAID はドライブ障害に対する防護策ではありますが、各ミラーへ忠実に複製される沈黙的なページ破損に対しては無力です。SQL パッチ適用時、auditing ページに対する重い I/O 操作が行われ、長らくアクセスされてこなかったページが対象となり、静かに信号衰壊していたセクタが浮き彫りになったと考えられます。

私は何を学んだでしょうか：

• バックアップだけでは不十分です。バックアップから実際に復元できることを確認し、復元されたデータの質も検証する必要があるのです。我々の場合は幸運でした。
• ベンダーの技術者がプロダクションデータベースに対して「小さなパッチ」を実行する場合でも、これは本格的な変更と同様に扱うべきです：事前にはバックアップを、実行中は監視を、事後には検証を行います。
• Dell のエンタープライズサポートは喜んで新しいディスクを送付しますが、データ回復に関する責任はお客様自身にあります。
• そして最後に：好奇心を持ってください。すべての手がかりが死地となる中、掘り下げることに躊躇せず、怪しい外観の 90 ドルツールにも開放的であることは、解決プロセスの半分を占めていたと言えます。

サイドノート

当該ディスクは SATA インターフェースが特殊であったため、サーバから取り出し、別の OS を動作させる他のコンピュータに接続して復旧作業を行いました。不良セクタの回復時の冷却設置状況の写真は以下です：[画像プレースホルダー]