停止したラップトップからHDDを回復しています（まったく起動しませんでした。ディスクユーティリティは、問題はないがディスクをマウントしないと報告しました）。USBアダプターを介してHDDを接続しました。ddrescueそのように実行する：
sudo ddrescue -v -n /dev/disk1s2 "/Volumes/Original HD/image.dmg" ddrescue.log
これまでのところエラーはありませんが、平均読み取り速度は徐々に50KB / sに低下しています。最初は約2MB / sでした。パーティションのサイズは300GBです。これまでのところ、160GBを回復することができました。MacBookのHFS +パーティションにリカバリしています。
この転送速度が遅い理由は何ですか？それを増やす方法は？
回答:
これはddrescue、OSXでUSB転送がどのように機能するかのようでした。このスレッドから：Subject：[Bug-ddrescue] ddrescue osxで10x遅い。
完全に機能するハードドライブで作業する場合、Linuxでは完全なI / O速度を実行します。デフォルトのコンパイルフラグを使用してosxでコンパイルすると、速度が大幅に遅くなり、Kb / sにクロールする場合があります。出力ファイルが/ dev / nullの場合、問題は解決しません。
同じスレッドにもこの応答がありました。
私の経験とOS Xでのテストでは、生のキャラクターデバイスにアクセスする
/dev/rdisk…ことが常に望ましいです。また、コピーブロックサイズを大きく設定することで、転送速度をさらに向上させることができます。512KiB（ddrescue -c 1Ki）のサイズで、ほとんどの場合に最高の結果が得られました。また、OS Xのrawキャラクターデバイスにはサイズが定義されているため、初回実行時でも簡単に使用できます。（少なくとも、この時点では、既存のドキュメントのrawデバイスに関する注記は
ddrescueOS Xには適用されません。）
ddrescue他のユーティリティがOS Xで同じ動作をするddかcat、または同じ動作をするため、これはのバグではないと思います。/ dev / disk…ブロックデバイスにアクセスすると、使用されるコピーブロックサイズに関係なく、速度がかなり遅くなります。一方、/ dev / rdisk…rawキャラクターデバイスの読み取り速度は、選択したコピーブロックサイズに大きく依存します。
- 512バイト（
ddrescue -c 1、デフォルトはdd）が最も低速です。- 4096バイト（
ddrescue -c 8、dd bs=4K）に設定すると、/ dev / diskにアクセスするのと同じ低速になります…- 128個のセクタ（=の64KiBのddrecueのデフォルトは
ddrescue -c 128、dd bs=64K）かなり良い結果をもたらします。- さらに（最大
ddrescue -c 1Ki/dd bs=512K）を掛けると、最大速度になります（ほとんどの場合、の8〜12倍/dev/disk…）- それを上回っても、私のテストでは転送速度はそれ以上向上しませんでした。時にはそれも減少しました。
これらは私自身の測定結果であり、使用したメディアやIOハードウェアによって結果は異なる場合があります。たぶん他のユーザーが彼らの経験を共有するなら、私たちはトピックのより良い絵を得ることができます。
ddrescueUNIXシステムから実行してみます。
HFS+MacOS のファイルシステムについてはよく知りませんが、Linuxミントを実行しているラップトップでUSBスティックから500 GBの内蔵ハードドライブ（SATA経由で接続）を救出し、レスキューイメージとログファイルをexFatフォーマットされたUSBハードドライブは、かなりゆっくりと起動していました（1〜2 MB /秒）。レスキュー画像ファイルが大きくなればなるほど遅くなるようです。
次に、レスキューイメージとログファイルを別の一時的な場所に移動し、USBハードドライブをext4ファイルシステムで再フォーマットし、ファイルをその上に戻し、ddrescueプロセスを再開しました。これで、1〜20 MB /秒で再び実行されます（変動しかし、平均で約7MB /秒）！
のようexFatに非常に大きなファイル（数百ギガバイト）ではうまく再生されません。すでに述べたように、これが当てはまるかどうかはわかりませんHFS+が、たぶんあなたext4はショットをしたいと思うでしょう。
-i214748364800。最初の0〜160GBがこの影響を受けないことを願っています。