☰

ddrescue を使用して壊れたドライブを回復します。実行が完了する前に進行状況を確認できますか?

tag-icon • tag-icon hard-drive hard-drive-recovery ddrescue
ddrescue を使用して壊れたドライブを回復します。実行が完了する前に進行状況を確認できますか?

現在、故障したドライブで実行していますddrescue。おそらく 16 時間ほど実行されており、まだ故障したブロックを分割している段階ですが、しばらく 0 B/s で実行されています。イメージを作成しているのではなく、別のドライブに直接コピーしています。

進捗状況を確認できますか、それとも何か問題がありますか? 故障したドライブには本当に必要なプロジェクトが 1 つだけあります。それらのファイルがすでにコピーされているかどうかを確認したいだけです。

実行したコマンドは次のとおりです。

ddrescue -d -f -v /dev/sda5 /dev/sdc2 /media/username/USB/rescue.logfile

私は Ubuntu 上で実行しており、古いドライブの OS は Arch でした。

答え1

理論的には、終了 ( ctrl+ C)しddrescueて、後で同じログファイルで実行し、最初からやり直すのではなく続行することができます。この方法が常に機能するわけではないと主張する投稿をいくつか見ました。これらのケースでは、ddrescue以前の作業を無視して、理由は不明ですが最初から開始しました。

ターゲット パーティションを読み取り専用でマウントしてみます。

sudo mount -o ro /dev/sdc2 /mnt/foo

読み取り専用なので、ddrescue操作に影響はありません。ファイルシステムにとって重要なデータがまだ回復されていないというリスクがあり、その場合はmount失敗します。運が良ければ、マウントして必要なファイルを読み取ることができるかもしれませんが、およびmount(例)からエラーが発生しなくても、ファイルが破損している可能性があります。ファイルまたはそのコピーを調べてください。ファイルが有効であり、内部に回復されていない/破損したフラグメントがないことを確認しない限り、cp終了しないでください。ddrescue

問題が発生した場合、ddrescueさらにデータを回復するまで待つことができます (ある場合)。システムがメタデータやファイル自体などをキャッシュする可能性があるため、破損していないファイルがマウントポイントの下に表示されるまで待つことはお勧めしません。 を実行し、umountさらにデータが回復されるのを待ってから、mountもう一度ファイルを確認してください。

編集: 追加の質問に答えます。

ddrescue に特定のフォルダーを指定するように指示する方法はありますか?

いいえ。このツールはブロック レベルで動作します。ファイル システムやファイルについては何も知りません。「ddrescuelog によると、ファイルの 99.73% が回復されました」という記述は、「ブロックの 99.73%」とすべきです。

また、99.73% が復元されたと表示されているので、データは復元されているものの、ファイルとして認識できないほど損傷がひどいという可能性はありますか? この場合、損傷したファイルを表示するプログラムはありますか? おそらく、一部を手動で復元できるでしょう。

考えられるシナリオ: ファイルの内容は回復されるが、対応するファイルシステムのエントリは回復されない (注: 一般的には逆のことも起こり得ますが、明らかにあなたの場合はそうではありません)。フォルダー全体が消えたとおっしゃっています。ファイルの一部は後で表示される可能性があると思いますlost+found(fsckまたはファイルシステムによっては同様の方法で表示されることがあります。それが何であるかはわかりません)。

詳細はこちら:Linux および Unix の lost+found フォルダーの目的は何ですか?

この操作は読み取り専用ではないため、 が動作しているfsckときには実行しないでください。 を終了して実行し、再開することもお勧めしません。 が完了するまで待つことをお勧めします。 時間がかかる場合があります。ddrescueddrescuefsckddrescueddrescueこれそしてこれ。

一般的には、fsck復元したデータのコピーに対して (または読み取り専用ではない他のツール) で作業する必要があります。今後の参考のために、次の方法をお勧めします。

  1. デバイスではなくファイルに書き込みます。コピーオンライト (COW)特徴。
  2. 作る牛でコピーしますcp --reflink=always。ddrescue操作中にこれを行うことができます。このコピーは、ターゲット ファイルのスナップショットのようなものです。
  3. 読み取り専用ではないツールも含め、コピーに対して任意のツールを使用します。
  4. 障害が発生した場合でも、元のターゲットファイル（ddrescueまだ実行中であれば、より多くのデータが回復されている可能性があります）が残っているので、別のファイルからやり直すことができます。牛コピーします（おそらく別のツールで）。

削除されたファイルを検索して復元することもできます。ツールの選択はファイルシステムによって異なります。

