タグ付けされた質問 「ddrescue」

故障したハードディスクをゼロアウトするとします。可能な限りゼロで上書きする必要があります。望まないのは、最初の書き込みエラーでプロセスが中断することです。どうやってするか？ AFAICS、plain ddは読み取りエラーを無視するオプションのみを提供します。したがって、次のようなもの dd if=/dev/zero of=/dev/disk/by-id/lousy-vendor-123 bs=128k 十分ではありません。 ddrescue エラーを無視するのが良いようですが、それで最適なコマンドラインは何でしょうか？ GNU ddrescueでの私の試み： ddrescue --verbose --force --no-split /dev/zero /dev/disk/by-id/lousy-vendor-123

19 hard-disk  dd  ddrescue 

背景/コンテキスト： 私は現在、GNU ddrescue 1.18.1を実行して、disk2s1パーティションに仮想ディスクイメージを書き込んでいる間にケーブルが切断されたUSBからデータを回復しています。最初は2番目のパーティション（disk2s2）を回復していて、3番目のフェーズ（分割）に達したことに気付きました。イメージをネットワークストレージに配置しています。 質問： このフェーズがループすることに気づきました。現在のステータス情報から、発生する可能性が高いループの数を計算する方法はありますか？ 状態： 更新/編集： ですから、ddrescueツールを使用して、ループ/完了の時間をどのように推定できるかについては、まだ非常に興味があります。コメントに従って、現在実行中のdisk2s1パーティションのログファイルの評価を追加しています（disk2s2は14.5時間後に完了し、1人のユーザーが約6時間中断しました）。 完了したパーティションログ 完了したばかりのパーティションについて、ログ検査の結果を次に示します。 リファレンス（ddrescueアルゴリズムの注意）： 4アルゴリズム GNU ddrescueはddの派生物ではありません。また、あるデバイスから別のデバイスにデータをコピーするために両方を使用できるという点を除いて、ddとは関係ありません。主な違いは、ddrescueは高度なアルゴリズムを使用して、故障したドライブからデータをコピーし、追加の損傷をできるだけ少なくすることです。 Ddrescueは進行中のレスキューのステータスを効率的に管理し、最初に適切な部分をレスキューしようとし、後で悪い（または遅い）領域内の読み取りをスケジュールします。これにより、故障したドライブから最終的に回復できるデータの量が最大になります。 標準のddユーティリティを使用して、障害が発生したドライブからデータを保存できますが、データが順次読み取られるため、ドライブの先頭にエラーがある場合は、ドライブを使い果たすことなく何も救うことができません。 他のプログラムはデータを順番に読み取りますが、エラーが見つかった場合は小さいサイズの読み取りに切り替えます。これは、エラー領域でより多くの時間を費やし、できるだけ早くそれらから抜け出すのではなく、表面、ヘッド、およびドライブ機構に損傷を与えることを意味するため、これは悪い考えです。この動作により、残りの適切なデータを救う可能性が減少します。 ddrescueのアルゴリズムは次のとおりです（ユーザーはいつでもプロセスに割り込むことができますが、不良ドライブがカーネルが停止するまでddrescueを長時間ブロックする可能性があることに注意してください）。 1）オプションで、マルチパートまたは以前に中断されたレスキューのステータスを説明するログファイルを読み取ります。ログファイルが指定されていないか、空または存在しない場合は、すべてのレスキュードメインを未試行としてマークします。 2）（最初のフェーズ;コピー）入力ファイルの未試行部分を読み取り、失敗したブロックを非トリムとしてマークし、それらを超えてスキップします。遅いエリアを越えてスキップします。スキップされた領域は、後で2つの追加パス（トリミング前）で試行され、すべてのレスキュードメインが試行されるまで、各パスの後で方向が逆になります。3番目のパスは、スキップを無効にしたスイープパスです。（目的は、大きなエラーをすばやく区切り、ログファイルを小さく保ち、トリミングの開始点を作成することです）。未試行の領域のみが大きなブロックで読み取られます。トリミング、分割、再試行はセクターごとに行われます。各セクターは最大2回試行されます。このステップの最初は（通常、大きなブロックの読み取りの一部として、場合によっては単一セクターの読み取りとして）、以下のステップの1つで2番目は単一セクターの読み取りとして。 3）（第2フェーズ、トリミング）読み取りは、トリミングされていない最小のブロックのリーディングエッジから、不良セクターが見つかるまで、一度に1セクターずつ転送します。次に、不良ブロックが見つかるまで、同じブロックの後縁から一度に1セクターずつ逆方向に読み取ります。トリミングされていないブロックごとに、見つかった不良セクターを不良セクターとしてマークし、そのブロックの残りの部分を、読み取ろうとせずに非分割としてマークします。トリミングされていないブロックがなくなるまで繰り返します。（トリミングされていない大きなブロックは、小さいブロックを連結することによって生成されるため、エッジでの適切なデータの割合は小さくなります）。 4）（第3段階;分割）読み取りは、最大の非分割ブロックの中心から一度に1つのセクターを、不良セクターが見つかるまで転送します。次に、見つかった不良セクターが最初に試行したものでない場合は、不良セクターが見つかるまで、同じブロックの中心から一度に1セクターずつ逆方向に読み取ります。ログファイルが「--logfile-size」よりも大きい場合、ログファイルのエントリ数が「--logfile-size」を下回るまで、最大の非分割ブロックを順番に読み取ります。残りのすべての非分割ブロックのセクターが7未満になるまで繰り返します。次に、残りの非分割ブロックを順番に読み取ります。 5）（第4フェーズ;再試行）オプションで、指定された再試行パスの回数に達するまで、不良セクターの読み取りを再試行します。すべての不良セクターは、各パスで1回だけ試行されます。Ddrescueは、不良セクターが回復不能であるかどうか、または再試行後に最終的に読み取られるかどうかを知ることができません。 6）オプションで、後で使用するためにログファイルを書き込みます。 合計エラーサイズ（ 'errsize'）は、すべての非トリミングブロック、非分割ブロック、および不良セクターブロックのサイズの合計です。コピーフェーズ中に増加し、トリミング、分割、再試行中に減少する可能性があります。ddrescueが失敗したブロックを分割してそれらを小さくすると、エラーの数が増加する一方で、合計エラーサイズが減少する可能性があることに注意してください。 ログファイルは定期的にディスクに保存されます。また、ddrescueが終了したときや中断されたときも保存されます。したがって、クラッシュが発生した場合は、ほとんど再コピーせずにレスキューを再開できます。保存の間隔は、ログファイルのサイズに応じて30秒から5分まで変化します（大きなログファイルはより長い間隔で保存されます）。 また、同じログファイルを、入力ファイルの異なる領域をコピーする複数のコマンド、および異なるサブセットでの複数のリカバリ試行に使用できます。この例を見てください： まず、ディスクの最も重要な部分を救出してください。ddrescue -i0 -s50MiB / dev / hdc hdimage logfile ddrescue -i0 -s1MiB -d -r3 / dev / hdc hdimage logfile 次に、いくつかの重要なディスク領域を救出します。ddrescue …

