ddrescue は、ファイルが含まれていないブロックも含め、ディスクまたはパーティション上のすべてのブロックを回復しようとするようです。ファイルシステム (たとえば、NTFS のマスター ファイル テーブル) を調べて、実際にファイルが含まれているブロックを見つけることはできないでしょうか?
編集: partclone と組み合わせれば可能になるかもしれないようです:
http://partclone.org/features/
レスキュー状況では、Partclone のレスキュー モードは不良ブロックをスキップし、パーティションのすべての正常なブロックをバックアップしようとします。ddrescue プログラムは不良ディスクを保存するためのもう 1 つの優れたソリューションですが、partclone の助けを借りて、すべての使用済みブロックをドメイン ファイルとしてリストすると、パーティションをダンプするときに ddrescue がよりスマートかつ高速になります。
参照: http://sourceforge.net/p/partclone/mailman/partclone-user/thread/[メールアドレス]/
答え1
簡単に答えると、それが目的ではないからです。Ddrescue は 1 つのこと (故障した HDD を 1:1 でコピーする) を実行し、それをうまく実行します。
答え2
ddrescue は、dd 自体と同様に、ファイルシステムがないものや破損しているものも含め、あらゆるブロック デバイスで動作するように設計されているため、これは不可能だと思います。ファイルシステムが存在するかどうかを調べると、複雑になるだけです。
答え3
古いスレッドですが、他の人の役に立つかもしれません...
入力が NTFS 形式のボリュームである場合、ddrutility の ddru_ntfsbitmap を使用して、$Bitmap システム ファイル (NTFS パーティションの使用済み/未使用のクラスターの正確なマップ) を使って ddrescue のマップファイルを生成できます。もちろん、$Bitmap ファイルがそのままの状態で、完全に読み取り可能な領域に配置され、適切に機能する必要があります (通常、パーティションの先頭に配置されます)。その場合、処理は迅速に進行します (私の最初の、そしてこれまでのところ唯一の経験では、1TB パーティションからマップファイルを生成するのに約 2 分かかりました)。次に、次の基本コマンドで ddrescue を実行します。
ddrescue [options] [input path] [output path] [logfile] -m [mapfile]
ddrescue の最新バージョンでは、入力ボリュームの復旧された / 未試行 / 不良領域が復旧中に保存されるファイルである「logfile」という用語が「mapfile」に置き換えられており、非常にわかりにくくなっています。したがって、たとえば、ddru_ntfsbitmap によって生成された Recovery_bitmap.log というマップファイルを使用して、/dev/sdc という HDD を /media/sdd1 上の Recovery というイメージに復旧する場合、コマンドは次のようになります。
ddrescue [options] /dev/sdc /dev/sdd1/Recovery /dev/sdd1/Recovery.log -m /dev/sdd1/Recovery_bitmap.log
答え4
主な理由は、ddrescueさまざまなファイルシステムに関する情報を組み込み、その内部構造を解析する必要があるため、 のコードが大幅に複雑になるためだと考えられます。
ただし、追加の開発作業を無視したとしても、どのブロックにデータがあるかを調べるのは一般的に困難です。 は、ddrescueデータがすでに破損していて、不整合が発生している可能性がある状況で通常使用されます。 そのような状況で使用済みブロックを見つけようとするのは危険です。空きブロックのリスト自体が破損している (ただし読み取り可能) 場合はどうなるでしょうか。 または、ファイルの現在のバージョンは回復できなくなっているかもしれませんが、ファイルの古いバージョンが空きブロックにまだ存在している可能性があります (ファイル システムがその場で上書きしなかったため)。
その場合、唯一の安全な選択肢は、すべてを取得して、後で詳細を整理することです。