I/Oバッファがブラックホールになるとき
2TBの古いSATAドライブをバックアップするために定期的なrsyncを実行していると、突然ターミナルが反応しなくなります。dmesgを確認すると、I/O error, dev sdb, sector 123456というエラーが画面を埋め尽くしています。標準的なLinuxツールは、健全なファイルシステムを対象に設計されています。物理的な不良セクタに遭遇すると、それらのツールは無限のリトライループに陥ったり、完全にクラッシュしたりすることが多く、不完全で破損したバックアップと、廃棄寸前のドライブだけが手元に残ることになります。
ハードウェアの故障は、都合のよいメンテナンス時間を待ってくれません。昨年、同期を開始した直後に、本番環境のストレージディスクからあの恐ろしい「死のクリック音」が聞こえ始めたことがありました。このような状況では、プラッタが回転する1秒1秒がギャンブルです。単にデータをコピーするだけでなく、ダメージをマッピングし、ハードウェアが完全に停止する前にアクセスしやすい正常なブロックを優先して救出するツールが必要です。
標準コマンドの致命的な欠陥
cpやddのような標準的なユーティリティは、ドライブの健康状態を「全体像」として把握できないため、ディスクエラーの処理が不十分です。カーネルがブロックを要求し、ドライブがその読み取りに失敗すると、ハードウェアは失敗を報告する前に何度もリトライを繰り返します。これによって2つの大きな問題が生じます：
- cp / rsync: これらはファイルシステムレベルで動作します。1GBのビデオファイルがたった一つの不良セクタの上にあるだけで、コマンドが数分間ハングすることがあります。強制的にスキップさせると、データの99.9%が完全に読み取り可能であっても、ファイル全体を失うことがよくあります。
- dd: 標準の
ddは厳密にリニア（線形的）です。不良箇所に当たると、停止するか、そのセクタをゼロで埋めます。本当の問題は効率です。数千もの健全なブロックがプラッタの先に残っているにもかかわらず、一つの死んだセクタのリトライに30秒を費やすことがあります。500の不良セクタがあるドライブでは、ddはメカニカルヘッドを摩耗させるだけで何時間も無駄にする可能性があります。
GNU ddrescueはこの状況を一変させます。洗練されたマルチパス・アルゴリズムを使用して、まず「取りやすい果実」から確保します。正常な領域を最大速度でコピーし、その後、困難な箇所を「トリミング（削り出し）」や「スクレイピング（掻き出し）」するために戻ります。処理の途中でドライブが切断されても、マップファイル（mapfile）があれば、中断した場所から正確に再開できます。
戦略：マップファイルを救世主として扱う
マップファイルなしでddrescueを実行してはいけません。このファイルは、どのブロックが完了し、どれが保留中で、どれが死亡確定かを追跡します。これにより、プロセスを中断したり、ケーブルを交換したり、あるいは2つの異なる故障ドライブからのデータを1つの正常なイメージに結合したりすることが可能になります。
1. 故障しているドライブを特定する
まず、ソース（コピー元）とデスティネーション（コピー先）を特定することから始めます。**決して、同じ物理ドライブにデータを復旧しようとしないでください。**
lsblk
dmesg | grep -i errorこの例では、/dev/sdbが故障したディスクであり、イメージを/mnt/recoveryにマウントされた健全な4TBドライブに保存すると仮定します。
2. フェーズ1：高速なデータ取得
最初のパスは、可能な限り負荷をかけないように行うべきです。読み取りに一瞬でも時間がかかるセクタはすべてスキップします。これにより、ドライブのモーターやコントローラーが完全に故障する前に、データの大部分を確保します。
# ツールをインストールする
sudo apt update && sudo apt install gddrescue
# 最初の高速パスを実行する
sudo ddrescue -n -b 512 /dev/sdb /mnt/recovery/disk_image.img /mnt/recovery/rescue.map主要なフラグの解説：
-n: 序盤で困難なセクタに時間を浪費しないよう、「スクレイピング」フェーズをスキップします。-b 512: セクタサイズを設定します。古いドライブの多くは512を使用しますが、新しい「アドバンスド・フォーマット」のドライブでは4096が必要な場合があります。rescue.map: これは進捗ログです。大切に扱ってください。
3. フェーズ2：ターゲットを絞ったリトライ
容易なデータが安全に確保されたら、残りのギャップに対して積極的に攻めるようddrescueに指示します。ダイレクトI/Oを使用してカーネルキャッシュをバイパスします。これは故障したハードウェアにおいて、より信頼性の高い結果をもたらすことが多いです。
sudo ddrescue -d -r3 /dev/sdb /mnt/recovery/disk_image.img /mnt/recovery/rescue.map-d: ダイレクトディスクアクセス。低速ですが、カーネルレベルの干渉を回避します。-r3: 各不良セクタを, 次へ進む前に3回試行するようにツールに指示します。
バイタルサインを読み取る
ライブステータス表示のerrsizeフィールドに注目してください。これが最も重要な指標です。1TBのドライブでerrsizeが512KBであれば、99.999%のデータを復旧できたことになります。その時点で、さらに削り続けることは、メカニカルな全損のリスクに見合わないかもしれません。
プロセスが完了すると、生の.imgファイルが残ります。これをフォルダーのように開こうとしないでください。これはドライブパーティションのビット単位のクローンです。
結果をマウントする
losetupを使用してイメージファイル内のパーティションをマッピングし、実際のディスクのようにマウントできるようにします：
sudo losetup -fP /mnt/recovery/disk_image.img
# 新しいループデバイスを特定する (おそらく /dev/loop0)
lsblk
# パーティションを読み取り専用でマウントする
sudo mount -o ro /dev/loop0p1 /mnt/data_recoveredプロのヒント： 常にro（読み取り専用）フラグを使用してください。イメージ内のファイルシステムが損傷している場合、書き込み権限でマウントすると自動的にfsckがトリガーされ、さらなる破損を招く可能性があります。
機能比較：なぜddrescueが勝るのか
| 機能 | dd / cp | GNU ddrescue |
|---|---|---|
| エラー処理 | ハングまたは中断 | スキップしてログを記録 |
| 再開可能性 | なし | 標準対応（マップファイル経由） |
| データ保護 | 低（高ストレス） | 高（正常ブロックを優先） |
実行サマリー
ハードウェアの故障を疑った瞬間、そのドライブへのすべての書き込みを停止してください。フォルダーをブラウズしないでください。fsckを実行しないでください。物理的な損傷はハードウェアの問題であり、ソフトウェアは賢く振る舞うことでしかそれを軽減できません。
私の標準的なワークフローは、現在3つのステップです：ddrescueでドライブをイメージ化し、故障したハードウェアは静電防止袋に入れて保管し、すべてのデータ抽出作業はイメージファイル上で行います。この方法なら、ファイルシステムの修復やtestdiskのようなツールの実行を、モーターの故障というタイムリミットに怯えることなく、何度でも試すことができます。
