☰

ddrescue が非常に遅く、NTFS に書き込みます。今 Ext4 に変換する価値はありますか?

tag-icon • tag-icon ntfs hard-drive-recovery ddrescue
ddrescue が非常に遅く、NTFS に書き込みます。今 Ext4 に変換する価値はありますか?

2 日前、私は、安価で大部分を回収できるという希望を抱いて、私に渡された 1TB の故障した HDD の復旧を始めました。

最初は動作が不安定で、突然切断されることも多く、恐ろしい音がしました。コピー速度は数 KB/秒から 50 MB/秒程度でした (暑い日だったので、ノートパソコンの冷却パッドの下に置き、冷却ブロックを上に置き、1 時間ごとに交換して過熱を防ごうとしました)。その後、最初の夜は安定しましたが、平均コピー速度は 3 ～ 4 MB/秒程度に大幅に低下しました。250 GB を回復した現在、平均で約 400 KB/秒に低下しており、これは非常に遅いです (少なくともこれ以上低下することはないようです)。

私の質問は次のとおりです:

  • 私は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 バイト/秒に指定し、「読み取りエラー時にスキップする初期サイズ」の値を 1 MB に設定して、まだ正常であるかアクセスしやすい領域をできるだけ早くコピーしようとしました。 は-u「一方向」を表します。以前別の HDD でリカバリしたとき、スイッチを使用して逆方向にコピーすると-R状況が改善されたように見えましたが、今回の場合は大混乱を引き起こしているようで、どうやらそのスイッチの方が安定しているようです。)

さて、1 回のパスが完了した後、これらのパラメータのほとんどを削除し、 のみを残しました-u。ある時点でスイッチ (「直接ディスク アクセスを使用する」) を試しました-dが、何もコピーされず、「エラー サイズ」が急速に増加しました。

答え1

上記のコメントを締めくくると (形式的な不便さや矛盾については申し訳ありません)、価値はあったと思います。理由はよくわかりませんが。2 回目の試行 (Ext4 パーティションへのリカバリ) では、最初はコピー速度が大幅に速く (平均で約 90 MB/秒、1 回目の試行 (NTFS パーティションへのリカバリ) では最高でも約 50 MB/秒)、エラーや速度低下もありませんでした。しかし、約 165 GB をコピーした後 (つまり、以前よりも早い)、非常に不安定になり、速度が極端に低下し、再びカチカチと音を立てるようになりました (非常に暑い時期だったので効果がありませんでした。下にノート PC の冷却パッドを置き、上に冷凍パックを置き、1 時間ごとに交換して、できるだけ冷却しようとしました)。何度も試しましたが (数秒間 120 MB/秒の速度に戻り、その後 0 に戻ることもありました)、しばらくして断念せざるを得ませんでした。

ddrescueview最初の回復の地図は次のとおりです。
ddrescueview 1回目の試み NTFS パーティション

興味深いパターンがあり、簡単に復元できるデータのストライプと、非常に遅いデータや読み取り不可能なデータが交互に現れます。[私の知る限りでは、ヘッドがプラッターに接触して表面が損傷し、磁性粉塵が放出され、それが遠心力で拡散したことを示しているようです。また、サーボ トラック (起動プロセスに不可欠な情報が含まれています) はハード ドライブ (3.5 インチの Hitachi 1 TB) の外縁にあるため、その粉塵の一部がサーボ トラックに到達してアクセスが困難になっている可能性があり、起動時に頻繁にクリック音が鳴る原因となっている可能性があります。](間違っていたら訂正してください。) => [編集 20200501] それは間違っていました。実際、このパターンは通常、ドライブの 1 つのヘッドが完全に故障し、何も読み取れなくなったことを示しています。この時点ではプラッター上のデータはまだ読み取り可能である可能性がありますが、ヘッド スタック アセンブリの交換が必要になります。これは、専門のデータ復旧ラボでのみ安全に実行できます。

ddrescueview2 回目の回復のマップは次のとおりです。
ddrescueview 2回目の試み Ext4 パーティション

そのため、ハード ドライブは非常に不安定になり、約 165 GB を超えると回復がますます困難になりましたが、それ以前はコピー速度が一貫して高く、スキップされた領域はありませんでした。その後、ddru_ntfsbitmap最後の試行でこの方法を使用したため、未割り当て領域はほとんどスキップされました。

以下は、ddrescueviewで作成されたログ ファイルのマップですddru_ntfsbitmap。ハード ドライブの実際のデータを含む領域は緑色で、空き領域は灰色で表示されています。
ddrescueview ddru_ntfsbitmap ログ ファイル

幸運にも、実際のデータのほとんどは第 1 四半期にあり、正常に復元されました。現在、2 つのイメージの適切な部分を結合し、実際のファイルを抽出する必要があります。おそらく R-Studio (私が試した中で最高のデータ復元ソフトウェア) を使用します。

