2 TB の大容量ハード ドライブからデータを救出する必要があり、問題のあるハード ドライブが USB 3 を使用して接続され、データを受信するために必要なサイズの仮想ディスクが VM によってローカルに提供される VM 内の Live-Linux でこれを行っています。次に、状況を確認するために次の呼び出しを実行しました。
ddrescue -f /dev/sdc /dev/sdb /mnt/sda1/ddrescue.map
sdcUSB の壊れたデバイスは、sdbデータを受信するための仮想ディスクであり、sda1一時的な保存用であり、Ext4 を使用してフォーマットされています。
最初はすぐに動作し始め、ddrescue数分以内に約 45 GB のデータを読み取ることができましたが、その後速度が大幅に低下し、数日間、1 秒あたり数バイトしか読み取れませんでした。したがって、これらの部分でデバイスが壊れていることは明らかで、私は次々--input-position=[...]GBに複数の呼び出しを使用してこれらの部分を単純にスキップしようとしました。ジャンプした場所に応じて、物事は再び高速に読み取りを開始し、再び遅くなるまで、別の呼び出しを使用して再びジャンプしました。注目すべき重要な点は、によって印刷された入力と出力の位置はddrescue常に同期されていることです。提供されたマップ ファイルでも手動で何も変更したり、削除したりしていません。それは常に 1 つの同じファイルであり、それddrescue自体によってのみ管理されています。
その後、私はアプローチを少し変更し、--input-position手動ではこれ以上使用せず、代わりに次の方法を使用することにしました。
ddrescue -f --min-read-rate=1MB --skip-size=1MB /dev/sdc /dev/sdb /mnt/sda1/ddrescue.map
そのためddrescue、遅い部分が認識されるたびに、データの合理的な破損ブロックをスキップして読み取りを続行しました。ここでも、入力と出力の位置は同期しており、読み取りと復元されたデータのカウンターは常に増加していました。ここまでで作業はddrescue完了し、約 650 GB のデータが復元されたと言われています。
問題は、仮想ディスク ファイル自体を最終的に確認した後、実際に保存されているデータは約 160 GB しかないように見えることです。さらに、最後の書き込みタイムスタンプが数日古すぎました。そのため、何らかの理由でddrescue大量のデータを読み込んでいると思っていましたが、壊れたディスクから読み込んだ仮想ディスクの場所に適切に書き込まれていないようです。結局のところ、私の理解では、仮想ディスクには、少なくとも、ddrescue救出されたデータの量について記載されているサイズがあるはずでした。
ddrescue指定されたすべてのデータを適切に読み取ったものの、後続の呼び出しで既に復元されたデータを上書きしただけのように感じます。したがって--input-position、読み取り元として認識されているものの、ターゲットでは常に位置 0 から書き込みが開始されているようです。
もちろん、データを書き込む開始位置を指定していませんが、ドキュメントそれは必要ではなく、ddrescueとにかく入力と出力の位置は常に同じになるように印刷されます。
-o bytes
--output-position=bytes
Starting position of the image of the rescue domain in outfile, in bytes.
Defaults to '--input-position'. The bytes below bytes aren't touched if
they exist and truncation is not requested. Else they are set to 0.
もちろん、私は切り捨てを要求しませんでした。ドキュメントによると、切り捨てはデフォルトでは有効になっておらず、指定したターゲット ドライブでも機能しなかったはずです。
-t
--truncate
Truncate outfile to zero size before writing to it. Only works for regular
files, not for drives or partitions.
それで、何が間違っていたのか、何か考えはありますか? 異なる値を使用した複数の呼び出しが--input-positionすでに間違っていましたか? パーティションやファイルではなく、ドライブの読み取りと書き込みに関係していますか?
おそらく、仮想ディスクへの書き込みに問題があるのでしょうか? ただし、それが何らかの違いを生む理由はわかりません。また、仮想ディスクに書き込む必要があり、必要なサイズの raw デバイス ストレージを提供できません。
ありがとう！
答え1
--input-positionddrescue で複数の異なるものを使用しても安全ですか?
以前その例を見逃していたようですが、実際に私がやったことはそれであり、私のアプローチがサポートされていることを示唆しています。
Example 5: While rescuing a partition in /dev/sda1 to the file hdimage, /dev/sda1 stops responding and begins returning read errors, causing ddrescue to mark the rest of the partition as non-scraped.
ddrescue -n /dev/sda1 hdimage mapfile <-- /dev/sda1 fails here
(restart /dev/sda or reboot computer)
ddrescue -n -A -i<pos> -O /dev/sda1 hdimage mapfile
(if /dev/sda1 fails again, restart /dev/sda or reboot computer and
then repeat the above command as many times as needed until it
succeeds. <pos> is the position where the drive stopped responding)
ddrescue -d -r3 /dev/sda1 hdimage mapfile
https://www.gnu.org/software/ddrescue/manual/ddrescue_manual.html#例
2 回目の呼び出しは、異なる位置で繰り返されることが明確に文書化されています。ddrescueマップ ファイルを使用して がどのように機能するかについては、そのファイルを使用してどのブロックがすでに読み取られたかを常に認識しているため、これも理にかなっています。
したがって、私のケースの問題は異なる可能性が高いようです。特に、私が認識したタイムスタンプが古すぎるのは奇妙です。ddrescue何らかの理由で実際のターゲット デバイスに書き込まれていないメッセージを単に見逃しただけかもしれません。VM 自体も別の USB ドライブにあり、実行時に Live-Linux によってデバイスが見逃されるような接続エラーがあったのかもしれません。ログに記録されたすべてdmesg -Tの読み取りエラーのため、このようなエラーを簡単に見逃した可能性があります。
プロセス全体を繰り返す必要があるようです...
答え2
マニュアルを読みましたddrescueが、複数のinput-positionパラメータの可能性についてはどこにも触れられていません。
このパラメータは常に「a」または「the」として記述されるため、一意である必要があるようです。
問題の原因は、マニュアルの次のフレーズである可能性があります:
元のレスキュー実行の '--input-position' と '--output-position' 間の元のオフセットを維持する必要があることに注意してください。
これは次の他の段落と一致するようです:
Ddrescue は、入力に不良セクタが見つかった場合、出力にゼロを書き込むことはなく、要求されない限り出力ファイルを切り捨てることもありません。そのため、同じ出力ファイルで実行するたびに、すでに救出されたデータを消去することなく、ギャップを埋めようとします。
これは、ddrescue最初の実行からのパラメータを記憶することを意味します。したがって、常に同じパラメータを保持するか、または後続の実行でパラメータを指定しないことが想定されます (どちらが正しいかはわかりません)。一部のパラメータが記憶され、後続の実行で新しいパラメータが無視される可能性は十分にあります。
ディスクのメタ テーブルの一部が破損している場合は、これらの部分を含むファイルが存在しないため、実際に回復されたデータよりも少ないデータが表示される可能性があります。
復旧できないデータは、ddrescue他の復旧製品で復旧する必要があります。この作業には長い時間がかかり、ご利用可能な製品では不可能な場合もあります。どうしてもデータを復旧する必要がある場合は、専門の復旧会社に依頼すれば元のディスクから復旧できるかもしれませんが、こうしたサービスは高額です。
答え3
のマニュアルページはddrescue長いので、 の使い方はddrescue目的やユーザーレベルによって大きく異なります。基本的に、Live Linux を使用する場合は、VM ではなく物理マシンで実行し、ディスクを sATA/USB アダプターなしで sATA に接続することをお勧めします。
その他の機能の中には、ddrescueカーネル ディスク ドライバーとバッファーをバイパスできるものがあり、そのため不良クラスターの無駄な繰り返し読み取りを減らすことができます。マップファイル (以前はログファイルと呼ばれていました) には、読み取りに失敗したクラスターと失敗したクラスターのすべてに関する情報が保持されるため、クラッシュした手順を繰り返すだけで済みます。 はddrescueジョブを開始する前にマップファイルを検索し、マップファイルを作成します。マップファイルが存在しない場合は読み取り、使用可能な場合は最後に記録された位置からレスキュー ジョブを続行します。プログラムがクラッシュするたびに、手動で開始位置を移動する必要はありません。
さまざまなオプションを使用して、レスキュー プロセスをより迅速かつ安全に実行できます。また、レスキュー プロセスを 2 つ以上のステップに分けることもできます (推奨)。
最初のステップ: 良いクラスターを素早く読み取り、悪いクラスターをすぐにスキップします。
2 番目のステップ: 前のステップで読み取られていないクラスターを処理し、特別なオプションを使用してディスク機能 (NCQ、先読みなど) をトリックし、一度に 1 つのセクターを読み取る必要があります。適切なコマンド (私が使用) は次のとおりです。
ddrescue -n -p -d -r1 /dev/sdd $IMGPATH/disk.img $IMGPATH/disk.log;
ddrescue -d -r3 -R /dev/sdd $IMGPATH/disk.img $IMGPATH/disk.log;
# | | | | |
# | | | | revers reading
# | | | retry read 1x (3x)
# | | direct access to disk (bypass the kernel)
# | preallocate diskspace
# nonscrap
ディスクの熱が高すぎる場合や、読み取り操作が多すぎる場合は、次のオプションを使用して読み取り速度を遅くすることができます。--max-read-rate=50M
これは最初の接触のみを対象としていますが、 に関する専門クラブやフォーラムで多くのアドバイスを見つけることができますddrescue。