もう 1 つのヒント: ソフトウェアがファイルシステム階層内の別の場所で一時ファイルを使用していた可能性があります。 、 を確認して/tmp/ください/var/tmp/。

編集して追加の質問に答えます。

ddrescuelog でブロックの 99.73% が復旧されたと表示される場合、それは具体的に何を意味しますか? 空のホーム ドライブではなく、何らかの結果を期待する必要があるようです。

注: 以下の例は、すべてのファイルシステムの問題とシナリオを網羅することを意図したものではなく、ディスク セクターとファイルシステムの割り当て単位を区別することを意図したものではなく、質問に答えることのみを目的としています。

パーティションを本だと想像してください。百科事典であり、筋書きのある小説ではありません。ファイルはその中の記事です。ディスクブロック（またはセクター）は本のページのようなものです。ファイルシステムは、ページに記事を配置する一般的な方法です。一部のページには、目次これは、私たちの図ではファイルシステムの問題であり、次のようになります。

記事#289: 2076、2077、2078、402、403ページ。

この記事はファイルとして断片化されていることに注意してください。別のページにありますが、目次次のようなフォルダ構造があります:

…
people/： 見る目次43ページ
…
（43ページ）
mathematicians/を参照目次80ページ
famous Poles/参照。目次82 ページ
Adam and Eve: 記事 #14 を参照してください。
…
(80 ページ)
Euclid: 記事 #289 を参照してください。
Banach Stefan: 記事 #4380 を参照してください。
…
(82 ページ)
Banach Stefan: 記事 #4380 を参照してください。
Kościuszko Tadeusz: 記事 #2208 を参照してください。
…

この構造は、ハードリンクされたファイルの例です。 1 つの記事を指すパスが少なくとも 2 つあります:./people/mathematicians/Banach Stefanと。ここで各パスの先頭にドットを配置したのは、この例では、 section がどのセクションに属しているか (またはまたはの場合もあります)./people/famous Poles/Banach Stefanという情報を意図的に隠しているためです。people//people//full articles/people//stubs/people//foo/bar/people/

の目次次のようなセクションもあるかもしれません:

「空の」ページ: 567、568、569、2070、2071…

あるページには、その時点で存在するどの記事にも属していない場合でも、テキスト（つまりデータ）が含まれています。これは、記事の削除プロセスが、目次。目次特定のページがどの記事に属しているか、または空として扱われて上書きされるかを判断する唯一の確実な方法です。さらに、「空のページ」を見つけるには、目次百科事典では、記事の一部に空白ページがあるのは奇妙に感じますが、0sやスペースなどでいっぱいのセクターはファイルの一部になることがあります。目次。

一部のページ（ブロック）はまだ復旧されていません。その中の1つは記事データまたは目次-メタデータ。可能性:

  • 欠落しているブロックはデータ ブロックです (たとえば、ページ 2078)。Euclid に関する記事へのパスと、その記事がどのページにあるかはわかっていますが、ページの 1 つが空白になっています。これは、空白であるべきではないためです。記事は無効です。
  • 欠落しているブロックはメタデータ ブロックです。いくつかのシナリオ:
    • 空き容量を把握できなくなりました。
    • パスがあることはわかっています./people/mathematicians/Euclidが、記事がどのページにあるかという情報がありません。記事についてすでに何か知っている場合を除き、記事を見つけることは不可能です (たとえば、人物に関するエントリには「born」という単語が含まれている可能性が高く、PDF ファイルは「%PDF」で始まります)。
    • 特定のページに記事が 1 つあることはわかっていますが、そこへの完全なパスはありません。その場合は、その下に配置すればうまくいきます。図にはlost+found、次のようなfsck可能性があります (他にもいくつかあります):
      • 80 ページがありません。(43 ページから) セクション (フォルダー) があることはわかっていますmathematiciansが、記事 #289 が「Euclid」という名前でそこに含まれているはずであることがわかりません。
      • 43 ページが欠落しています。アダムとイブに関する記事 #14 や、数学者や有名なポーランド人に関するセクションがあるはずがわかりません。しかし、(80 ページ) にはユークリッドとバナッハに関する記事があるセクションがあり、(82 ページ) にはバナッハとコシチュシュコに関する記事があるセクションがあることがわかります。これは、あなたの で起こっている可能性があります/home。記事（ファイル）は存在し、有効である可能性があります。パスがないため、アクセスできません。目次あなたの/home。
  • 回復されていないブロックが複数ある場合、上記の問題が複数組み合わさって発生する可能性があります。
  • 欠落したブロックは空としてマークされる場合があります。この場合、何も失われません。

関連情報