努力する過程で故障したハードドライブからのデータ復旧、私はコマンドを実行しています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
答え1
まだハードドライブからデータを抽出しようとしているのか、それともすでに成功しているのかわかりませんが、成功しなかったためにビットコインから失われたデータを回復できるかどうかを確認したい場合は試してください。とにかく私の考えはあなたのようです。ddrescueコマンドラインパラメータが少し変更されたため、以下を追加しました。
$ sudo ddrescue -d /dev/sdb /home/dave/RECOVERY/usb500.image \
/home/dave/recovery_usb500.logfile --force -R
- -d は ddrescue に直接ディスクアクセスを使用するよう指示します。
- --forceは、読み取り/書き込み目的で使用できないと文句を言う場合は、ログファイルを強制的に使用して読み取り/書き込みを行うようにddrescueに指示します。
- -R（たとえば、大文字のR）は、
ddrescueフォワードモードで故障したハードドライブを読み取るのではなく、リバースで回復操作を実行するように指示します。場合によっては、深刻な破損が発生した場合、問題が発生した場合はハードドライブのキャッシュを迂回するため、逆方向に読み取ると便利です。
3現在私はこのコマンドを使用しています。 （ただし、不良セクタを[まだ]再試行したくないので使用していません。ddrescue最初のスキャンが完了してから最後までそのままにしておき、とても元気にしています。年に採掘した可能性のあるビットコインが含まれていると推定されます。合計15日以上かかります。
また、9日以上の「最後の読書活動」の以前の記録に基づいて、ハードドライブが追加の読取りを拒否する状況に直面する可能性が高いという点を付け加えたいと思います。キャンセルするには CTRL+C を押します。ログファイルを操作しているため、エラーが発生したハードドライブからSATAケーブルを抜いてください。ただし、USBポートからUSBコントローラを抜かないでください（たとえば、USB SATAコントローラを使用してください。マザーボードがコンピュータ全体をロックして強制的に再起動しないようにし、SATA電源を再接続して約10秒間ハードドライブを再起動し、上部または、下矢印を押して前のターミナルコマンドを再ロードし、再起動します。以前のログのために中断された場所から操作が続行され、読み取りが完了し、「ddrescue最後の成功の読み取り」は常に「0秒」（0秒）の位置になければなりません。データddrescueがハードドライブから正常に読み取られた後、「最後の読み取り」が秒を数え始めることがわかったら、+をddrescue使用して再び終了し、ハードドライブを再起動してから再起動すると、「最後の読み取り」がゼロに再起動することを確認するのを待ちます必要はありません。私の経験では決して起こらず、永遠に待つことになるでしょう。まだ半分くらい残っていました。CTRLCddrescue
また、より高速なデータスループットの読み取り速度を得ることを望んでいないでください。多くのパラメータとさまざまなブロックサイズを試してみたところ、再起動後1秒以上かかる完全に死んだハードドライブが発生する可能性がありました。動作は停止しました（つまり、5日前）が、幸いにも再び命の兆しが見え始めました。最初は2kbps未満の2,000bs（例えば1秒あたりのバイト）で読み始めました。とても失望しましたが、ddrescueCTRL+Cでキャンセルして再起動しました。再度（-Rとは対照的に）パラメータを追加すると、速度は630に戻り、次に930kbpsで前に読みました。少なくとも630kbpsに満足しています。スピードは後ろに読んでいるので、そうする必要はありません。 2kbps遅れているので、どんな読み取り速度（500kbpsの範囲など）で成功した場合は、それに固執し、速度を上げるために何も試みないでください。これはおそらく最後の成功した試みの読み取り速度を取得する方法です。
または、ddrescueどのパラメータを試しても何も読み取れないために機能しない場合は、ハードドライブのロジックボードを交換することを検討してください。故障したロジックボードは90％の場合は悪いからです。ただし、まずロジックボードを取り外し、ハードドライブピンと接触しているすべての接点を清掃してください。時にはこれらの接点に黒い粘着性の混合物があり、接点を遮断し、これが故障の原因となることがあります。 。ただし、ハードドライブのロジックボードを交換する必要がある場合は、元のドライブとできるだけ似ている必要があるため、同じメーカー、シリアル番号（閉じる）、モデル番号、リビジョン番号のいずれかを受け取る必要があります。寄付委員会が仕事を始めます。
答え2
ddrescueログファイルを使用して中断された場所からジョブ（終了）を再開できるため、停止できるはずです。ただし、タイムスタンプを確認するか、次の手順を実行して、最近ログファイルが更新されたことを確認しますtail -f /home/dave/recovery_usb500.logfile。
イメージファイルがまだ小さすぎるという事実は、まだドライブで正常に検出されていないチャンクに関連している可能性があります。しかし、そう長期的に見ると、これは悪い結果になります。デバイスに不良ブロックがいくつかあり、最初は存在しないと仮定すると、最初の項目の状態はです+。 IIRCddrescueはエラーが見つかるまで読み取りを開始し、ディスクの残りの部分を分割し始めます。ディスクが最初から正しく動作しないようです。
+ログに（複数の）エントリがない場合そしてあなたのファイルサイズはまだ間違っ0ているとは思わないサイズですddrescue。いいえは、+ドライブ内の何も回復できないことを意味します。これは、電子機器が破損しているか不良であることを意味する可能性があります。一部の部品にのみ欠陥がある場合でも、より早く結果が得られるからです。
他のことをすることについて。私はあなたが通常のddを使用していくつかのブロックを読み取ろうとしたと仮定します。これに基づいてシステムログを調べて、そこで見つかったメッセージをGoogleで検索してみましたか？
「結果：ホストバイト=無効なドライババイト= DRIVER_SENSE」を検索すると、興味深いコンテンツ（一部ドイツ語）とより多くの提案が表示されます。
- 2.0の代わりにUSB 1.1を介して接続してみてください。
- ドライブが熱くなる可能性があるため、ビニールで包んで、ドライブが再び熱くなる前に読むのに十分な時間があるように、10分間冷蔵庫に入れてください。
- BIOSのSMARTスイッチ（およびSATA接続）
- USBフラッシュドライブの電源が十分であることを確認してください（追加の電源装置）
- しばらくしてUSBを介した読み取りが失敗した場合は、リモートで制御されているUSBハブを使用して、数秒間プログラム的にUSBハブからドライブに電源を入れます。
読めないディスクを冷却すること（冷却スプレーを使用）以外は直接試したことはありません。