web-dev-qa-db-ja.com

この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
hard-diskdata-recoveryddrescue
9
Questioner

まだハードドライブからデータを抽出しようとしているのか、それとも成功したのかはわかりませんが、成功しなかった場合に、回復できるかどうか、おそらく失われたかどうかを確認したい場合は、ビットコインなど、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コマンド[不要] ddrescueで不良セクターを再試行したくないため、最初のスイープが完了した後、それを最後まで残し、1 TBのSeagateが故障したハードドライブからデータを救出することに成功しました。 ASSUMEは、2009年から2010年に採掘していたビットコインをいくつか保持している可能性があります。おそらく、それぞれ50 BTCのブロックが1〜3個見つかりました。このハードドライブにあるといいのですが、合計で15日以上かかります。平均634 kbpsの読み取り速度で操作を完了します。

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

また、多くのパラメーターとさまざまなブロックサイズを試してみたところ、電源を入れ直した後、1秒を超えると動作しなくなる完全に完全なハードリヴが残されたため、データスループットの読み取り速度を速くしようとすることに貪欲にならないでください。 （それは5日前でしたが）ありがたいことに、最初は2,000 bs（はい、1秒あたりBYTES）で2kbps未満を読み取って再び生命の兆候を示し始めましたが、私は非常にがっかりしましたが、CTRL + Cでddrescueをキャンセルした後、もう一度（-Rを使用して逆に）再起動するだけで、速度は630に戻りました。前に930 kbpsで読み取りを行っていましたが、少なくとも630 kbpsを逆方向に実行していて、 2 kbpsでオフにするので、500 kbpsの範囲などの任意の読み取り速度で成功し、それ以上のプッシュ速度を試さない場合は、それが読み取り速度を得るための最後の成功した試みである可能性があります。

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

8
m8ty.com

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

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

ログに（複数の）+エントリがない限りandファイルサイズは0のままですddrescueは間違っていると思います。いいえ+sは、ドライブから何も回復できなかったことを意味します。ほんの数セクターに欠陥があると、結果がはるかに速くなったので、それは揚げた電子機器または悪い頭を意味するかもしれません。

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

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

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

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

5
Anthon