この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,     time from last successful read:     9.7 d
Splitting failed blocks... 

変更された一つの部分は、それが言うところであるiposとopos。500000 MB障害が発生したディスクドライブのサイズであるに達するまでに9日かかりました。それがそこに着いたとき、しかし、それはそれから下に0下がり、再び上昇し始めました。私がこれを書いているように、それは約で2580 MB、数えています。

作成される画像ファイルの長さは0バイトです。

ログファイルのサイズは約3MBで、次のようになります。

# Rescue Logfile. Created by GNU ddrescue version 1.14
# Command line: ddrescue -r3 /dev/sdb /home/dave/RECOVERY/usb500.image /home/dave/recovery_usb500.logfile
# current_pos  current_status
0x975C3000     /
#      pos        size  status
0x00000000  0x00862000  -
0x00862000  0x00014800  /
0x00876800  0x00800400  -
~~~~~~edited for brevity ~~~~~~~~
0x74702CCE00  0x00320000  -
0x74705ECE00  0x00025800  /
0x7470612600  0x005F3A00  -

これは単なる時間の浪費であり、データがまったく回復されないことを心配し始めています。

この出力から、何か有用なことが起こっているという兆候はありますか？

ddrescueコマンドをそのまま続行させる理由はありますか、それとも停止して別のことをする必要がありますか？

これはの最新のコンテンツです /var/log/syslog

Jun 10 07:29:17 homebase-i3 kernel: [568470.316436] sd 5:0:0:0: [sdb]  Sense Key : Medium Error [current] 
Jun 10 07:29:17 homebase-i3 kernel: [568470.316443] sd 5:0:0:0: [sdb]  Add. Sense: Unrecovered read error
Jun 10 07:29:17 homebase-i3 kernel: [568470.316450] sd 5:0:0:0: [sdb] CDB: Read(10): 28 00 11 ff 02 98 00 00 08 00
Jun 10 07:29:17 homebase-i3 kernel: [568470.316465] end_request: critical target error, dev sdb, sector 301925016
Jun 10 07:29:17 homebase-i3 kernel: [568470.346640] sd 5:0:0:0: [sdb] Unhandled sense code
Jun 10 07:29:17 homebase-i3 kernel: [568470.346646] sd 5:0:0:0: [sdb]  Result: hostbyte=invalid driverbyte=DRIVER_SENSE
Jun 10 07:29:17 homebase-i3 kernel: [568470.346651] sd 5:0:0:0: [sdb]  Sense Key : Medium Error [current] 
Jun 10 07:29:17 homebase-i3 kernel: [568470.346656] sd 5:0:0:0: [sdb]  Add. Sense: Unrecovered read error
Jun 10 07:29:17 homebase-i3 kernel: [568470.346662] sd 5:0:0:0: [sdb] CDB: Read(10): 28 00 11 ff 02 98 00 00 08 00

それでもハードドライブからデータを抽出しようとしているのか、それともすでに成功したのかはわかりませんが、成功しなかったために、回復できるかどうか、おそらく失われたかどうかを確認したい場合は、ビットコインなど、ddrescueコマンドラインパラメータにいくつかの変更を加えました。以下を追加しました。

$ sudo ddrescue -d /dev/sdb /home/dave/RECOVERY/usb500.image \
     /home/dave/recovery_usb500.logfile --force -R

• -dは、直接ディスクアクセスを使用するようにddrescueに指示します。
• --forceは、読み取り/書き込みの目的でログファイルを使用できないと不平を言った場合に備えて、強制的に使用し、ログファイルを読み取り/書き込みするようにddrescueに指示します。
• -R（はい、CAPITAL Rを使用）は、障害がddrescue発生したハードドライブをフォワードモードで読み取る代わりに、回復操作をリバースで実行するよう指示します。問題が発生した場合に備えてハードドライブのキャッシュを迂回するため、損傷が大きい場合は逆に読むと役立つことがあります。

現在、私はこれらのコマンドを使用しています（3[YET]でddrescue不良セクターを再試行したくないため、コマンドを使用していませんが、最初のスイープが完了した後、それを最後まで残し、大成功を収めています1 TB Seagateのデータがハードドライブで故障したため、2009年から2010年に採掘していたビットコインをいくつか保持している可能性があります。おそらく、それぞれ50 BTCのブロックが1〜3個見つかりました。このハードドライブにあるといいのですが、平均634 kbpsの読み取り速度で操作を完了するには、合計15日以上かかります。