私の最初の質問に関して、後で興味深く奇妙なことが 1 つ分かりました (正式なルールに従って、これをコメントとして投稿するべきだったと思いますが、長くなりすぎてスクリーンショットを提供できなかったでしょう)。

イメージ 1 で欠落していた Ext4 パーティション上のイメージ 2 の復旧領域を、イメージ 1 の NTFS パーティション{1}にコピーしようとしましたが、これは非常に高速に実行されるはずでした (入力と出力は正常な 2 TB HDD 上で実行)。しかし、平均速度はわずか 660 KB/秒でした。これは、私が最初にこの質問をするほど心配になった後の段階での初期回復の速度に非常に近いものでした...

使用されたコマンド (ドメイン ログファイルとして使用されるイメージ 2 のログ ファイル):

ddrescue -m [image2.log] [image2] [image1] [image1.log]

スクリーンショット:
ddrescue は、救出された領域のイメージ 2 をイメージ 1 にコピーします。

そこで、私はやめて、逆のことを行いました。つまり、イメージ 2 (Ext4) で失われていた、イメージ 1 (NTFS) の回復された領域をそのイメージ 2 にコピーしたところ、コピー速度は平均で約 43000 KB/秒、つまり 43 MB/秒になりました (同じ HDD でのコピーに期待される速度よりわずかに遅いかもしれませんが、Seagate 2 TB の最大書き込み速度は 200 MB/秒近くなので、1 つのパーティションから別のパーティションへのコピーでは約 100 MB/秒に達するはずですが、それでも最初の試行よりはほぼ 100 倍高速です)。このような大きな差異の原因は何でしょうか?

使用されたコマンド (ドメイン ログファイルとして使用されるイメージ 1 のログ ファイル):

ddrescue -m [image1.log] [image1] [image2] [image2.log]

スクリーンショット:
ddrescue は、救出された領域のイメージ 1 をイメージ 2 にコピーします。

両方のパーティションのイメージ ファイルの「ディスク上のサイズ」 {2}は、実際に書き込まれたデータの量に対応しており、スイッチ-S(「出力ファイルにスパース書き込みを使用する」) を使用していないにもかかわらず、合計サイズ (1 TB または 931.5 GB) から大きく離れていることに気付きました。イメージ 2 (イメージ 1 から追加の救出された領域で完了した後) の「ディスク上のサイズ」は 308.5 GB ですが、イメージ 1 の「ディスク上のサイズ」は 259.8 GB です。Linux NTFS ドライバーがスパース書き込みの処理に何らかの問題を抱えている場合、これはコピー速度が遅いことと関係があるのでしょうか。また、そのスイッチを使用していないことを考えると、最後のセクターが書き込まれた直後に全体のサイズが割り当てられなかったのはなぜでしょうか-S。

プロセスの最初にスイッチ (“preallocate”)を使用しようとしました-p。これは、何か問題が発生した場合 (リカバリをリカバリする必要がある場合など) に、より “クリーン” で、よりわかりやすく、対処しやすいと考えたからです。しかし、時間がかかりすぎたため、すぐに開始したかったため、中止する必要がありました (どうやら、必要なセクターを単に割り当てるのではなく、実際には空のデータを書き込むようです)。次に、スイッチ-R(“reverse”) を一時的に使用することで、最後のセクターが出力ファイルに書き込まれ、意図したとおりにフルサイズが割り当てられると考えました。その結果、出力ファイルのサイズは確かに 931.5 GB に増加しましたが、実際には “ディスク上のサイズ” ははるかに小さくなりました (後で、Windows でリカバリに使用した HDD にアクセスし、異常に高い空き領域を確認したときに気付きました)。________________
{1}
その間、HDD の健全性状態が低下していたにもかかわらず、2 回目のリカバリ試行で最初の 100 GB 程度で非常に良い結果が得られた理由がまだわかりません。 [編集 20200501] => 最初に使用したパラメータが原因でa500000、読み取り速度が 500KB/秒のしきい値を下回る領域がスキップされた可能性があります。そのオプションがなければ、2 回目はすぐに遅い領域を読み取りました。実際、これらの遅い領域は弱いヘッドに関連付けられていたため、故障の兆候がすでに見られていたにもかかわらず、この故障したヘッドが 2 回目に同じ量のデータを取得できたのは依然として不可解です。まだ学習中です...

{2} ちなみに、「ディスク」という単語は、Windows システムでも Linux システムでも、「ディスク」ではないデータ ストレージ ユニットが存在するため、置き換える必要があります...

答え2

  1. まずディスクイメージをコピーし、dd指示

    sudo dd bs=[ブロックサイズ] count=[ブロック数] if=[入力ファイル] of=[出力ファイル]

どこ

[in_file] - 壊れたディスク（/dev/sdd2 など）

[out_file] - 出力画像ファイルの場所。

  1. イメージをマウントして回復を試みます。

関連情報