ddrescueが非常に遅く、NTFSへの書き込み–今すぐExt4に変換する価値はありますか？
2日前に1TBの故障したHDDの回収を開始しましたが、そのほとんどを安い価格で回収できることを期待して配布されました。
最初は不規則に動作し、突然切断されて恐ろしい音がすることが多く、コピー速度は毎秒数KBから毎秒約50MBの間で変動しました（暑い日だったので、ラップトップの冷却パッドで過熱しないようにしましたその下に冷却ブロックがあり、1時間ごとに交換しました）。その後、最初の夕方に安定しましたが、平均コピー速度は大幅に低下し、約3〜4MB /秒になりました。現在、250GBを回復したので、平均で約400KB/sに低下しましたが、これは非常に遅いです（少なくとも、それ以上低下することはないようです）。
だから私の質問は：
- 私はNTFSパーティションへのリカバリを行っています。これは、プロセスのかなり遅い段階（ このフランス語ガイド ）で読んだものから、リカバリが大幅に遅くなる可能性があるためお勧めできません。それは（まだ）本当ですか、もしそうなら、なぜですか？
- それとも、Linux用のNTFSドライバーが十分に成熟していなかったとき、これは過去のものですか？ （DVD-RWから正常に起動できないため、メモリカードにコピーされた最新のKnoppixライブDVDを使用しています。）
- この段階でパーティションをExt4のようなネイティブLinuxフォーマットに変換するのは面倒な価値がありますか？つまり、コピー速度が大幅に向上するでしょうか？
- または、ほとんどの「正常な」セクターがすでに回復している最初のパスの後で、ドライブの障害によってこのような速度低下が発生するのは正常ですか？ （SMARTパラメーターが悪化し、「全体的なヘルス自己評価テスト結果」が「合格」から「不合格」になり、再割り当てされたセクターの数が144から1360になりました。）
- 回復率や回復速度を向上させるために他にできることはありますか？
ddrescueに、実際に役立つオプションはありますか？
私はこのコマンドで最初の実行を行いました：
_ddrescue -n -N -a500000 -K1048576 -u /dev/sdc /media/sda1/Hitachi1TB /media/sda1/Hitachi1TB.log
_（_-n_＆_-N_スイッチは、おそらくスクレイピングとトリミングのフェーズをバイパスします–プロセスのどの時点でこれらのアクションがプログラムによって試行され、それが実際にそれらをバイパスするのに役立つかどうかはわかりませんが次に、最小コピー速度を500000バイト/秒、「読み取りエラー時にスキップする初期サイズ」に1MBの値を指定し、まだ正常であるかアクセスしやすい領域をできるだけ早くコピーしようとしました。_-u_は「単方向」用です：別のHDDを使用した以前のリカバリでは、_-R_スイッチを使用して逆方向にコピーすると問題が改善されたようですが、これを使用すると大混乱を引き起こし、明らかに安定していますそのスイッチで。）
1回のパスが完了した後、これらのパラメーターのほとんどを削除し、_-u_のみを保持しました。ある時点で_-d_スイッチを試しましたが（「直接ディスクアクセスを使用」）、何もコピーされず、「エラーサイズ」が急速に大きくなりました。
上記の私のコメントを完成させるために（正式な不便/矛盾について申し訳ありません）：理由はよくわかりませんが、それだけの価値があると思います。 2回目の試行であるExt4パーティションへの回復では、最初はコピー速度が大幅に高くなりました（平均で約90MB /秒でしたが、最初の試行ではせいぜい約50MB /秒で、NTFSパーティションに回復しました）。 、エラーや速度低下さえありません。しかし、その後、約165GBをコピーした後（以前よりも早く）、それは非常に不安定になり、クロールまで遅くなり、カチッという音とうなり音が再び発生しました（非常に暑い時期でしたが、役に立たなかった-私はそれを冷やそうとしました下のラップトップ冷却パッドとその上の冷凍パックを使用して、可能な限りダウンさせ、1時間ごとに交換します。何度も試しましたが（数秒間120MB/sの速度に戻ってから、0に戻ることもありました）、しばらくしてそれを放棄しなければなりませんでした。
これが最初の回復のddrescueviewマップです。
興味深いパターンがあり、簡単に回復できるデータのストライプが非常に遅いデータや読み取り不可能なデータと交互になっています。私の知る限りでは、ヘッドがプラッターに接触して表面に損傷を与え、磁気ダストを放出し、それが遠心力で広がったことを示しているように思われます。また、サーボトラック（起動プロセスに不可欠な情報を含む）はハードドライブの外縁（3.5 "Hitachi 1 TB）にあるため、ほこりの一部がそこに到達し、アクセスが困難になっている可能性があります。これは、起動時に頻繁にクリック音がすることを説明している可能性があります（間違っている場合は訂正してください）。
これが2回目の回復のddrescueviewマップです。
そのため、ハードドライブは非常に不安定になり、約165 GBを超えるとリカバリがますます困難になりましたが、それ以前は、コピーレートは一貫して高く、スキップされた領域はありませんでした。後で最後の試行でddru_ntfsbitmapメソッドを使用したため、空き領域はほとんどスキップされました。
これは、ddru_ntfsbitmapで作成されたログファイルのddrescueviewマップで、実際のデータを含むハードドライブの領域を緑色で、空き領域を灰色で示しています。
幸い、実際のデータのほとんどは第1四半期にあり、正常に復元されました。今、私はまだこれら2つの画像の良い部分を組み合わせて、おそらくR-Studio（私が試した中で最高のデータ復旧ソフトウェア）を使って実際のファイルを抽出していません。
私の最初の質問に関して、後で私が興味深く独特なことを見つけたことが1つあります（正式な規則に従って、これをコメントとして入れるべきだったと思いますが、長すぎてスクリーンショットを提供できませんでした） 。
Image1で欠落していたExt4パーティション上のimage2のレスキューされた領域を、NTFSパーティション上のそのimage1にコピーしようとしました。{1}、これは非常に高速で実行されるべきでした（入力と出力は正常な2 TBのHDDにあります）が、平均で660KB/sの速度しか得られませんでした！
使用されるコマンド（ドメインログファイルとして使用されるイメージ2のログファイル）：
ddrescue -m [image2.log] [image2] [image1] [image1.log]
スクリーンショット：
そこで、停止して反対の操作を行いました。イメージ2で欠落していたイメージ1（NTFS）のレスキュー領域をそのイメージ2（Ext4）にコピーしました。現在、コピー速度は約43000KB/sまたは43MB/sでした。平均して（同じHDD上のコピーで予想されるよりもわずかに遅い可能性があります。最大書き込み速度が200MB /秒に近いSeagate2TBの場合、約100MB /秒に達することができるはずです。あるパーティションから別のパーティションにコピーしますが、それでも最初の試行よりもほぼ100倍優れています）。そのような途方もない矛盾の説明は何でしょうか？
使用したコマンド：
ddrescue -m [image2.log] [image2] [image1] [image1.log]
スクリーンショット：
両方のパーティションのイメージファイルに「ディスク上のサイズ」があることに気づきました{2}-Sスイッチを使用しなかったにもかかわらず（「出力ファイルにスパース書き込みを使用する」）、実際に書き込まれたデータの量に対応し、合計サイズ（1 TBまたは931.5GB）からはほど遠い。 。イメージ2（イメージ1から追加のレスキュー領域を追加した後）の「ディスク上のサイズ」は308.5GBで、イメージ1の「ディスク上のサイズ」は259.8GBです。 Linux NTFSドライバーがまばらな書き込みの処理に何らかの問題を抱えている場合、コピー速度が遅いことに関係している可能性がありますか？そして、その-Sスイッチを使用しなかったことを考えると、最後のセクターが書き込まれるとすぐに全体のサイズが割り当てられなかったのはなぜですか？
プロセスの最初に-pスイッチ（「事前割り当て」）を使用しようとしましたが、何か問題が発生した場合に備えて、「よりクリーン」で、より簡単で、扱いやすいと考えました（回復した場合）。回復する必要があります...）しかし、長すぎてできるだけ早く始めたかったので、やめなければなりませんでした。次に、一時的に-Rスイッチ（「リバース」）を使用すると、最後のセクターが出力ファイルに書き込まれ、意図したとおりにフルサイズが割り当てられることがわかりました。実際、出力ファイルのサイズは931.5GBに増加しましたが、「ディスク上のサイズ」は実際にははるかに小さかった（後で、Windowsでそのリカバリに使用されたHDDにアクセスし、異常に大量の空き容量があることに気づきました。スペース）。
________________
{1} HDDのヘルスステータスがその間に低下したにもかかわらず、2回目のリカバリ試行で最初の100GB程度でこれほど良い結果が得られる方法がまだわかりません。
{2}ちなみに、「ディスク」ではないデータストレージユニットがあるため、WindowsシステムとLinuxシステムでは、「ディスク」という単語を置き換える必要があります。