だから最近、私たちはハードドライブが死んでいる間、使用中のすべてのデータをコピーしようとしましたsafecopy。私が見つけることができるすべてのガイドとドキュメントは、出力が画像ファイルであるべきでsafecopyあると述べています。コマンドは処理されましたが、XXX何百、何千ものブロックの読み取りが失敗したことを示す出力としてのみ生成されました。明らかに、これはドライブがまだマウント可能であり、ほとんどのファイルを読み取ることができるので間違っています。次に、誰かが提案したように、HDDパーティション（/dev/sdb2）を出力として指定して再試行しました（そのスレッドが見つかりませんでした。1週間を超えました）。コマンドが実行され、出力が正常に読み取られ、5日が少し以上完了すると予想されます。
これで、ドライブに回復されたすべてのデータがありますが、パーティションを読み取ることができなくなりました。破損したドライブがすぐに死ぬため、回復を繰り返すことができず（ヘッドクラッシュ、これは非常に暴力的な状況です）、コマンドが完了して記録されてから実行されていた他のHDDからデータを何らかの方法でインポートする必要があります。パーティションのすぐ上にあります。何とか回収できますか？意図したターゲットが.imgファイルの場合、デバイスファイルの生データをwithにコピーすると、コマンドが開始されるようにする「予想結果」が得られる.imgと思います（例：ファイル形式ではなくファイル形式）。デバイス）、しかし数パーセントの操作の後、動作は停止し、数時間後も回復しませんでした。ddsafecopy.imgdd
揮発性システムでの実行により正確なコピーと出力が失われましたが、デバイスとパラメータに基づいて覚えておくと、フェーズ1のコピーをsudo safecopy --stage1 -b 4096 -R 2 /dev/sda2 /dev/sdb2実行し/dev/sda2（破損）から（バックアップ）までdev/sdb2追加する2回の再試行がありました。ブロックサイズは4096バイトです。...私が知っている限り、ブロック読み取りが成功したことを示す出力がほとんど生成されます。safecopy約3TBのデータが記録され、正常に完了したことを示す出力が終了します。
sudo file -s /dev/sdb2エラーメッセージのみが生成され、再試行を使用すると、本機の内容についてより多くの情報を取得/dev/sdb2: ASCII text, with very long lines, with no line terminatorsできます。hexdump -C /dev/sdb2
00000000 42 61 44 62 4c 6f 43 6b 42 61 44 62 4c 6f 43 6b |BaDbLoCkBaDbLoCk|
*
01000030 42 61 44 62 4c 6f 43 6b 10 00 00 00 4c 6f 43 6b |BaDbLoCk....LoCk|
01000040 c4 7b 00 00 4c 6f 43 6b 42 61 44 62 4c 6f 43 6b |.{..LoCkBaDbLoCk|
01000050 42 61 44 62 4c 6f 43 6b 42 61 44 62 4c 6f 43 6b |BaDbLoCkBaDbLoCk|
*
0101ef10 c8 7b 00 00 4c 6f 43 6b 42 61 44 62 4c 6f 43 6b |.{..LoCkBaDbLoCk|
0101ef20 c9 7b 00 00 ca 7b 00 00 cb 7b 00 00 cc 7b 00 00 |.{...{...{...{..|
0101ef30 cd 7b 00 00 ce 7b 00 00 cf 7b 00 00 d0 7b 00 00 |.{...{...{...{..|
0101ef40 d1 7b 00 00 d2 7b 00 00 d3 7b 00 00 d4 7b 00 00 |.{...{...{...{..|
残りの行は通常のディスクデータのように見えますが、奇妙なことに、最初の数hexdump千のブロックを正常に読み込んだにもかかわらず、最初の行には不良ブロックが表示されます。safecopy