また、「最後の読み取りアクティビティ」の9日間以上の以前の実績に基づいて、ハードドライブがそれ以上の読み取りを拒否するという状況に遭遇する可能性が高いことを付け加えておきます。ログファイルを使用しているため、CTRL + Cを押してキャンセルし、障害が発生したハードドライブからSATAケーブルを取り外しますが、USBポートからUSBコントローラーを取り外しません（はい、接続する代わりにUSB SATAコントローラーを使用します）コンピュータ全体をロックアウトせずにハードリブートを強制しないマザーボード。SATA電源を再接続してハードドライブを再起動します。10秒ほど待ってから、上矢印または下矢印を押して、以前のターミナルをリロードします。コマンドと再起動ddrescue操作は、以前のログのおかげでそれが最後の中断したところから継続するものと行われているが読みになり、「最後に成功した読み取りは、」常にそれが、あることを示す必要がある「0」（ゼロ秒）に滞在するものddrescueであることに成功中をハードドライブからの読み取り、および「最後の読み取り元」が秒のカウントを開始することに気付いた場合はddrescue、CTRL+ Cでもう一度終了し、ハードドライブの電源を入れ直して再起動しますddrescue、「最後の読み取り元」がそれ自体で0に再起動するかどうかを確認しても意味がありません。私の経験に基づいて、それが起こることは決してないので、あなたは永遠に待つことになります。私は不良の1 TBハードドライブを合計で約20回電源再投入する必要がありました。7日間で、500 GBの回復マークに非常に近づいています。まだ途中です。大きな障害が発生しないことを願っています。過去3日間で問題なく動作し、再び634 kbpsを超えているため、私はほぼ100％です。

また、多くのパラメーターとさまざまなブロックサイズを試してみたところ、電源を入れ直した後、1秒以上経過するとハードリバーブが完全に機能しなくなるため、データスループットの読み取り速度を速くしようとすることに貪欲にならないでください。 （5日前でした）ありがたいことに、最初は2,000 bs（1秒あたりBYTESでした）で2kbpsを少し下回って読み取りを再開しましたが、非常にがっかりしましたが、キャンセルした後ddrescueCTRL + Cを押してもう一度（-Rを使用して逆に）再起動するだけで、速度は630に戻りました。前に930 kbpsで読み取りを行っていましたが、少なくとも逆に630 kbpsを実行していることに満足しています。 2 kbpsで延期する必要がないので、500 kbpsの範囲などの読み取り速度で成功した場合は、それをそのままにして、速度を上げるために何もしないでください。読み取り速度。

または、ddrescue試行するパラメーターに関係なく何も読み取れないためにが役に立たない場合は、ロジックボードが90％の時間になるので、ハードドライブからロジックボードを交換することを検討してください。悪いですが、最初に、ロジックボードを取り外して、ハードドライブのピンと接触するすべての接点をクリーニングします。これらの接点に黒っぽいねばねばした混合物が混ざり、障害の原因である可能性のある接点が切断されます。ただし、ハードドライブのロジックボードを交換する必要がある場合は、同じブランド、シリアル番号（に近い）、モデル番号、リビジョン番号のいずれかを取得する必要があります。働くための寄付委員会。

ddrescueログファイルを使用するため、停止した場所から操作を再開（閉じる）できるため、停止できるはずです。ただし、タイムスタンプを見たり実行したりして、ログファイルが最近更新されているかどうかを確認しますtail -f /home/dave/recovery_usb500.logfile。

画像ファイルがまだ小さいことは、ドライブから正常にブロックが取得されていないことに関係している可能性があります。しかし、この時間をすべて実行しても、それは悪い結果になります。デバイスにいくつかの不良ブロックがあり、それらが最初にない場合、最初のエントリのステータスはになります+。IIRC ddrescueは、エラーが見つかるまで読み取りを開始し、ディスクの残りの部分の分割を開始します。ディスクは最初から失敗しているようです。

+ログに（複数の）エントリがあり、ファイルサイズがまだ変わらない0限り、私ddrescueは間違っているとは思いません。+ドライブから何も回復できなかったという意味ではありません。それは揚げた電子機器または悪いヘッドを意味するかもしれません、いくつかのセクターだけが不良である場合、あなたははるかに迅速に結果を得たでしょう。

他のことをすることに関しては。私はあなたがすでに通常のddでいくつかのブロックを読んでみたと思います。これに基づいてsyslogを確認し、そこで見つけたメッセージをグーグルで検索しましたか？

「結果：hostbyte = invalid driverbyte = DRIVER_SENSE」を検索すると、いくつかの興味深い読み取り（一部はドイツ語）が行われ、さらにいくつかの提案が表示されます。

• 2.0ではなくUSB 1.1で接続してみてください
• ドライブが熱くなる可能性があるため、ドライブをプラスチックで包み、冷蔵庫に10分間入れます。これにより、ドライブが再び熱くなるまでの読み取り時間を確保できます。
• BIOSのSMARTのスイッチ（およびSATAに接続）。
• USBドライブに十分な電力があることを確認してください（追加の電源）
• しばらくしてUSBの読み取りに失敗する場合は、リモートで制御されているUSBハブを使用して、プログラムでUSBハブからドライブに数秒間電源を切り替えます。

（冷却スプレーを使用して）読み取り不可能なディスクを冷却することを除いて、私はこれらのいずれも自分で試したことはありません。