9 ddrescue 

停止したラップトップから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 +パーティションにリカバリしています。 この転送速度が遅い理由は何ですか？それを増やす方法は？

9 osx  usb  hard-disk  ddrescue 

私はddrescueを使用してSDHCカードからデータを救出しようとしています： while true ; do ddrescue -d /dev/mmcblk0p1 mmc.img mmc.log ; done コントローラーは、カード上のものか、ラップトップ内のものかはわかりませんが、特定の数の不良セクターが読み取られた後（syslogに表示されます）、すべてのセクターでエラーが返されるようです（これはSyslogに表示されます）、カードを取り出してスロットに再び入れると、これがリセットされ、読み取られた不良セクターが多すぎるまで、正常なセクターが再び良好であることが報告されます。 現在、私はこのループを使用しており、ddrescueのステータス出力を監視し、カードを手動でリセットしています。カードを取り外さずにコントローラーをリセットして、レスキュープロセスを無人で実行できる方法はありますか？ これは関連しているかもしれませんが、このDellラップトップでは、カードが挿入されたことにリーダーが気付くためにも、ブート時またはの使用時にecho 1 > /sys/bus/pci/rescan1回だけ実行する必要があります。その後、リーダーのPCIデバイスが表示され、すべてが期待どおりに機能します。 07:00.0 System peripheral: JMicron Technology Corp. SD/MMC Host Controller (rev 30) Subsystem: Dell Device 046e Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at f0600000 (32-bit, non-prefetchable) [size=256] Capabilities: [a4] …

9 sd-card  ddrescue 

故障したハードドライブからデータを回復しようとする過程で、私はコマンドを実行していddrescueます。 コマンドは9日間実行されており、ディスクアクティビティのサウンドから、何かが実行しているのではないかと思いました。コマンドラインの出力は、これまでずっと多かれ少なかれ静的に見えてきました。 $ sudo ddrescue -r3 /dev/sdb /home/dave/RECOVERY/usb500.image /home/dave/recovery_usb500.logfile Press Ctrl-C to interrupt Initial status (read from logfile) rescued: 0 B, errsize: 0 B, errors: 0 Current status rescued: 0 B, errsize: 500 GB, current rate: 0 B/s ipos: 2539 MB, errors: 1, average rate: 0 B/s opos: 2539 MB, …

9 hard-disk  data-recovery  ddrescue