ドライブが断続的に切り取られることからの脱出、ソフトウェアを介してパワーサイクリングを自動化する方法？
故障したWindows/NTFSドライブがあります。 USB-IDEケーブルを介して別のPCに接続し、Knoppix 7.2LiveUSBとddrescue/ddrutitliyを使用してドライブのほとんどを回復することができました。最も重要なデータを復元しました。今、私はそれを学習演習として使用しており、プロセスを簡単にすることができたかどうか、そしてハードウェアをいじることなくどれだけ取り戻すことができるかを確認しています。
以下に完全な説明がありますが、ドライブ（USBまたはその他）の状況を処理するためのスクリプトを作成して、間欠的に、または既知の理由で救助中に切断された人がいるかどうか疑問に思いました。
ddru_ntfsbitmapを使用して、ブートセクターとMBRビットマップをプルして、使用したファイルスペース（60GBドライブで16GB）にリカバリを絞り込むことができました。使用したコマンドは次のとおりです。
ddru_ntfsbitmap -i 32256 -m MFTDomainFile.txt /dev/sdc filelocations.txt
（-iは63*512 = 32256を使用します。ドライブはfdiskから63を見つけるためにマウントされないため、ddru_ntfsbitmapがブートセクタを見つけることができると私に言うまで推測しなければなりませんでした。どうやら通常は63です。または2048。）
このドライブは頻繁にカットアウトし、単一セクターの読み取りエラーの後にカットアウトするドライブセクションが1つ（最初の950MB）あります。続行するには、usb-IDEケーブルを引っ張ってから再度接続して、ドライブを/ devに戻す必要があります。このPCでは（またはKnoppixに関係している可能性があります）、ドライブが停止した場合、ddrescueは追加の読み取り試行をエラーとしてマークし続け、「実際の」セクター読み取りの問題を追跡することを困難にします。 （Ubuntuを搭載した別の古いPCでは、どういうわけかこれを検出してddrescueを終了します。これは素晴らしい機能ですが、その異なる動作の原因はわかりません。）数回の起動と再起動で、次のことができました。 ddrescueを使用して、一度に大きなセクションを読み取り/コピーし、ディスクの大部分を取得します。 （より適切に動作するセクションの> 95％）。 -iおよび-sオプションを使用して回避し、「すべてを不良としてマークする」問題の影響を制限します。
一般的に、私が使用したコマンドは次のようなものでした。
ddrescue -S -m filelocations.txt /dev/sdc HDImage.img HDRecoverlog.txt -r2 -d -i5GB -s1GB
切り取られた場合、その1GBセクションのみが不良としてマークされ、-AMの追加を再試行してコピーをブロックするか、-r5で実行できます。遅いセクションではコピー速度はそれほど重要ではないようで、ブロックコピーを行うとより頻繁にカットされます。
未試行の大きなセクションをすべて取得した後、ドライブのより安定した部分でddrescueを一晩実行できるようにすると、そのセクションのほとんどのセクターエラーが検出されました。 ddru_ntfsfindbad（どのファイルにエラーがあったかを見つけるため）は$ MFTで20セクターのエラーを報告したので、次を使用して一晩再実行しました。
ddrescue -S -m MFTDomainFile.txt /dev/sdc HDImage.img HDRecoverlog.txt -r-1 -d
これにより、すべての$MFTエラーが検出されたので、ddru_ntfsfindbadを実行して、ドライブの残りの部分にまだエラーがあるファイルを見つけました。
ddru_ntfsfindbad -i 32256 -DD -HDImage.img HDRecoverlog.txt
（-DDは、各iノードのセクター位置を含むデバッグログファイルを生成します。これを通常のntfsfindbad.logと組み合わせて、エラーのあるすべてのファイルを見つけることができます。）
週末全体にわたって安定した部分でddrescueを実行させるだけで、そのセクションの2つのセクターエラーを除くすべてが検出されました（金曜日の1112エラーから）。 ddru_ntfsfindbadを再実行すると、はるかに小さなファイルエラーリストが生成されました。
ドライブの難しいフロント部分については、「不良」とマークされた約150MBがまだありました。多くは単にスキップ/未試行でしたが、ドライブのカットアウトと同じくらい悪いとマークされていました。 ntfsfindbadログを使用すると、次の（明らかによく知られている）面倒なプロセスでファイルを手動でターゲットにすることができます。
- USBコネクタを差し込みます。
- スピンアップ後に
ddrescueコマンドを発行します。 - 不良セクタに引っかかると聞いた場合は
CTRL-Cを押してください。そうでない場合は、上記のように場所を失います。CTRL-Cを使用すると、次のセクターで停止し、次回はそこで開始します。-Xオプションを使用すると、これは不要になりますが、前進するのではなく問題のあるセクターに留まり、本当に不良セクターを通過することはありません。
- ドライブを抜いて電源を切る
- 後藤（1）
関心のあるほとんどのファイルは、この方法で完全に回復することができました。大きな未試行のセクションを手動でターゲット/分割すると、セクション全体がエラーなしでプルされる可能性があります。しかし、特定のエラーを10〜20回再試行しなければならない場合があります。このプロセスを使用すると、約150kBを除くすべてのエラーが「迅速に」クリーンアップされました。それ以来、手動で再試行すると、合計で最大55の単一セクターエラーと31kBになりました。ドライブの残りの部分の動作に基づいて、いくつかの実際に不良セクタを除いてすべてを削り取り、少数のファイルを置き換えた後にイメージ全体を機能させることができても驚かないでしょう（もちろんWindows/system32は座っています）そのセクションで）。
これは、データがこれほど回復可能であるという、かなり幸運な（まれではありますが）ケースに相当することを私は理解しています。しかし、私が救出した最後のディスクには、非常によく似た「単一の読み取りエラーでドライブがカットアウトする」という問題がありました。ディスクやUSBポートをリセットまたは電源を入れ直す方法についての投稿をいくつか読みました。私が見たところ、USB電力を削減する機能は、ハードウェアとLinuxカーネルの両方に大きく依存しています。また、これを支援するハードウェアとサービスのソリューションがあり、費用便益の全体像が異なっていれば価値があることも理解しています。
それで、上記の5ステップのプロセスを処理するためのより良い方法はありますか？これにより、「良好」セクションの最初のデータスクレイピングも高速化された可能性があります（手動では少なくなります）。プロセス全体に取り組むためのより良い方法（まだDIY）はありましたか？
[〜＃〜] tlre [〜＃〜] を1秒に設定すると、電源サイクルの問題が修正されました：smartctl -l scterc,10,10 /dev/sdX
USBエンクロージャーの不良SSDでも同じ問題が発生し、ddrescueが不良セクターに遭遇するたびに、ディスクの/dev/sd…デバイスが消えていたため、USBを200〜300回抜き差しする必要がありました。 、または不良セクタの近くにあったddrescueファーストパス「ビッグブロック」モードで何かを読み取ろうとしました。
今回は自分に合った解決策は見つかりませんでしたが、これに一度以上遭遇する人はUSBリレーボードの恩恵を受けるだろうと考えていました。 -）たとえば、 usbrelay ソフトウェアを使用して、コマンドラインから制御できます。リレーは特別に細工されたUSB延長ケーブルに接続され、そこで電源線を遮断して再接続します。これは、デバイスのプラグを抜き差しするのと同じであり、システムはデバイスを再検出する必要があります。スクリプトがデバイスの再接続を開始できるようになったため、ソフトウェアのすべてを自動化できます。