debugfsを使用したddrescueマッピングファイルのバッチ処理

Question

私は私の問題に対する解決策を見つけたと信じています。しかし、誰かがよりエレガントな解決策を思いつくことができるのか、私の解決策でバグを見つけることができるのかはまだ疑問に思います。

stdinに書き込むことができることがわかったので、出力を解析できるdebugfs一連のコマンドを生成するだけです。debugfsddrescue

次のbashスクリプトは、というmapfile.ddrescue名前のファイルがによって生成された現在のディレクトリに存在すると仮定しますddrescue。

for line in \
    $(cat mapfile.ddrescue | \
      grep -e "-$" | \
      awk -F" " '{print $1}' | \
      awk -F"0x" '{print $2}'); \
do \
    position=$(( 16#$line / 512 - 91914240 )); \
    result="$result $position"; \
done; \
echo -e "open /dev/sdd3\nicheck $result\nquit\n" | sudo debugfs

スクリプトは次のことを行います。

私がmapfile名前を付けたものを分析しました。ddrescuemapfile.ddrescue
ハイフンで終わる行だけを保持するようにフィルタリングしました。不良ブロックがある場所です。
私はawkを使用してスペースを分割し、場所である最初のマークを印刷します。これには、0x34A933F000などの16進数が含まれます。
Oxプレフィックスを削除しました。
呼び出し側が返した結果は$(...)forループへの入力として使用されるため、行には常に位置が含まれます。
私は$(( ... ))場所を512（セクターあたりのバイト数など）で割り、パーティションの開始位置（私の場合）を減算する式を使用して場所の計算を実行します91914240。これは、パーティションの開始に基づいてセクタ位置を提供します。
各場所をスペースで区切られたリストにリンクします$result。
debugfs最後に、sudoを使用して実行されるコマンドの標準入力にパイプする改行区切りコマンドのリストを生成します。このコマンドはデバイスを開きます（私の場合は/dev/sdd3）。その後でicheck実行され$result、終了しますdebugfs。

このスクリプトを実行すると、このブロックのすべての内容をdebugfs見つけるのに長い時間がかかりましたinodes。私の場合、出力が印刷されるまで数分間中断されたようです。

スクリプトが完了したら、結果をテキストファイルにコピーして分析します。幸いなことに、ほとんどのセクタは割り当てられていないブロックを指し、残りのセクタのほとんどは同じ少数の数を指しますinode。行を削除<block not found>して重複エントリを削除した後は、手動チェックを使用できるinodes4行しか残りません。これにより、バックアップから復元しようとするファイルである4つのファイルパスが提供されます。debugfsncheck

背景もともとdd256GB SSDの内容を大きなSSDにコピーしたかったのです。dd最後のパーティションの約45/185 GBでI / Oエラーのため中止されました。しかし、ddrescue保存できます。99.99％運転する。最後に、上記の解決策で、残りの1700kb、つまり418個の不良セクタがどのファイルに属しているかを確認でき、4個のファイルのみが破損していることがわかりました。これで、どのファイルが破損しているかを把握し、以前のバックアップからそのファイルを復元できるため、データ復旧に対する自信が大幅に向上しました。

Answer 1