午前2時の悪夢：データが消える瞬間
ある火曜日の午前2時、ステージングサーバーで定期的なクリーンアップを行っていた時のことです。fdiskコマンドの打ち間違いと、不用意なw（書き込み）を実行した直後、2TB hostのデータドライブのパーティションテーブルが消え去りました。カーソルは淡々と点滅していましたが、数ヶ月分の未同期作業が消滅したことに私はまだ気づいていませんでした。これは演習ではなく、本番環境に近いシステムで起きた重大なミスでした。
3年間で10以上のLinux VPSインスタンスを管理してきましたが、経験は自信を生む一方で、疲労は危険な変数となります。もしあなたが誤ったマウントポイントでrm -rfを実行したり、パーティションが消えるのを目の当たりにしたりしたなら、まずはキーボードから手を離してください。データはおそらくまだ物理セクタ上に存在しています。それを見つけ出すための「地図」を再構築すればいいのです。
根本原因：削除時に何が起きているのか？
fdiskやpartedでパーティションを削除しても、オペレーティングシステムは即座にファイルを消去するわけではありません。単に「目次」を破壊するだけです。GPTやMBRディスクでは、パーティションテーブルがカーネルに対してファイルシステムの開始位置と終了位置を正確に伝えます。このテーブルがないと、カーネルはディスク全体を未割り当て領域として扱います。
ファイルの削除も同様のロジックに従います。Ext4ファイルシステムでは、iノード（メタデータ）が利用可能としてマークされますが、生のデータブロックは新しいデータで上書きされるまでそのまま残ります。そのため、復旧の第一鉄則は**「直ちにディスクへの書き込みを停止すること」**です。システムログや一時ファイルのような小さな動作でも、失われたデータを上書きし、復旧を不可能にする可能性があります。現代のSSDでは、TRIMコマンドがこれらのブロックを「クリーンアップ」しようとするため、一分一秒を争います。
適切なツールの選択
このような緊急事態において、2つのオープンソースユーティリティが標準的な解決策となります。
- TestDisk: 最初の防衛線です。パーティションテーブルの修復に特化しています。成功すれば、ファイル名やフォルダ構造もそのままに、ドライブが元の状態で再表示されます。
- PhotoRec: ファイルシステムがひどく損傷し、TestDiskで対応できない場合に使用します。「ファイルカービング」という手法を用い、生のセクタから特定のヘッダー（JPEGなら
0xFFD8など）をスキャンします。ただし、PhotoRecではファイル名が失われることが多く、大量のデータを手作業で整理する必要があります。
私の午前2時の危機では、まずパーティションの復元を目指しました。PhotoRecは、個別のファイルを救い出すための最終手段として考えていました。
ステップ1：環境の準備
OSが入っているプライマリドライブのデータを失った場合は、すぐにシャットダウンし、SystemRescueや標準のUbuntuイメージなどのライブUSBから起動してください。セカンダリのデータドライブの場合は、バックグラウンドプロセスが書き込みを行わないよう、アンマウントします。
# ドライブ名を特定する
lsblk
# まだ一部が見えている場合は、対象のパーティションをアンマウントする
sudo umount /dev/sdb1復旧スイートをインストールします。Debian、Ubuntu、Pop!_OSでは、一つのパッケージで済みます。
sudo apt update
sudo apt install testdiskステップ2：TestDiskによるパーティションテーブルの復元
ルート権限でユーティリティを起動します：
sudo testdiskインターフェースは、クラシックなNcursesベースのテキストメニューです。以下のワークフローに従ってください：
- Log:
[ Create ]を選択して、セッションの記録を保存します。 - Select Disk: 物理ドライブ（例：
/dev/sdb）を選択し、[ Proceed ]を選びます。 - Partition Table Type: TestDiskは通常、
[ EFI GPT ]や[ Intel ]を自動検出します。推奨される設定に従ってください。 - Analyze:
[ Analyse ]を選択し、次に[ Quick Search ]を実行します。
TestDiskがディスクシリンダをスキャンします。失われたパーティションが見つかれば、緑色で表示されます。Pキーを押してファイルを確認してください。見慣れたディレクトリ構造が表示されれば、一安心です。Quick Searchで見つからない場合は、[ Deeper Search ]オプションで全セクタをスキャンします。これには2TBのドライブで4〜8時間かかることがあります。
正しいパーティションを特定したら、ステータスをP (Primary) に設定してEnterを押します。[ Write ]を選択して変更をディスクに書き込みます。再起動後、カーネルがパーティションを再び認識するはずです。
ステップ3：PhotoRecによる生ファイルの復旧
ファイルシステムのメタデータが破壊され、TestDiskが失敗した場合は、PhotoRecの出番です。パーティションテーブルを完全に無視し、480種類以上のファイル形式の「シグネチャ」を探します。
sudo photorec- ドライブと未割り当て領域を選択します。
- ファイルシステムのタイプを選択します（Linuxの標準はExt2/Ext3/Ext4です）。
- Destination: ここが非常に重要です。復旧したファイルは、**絶対に**スキャン対象と同じドライブに保存しないでください。救出しようとしているデータそのものを上書きしてしまいます。外付けUSBドライブやネットワークストレージを使用してください。
PhotoRecはいわば「力技」の道具です。recup_dir.1、recup_dir.2といった名前のフォルダが作成され、その中にf123456.pngのような名前のファイルが数千個生成されます。
事後処理：データの整理
名前が変わってしまった5万個のファイルを精査するのは悪夢です。基本的なBashスクリプトを使って、必要なファイルを探し出すことができます。例えば、5MB以上の復旧されたPDFをすべて見つけるには：
find /media/recovery_drive -name "*.pdf" -size +5M特定のコードやテキストを探しているなら、grepが最適です：
grep -r "database_connection_string" /media/recovery_drive将来への教訓
データの復旧はストレスが多く、100%成功するとは限りません。今回の事件後、私はワークフローに3つの具体的な安全策を取り入れました。
1. エイリアスの設定
.bashrcに確認プロンプトを追加しました。原理主義者は「悪い癖がつく」と言うかもしれませんが、入力ミスを防ぐための一瞬の猶予を与えてくれます。
alias rm='rm -i'
alias mv='mv -i'
alias cp='cp -i'2. LVMスナップショット
LVM（論理ボリューム管理）を使用すると、危険なディスク操作の前にスナップショットを作成できます。パーティションを壊してしまっても、復旧ツールを使わずに数秒でスナップショットの状態に戻せます。
3. 「3-2-1」バックアップ戦略
どんなソフトウェアも適切なバックアップの代わりにはなりません。データのコピーを3つ持ち、2種類の異なるメディアに保存し、そのうち1つはオフサイト（遠隔地）に保管しましょう。ResticやBorgBackupなどのツールを使えば、Linuxサーバーでの自動化と暗号化が可能です。
最後に
TestDiskとPhotoRecは、数多くのシステム管理者を災難から救ってきた信頼できるツールです. あの夜、私のキャリアを救ってくれたように、あなたのデータも救ってくれるかもしれません。これらのツールをツールキットに備えておきつつ、午前2時にこれらを使わずに済むよう、バックアップ戦略の構築に注力してください。
