Windowsに繋いでも読めない
社内のLinuxサーバーが起動しなくなった。ディスクを抜いてWindowsのPCに繋げば中身が見えるだろう——見えません。
Linuxで一般的に使われるファイルシステム（ext4、XFSなど）は、Windowsが標準では扱えません。 接続すると「ディスクを初期化する必要があります」といったメッセージが出ます。
ここで実行すると、管理情報が書き換えられて復旧が困難になります。 NASの場合とまったく同じ構造の落とし穴です（NAS本体が壊れた）。
認識されないのは異常ではありません。そういう作りです。
構成が複雑になっている
サーバー用途では、ディスクがそのまま1つのボリュームになっているとは限りません。
| 仕組み | 内容 |
|---|---|
| ソフトウェアRAID | 複数のディスクを束ねて冗長化する（OS側で管理） |
| ハードウェアRAID | RAIDカードが管理する。カードが壊れると同型が必要になる場合がある |
| LVM（論理ボリューム管理） | 物理ディスクをまとめ、論理的に区切って使う |
| 仮想化 | 1つのファイル（ディスクイメージ）の中に、仮想マシンのディスク全体が入っている |
これらが組み合わさっていると、ディスク1本を取り出しても、それ単体では意味を持ちません。
だからこそ、触る前に構成を記録してください。
- ディスクの搭載位置（ベイ番号）とシリアル番号の対応
- RAIDの構成（種別、ディスク本数）
- RAIDカードのモデルと設定
- LVMの構成が分かる資料（あれば）
- 仮想化基盤の種類とバージョン
「あとで分かるだろう」は通用しません。 同じ型番のディスクが並んでいると、外見では区別できません。
仮想マシンの場合
仮想マシンのディスクは、ホスト側から見ると1つの大きなファイルです。
このファイルが壊れると、中の仮想マシン全体が起動しなくなります。 逆に言えば、ファイルさえ無事なら、別のホストに持っていって起動できる可能性があります。
確認の順番。
1. ホスト側のストレージは正常か（物理層の問題ではないか）
2. ディスクイメージのファイルは存在するか、サイズは正常か
3. スナップショットや差分ファイルが残っていないか
スナップショットが絡んでいる場合、ファイルの依存関係が複雑になります。 親ファイルと差分ファイルの関係が崩れると、単体では起動できません。構成を理解せずにファイルを移動・削除しないでください。
RAIDの再構築を急がない
縮退（デグレード）している状態でリビルドを開始すると、残りのディスクに強い負荷がかかります。
長年稼働してきたディスクは、多くが同時期に導入され、同程度に消耗しています。リビルド中の高負荷で、もう1本が脱落する——これが実際に起きます（RAIDのリビルドに失敗したときの対応）。
重要なデータがあるなら、リビルドの前に現状のバックアップを確保するか、業者に相談してください。
複数のディスクが同時に脱落している場合は、特に危険です。 その状態でのリビルドは、状況を悪化させるだけになることがあります。
業務システム特有の判断
個人のPCと違い、復旧作業と並行して決めなければならないことがあります。
# 業務を止めるか、動かすか
止めれば証跡が保全され、復旧の選択肢が広がります。 一方で、業務が止まる損失があります。
復旧の観点だけで言えば、止めるほうが有利です。 稼働を続ければ書き込みが発生し、救出できる領域が減ります。この判断は、技術ではなく経営の判断です。
# 情報漏えいの可能性はあるか
故障ではなく、不正アクセスやランサムウェアが疑われる場合、まったく別の対応が必要になります。
個人データの漏えいが疑われる場合、個人情報保護委員会への報告と本人への通知が義務です。速報はおおむね3〜5日以内という短い期限です（業務データが流出したかもしれない、ファイルが暗号化されて開けない）。
そして、復旧作業が証跡を消します。 電源を落とせばメモリ上の情報が消え、再構築すれば侵入経路の手がかりが消えます。
「まず復旧」ではなく、「何が起きたかを説明できる状態を保ちながら復旧する」という順番が必要になります。
# 誰が何をしたかを記録する
対応の過程を記録してください。 いつ、誰が、何をしたか。後から報告する際、これが説明の土台になります。
アクセス権とログの設計そのものが、事故対応の質を決めます（業務用NASで「誰が消したか分からない」を防ぐ）。
業者に依頼する場合
サーバー・仮想環境の復旧に対応しているかを、最初に確認してください。 個人向けの復旧と、必要な技術が異なります。
伝えるべき情報。
- OSとバージョン
- ファイルシステム（ext4、XFS など分かる範囲で）
- RAIDの種別と構成、ハードウェアRAIDならカードのモデル
- LVMの使用有無
- 仮想化基盤の種類
- 症状と、発生の経緯
- これまでに試した操作（リビルドを試みた、Windowsに繋いだ、など）
- 個人データを含むか、秘密保持の要件があるか
最後の項目は必ず伝えてください。 委託先の監督という論点があり、秘密保持契約や作業範囲、データの取り扱いと消去について事前に取り決める必要があります。
伝え方の整理は復旧業者に伝えるべきこと、費用感はデータ復旧の費用相場にまとめています。
起きる前に決めておくこと
バックアップからの復元を、実際に試したことがあるか。 これが分かれ目です。
「バックアップは取っている」という状態と、「バックアップから業務を再開できる」という状態は違います。手順を知っている人が一人しかいない、あるいは誰も試したことがない——という組織は珍しくありません。
RAIDはバックアップではありません（バックアップとRAIDの違い）。スナップショットも同じ筐体の中にあります。 別の場所に、オフラインのコピーを持ってください（バックアップは「取っているつもり」が一番危ない）。
よくある質問
# Q. LinuxのPCを用意すれば読めますか？
構成が単純なら読める場合があります。 ただしLVMやRAIDが絡むと、正しい手順で構成を認識させる必要があり、操作を誤ると状態が悪化します。 重要なデータなら試行を控えてください。
# Q. RAIDカードが壊れました。同じカードを買えば戻りますか？
同一メーカー・同一モデルであれば構成を引き継げる場合があります。 ただし世代やファームウェアの違いで非対応のこともあります。メーカーの資料で確認してください。
# Q. 仮想マシンのファイルをコピーしておけばバックアップになりますか？
稼働中のコピーは、整合性が取れていない場合があります。 仮想化基盤が提供するバックアップ機能を使うか、停止した状態でコピーしてください。
# Q. クラウド上のサーバーでも同じ考え方ですか？
物理層は事業者が管理しますが、「削除・上書き・暗号化はそのまま反映される」という点は同じです。スナップショットの保持期間と、別リージョン・別アカウントへの退避を確認してください。