web-dev-qa-db-ja.com

特定のext4ブロックがiノードテーブルにあるかどうかを確認できますか？ある場合は、ヘッダーのないジャーナルから手動で選択できますか？

そのため、古いラップトップから新しいラップトップに移動する途中で、古いラップトップのハードドライブに物理的な損傷が発生しました。 badblocksは64個の不良セクタを報告します。 /パーティションと/homeパーティションが分割された2か月前のUbuntuGNOMEセットアップがありました。私の知る限り、/のいくつかのセクターが損傷しましたが、それは問題ではありません。一方、/homeのパーティションは、この注釈付きのddrescueログを提供します。

# Rescue Logfile. Created by GNU ddrescue version 1.17
# Command line: ddrescue -d -r -1 /dev/sdb2 home.img home.log
# current_pos  current_status
0x6788008400     -
#      pos        size  status
0x00000000  0x6788000000  +
0x6788000000  0x0000A000  -
    first 10 sectors of the ext4 journal
0x678800A000  0x2378016000  +
0x8B00020000  0x00001000  -
    inode table entries for /pietro (my $HOME) and a few folders within
0x8B00021000  0x00006000  +
0x8B00027000  0x00001000  -
    unknown (inode table?)
0x8B00028000  0x00004000  +
0x8B0002C000  0x00001000  -
    unknown (inode table?)
0x8B0002D000  0x001DC000  +
0x8B00209000  0x00001000  -
    unknown (inode table?)
0x8B0020A000  0x00090000  +
0x8B0029A000  0x00001000  -
    unknown (inode table?)
0x8B0029B000  0x4420E65000  +

Debugfsのicheckおよびtestbコマンドを使用して注釈を付けました。損傷したすべてのブロックは使用済みとしてマークされます。いくつかのスーパーブロック統計：

Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      972
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512

だから私の質問は：

  1. Iノードエントリでない場合でも、これら5つの不明なブロックが何であるかを正確に知ることができますか？私の疑いは、それらがiノードテーブルエントリであるということですが、icheckは言いたくありません。もしそうなら、どのiノードを見つけることができますか？
  2. ジャーナルの最初の10ブロックが失われた場合でも、これらのiノードテーブルエントリをジャーナルから手動で復元できますか？

私はfsckでこのデータ復旧をしたくありません。これは、すべてのファイルを/lost+foundで、フラット化されたディレクトリ構造と重複ファイルの巨大な混乱にダンプするだけです...

ありがとう。

data-recoveryext4ddrescuejournaling
6
andlabs

さて、最初の質問では、debugfsstatsコマンドが、グループのすべてのセクションの開始ブロックが何であるかを示していることがわかりました。さらに、iノードテーブルへのオフセットの基本的な追加とimapコマンドにより、最初のインバーが得られたので、インバーは連続して増加する必要があると推測しました。それはまた、私のブロックグループの計算がそれが間違ったグループにあることを示した最後の不良セクタについての私の疑いを確認しました。

byte address  block      group  what                   first inumber
0x8B00020000  145752096  4448   inode table block 0    36438017
0x8B00027000  145752103  4448   inode table block 7    36438129
0x8B0002C000  145752108  4448   inode table block 12   36438209
0x8B00209000  145752585  4448   inode table block 489  36445841
0x8B0029A000  145752730  4449   inode table block 122  36448161

ブロックは4096バイトで、各iノードテーブルエントリは256バイトであるため、ブロックごとに16個のiノードがあります。これで、80個すべてのiノードテーブルエントリがinumberによって失われました。

それでは、ジャーナルに目を向けましょう。私は書いた 小さなツール ジャーナルの各ブロックに情報をダンプします。ジャーナルのスーパーブロックが欠落していたため、これに必要な2つの情報が失われました。

  • ジャーナルが64ビットのブロック番号を保持していたかどうか
  • ジャーナルがバージョン3のチェックサムを使用したかどうか

幸い、これらのスイッチの1つ（または両方）を強制的にオンにすると、ジャーナル内の記述子ブロックの一部がそのブロックをオーバーフローし、それらのフラグが設定されていないことを証明しました。

1つのawkスクリプト（fulllog.awk）後で、フォームのログがあります

0x0002A000 - descriptors
        0x0002B000 -> block 159383670
        0x0002C000 -> block 159383671
        0x0002D000 -> block 0
        0x0002E000 -> block 155189280
        0x0002F000 -> block 195559440
        0x00030000 -> block 47
        0x00031000 -> block 195559643
        0x00032000 -> block 195568036
        0x00033000 -> block 159383672
0x0002B000 - invalid/data block
0x0002C000 - invalid/data block
0x0002D000 - invalid/data block
0x0002E000 - invalid/data block
0x0002F000 - invalid/data block
0x00030000 - invalid/data block
0x00031000 - invalid/data block
0x00032000 - invalid/data block
0x00033000 - invalid/data block
0x00034000 - commit record
        commit time: 2014-12-25 16:53:13.703902604 -0500 EST

これで、別のawkスクリプト（dumpallfor.awk）すべてのブロックをダンプします：

byte address  block      number of journaled blocks
0x8B00020000  145752096  6
0x8B00027000  145752103  10
0x8B0002C000  145752108  206
0x8B00209000  145752585  1
0x8B0029A000  145752730  0

そのため、最後のブロックは本当に失われます:(運が良ければ、debugfsのncheckコマンドでどのファイルがあったかを知ることができます。

だから私はたくさんのブロックを持っています。そして、それらはすべて異なっているように見えます！それで？

失効レコードをできましたですが、その構造を意味のある形で解析できないようです。コミットレコードのタイムスタンプをできましたですが、それを試す前に、各iノードテーブルブロックがどのように異なるかを確認したいと思います。だから私は書いた 別のクイックプログラム （diff.go）それを見つけるために。

ほとんどの場合、異なるファイルはタイムスタンプのみが異なるため、最新のタイムスタンプを持つファイルを選択するだけで済みます。後で行います。他のすべてのファイルについては、次のようになります。

36438023 - size differs
36438139 - OSD1 (file version high dword) differs
36438209 - OSD1 differs

うーん、それは良くありません...サイズの異なるファイルが問題になり、2つのOSD1ファイルをどうすればよいかわかりません。また、debugfsのncheckを使用してファイルが何であるかを確認しようとしましたが、一致するものがありません。

次に、どのブロックダンプが今のところ最新のタイムスタンプを持っているかを見つけました（同じリポジトリ、latest.go）。注意すべき重要な点は、コミット時間ごとにブロックを時系列でスキャンしたことです。 これは必ずしもブロック番号による番号順と同じではありません。ジャーナルは常に時系列で昇順で保存されるとは限りません。

ただし、結局のところ、（コミット時間による）最新のブロックは実際に最新のタイムスタンプを持つブロックです！

これらの最新のブロックを試して、それらから何かを回復できるかどうかを確認してみましょう。

Sudo dd if=BLOCKFILE of=DDRESCUEIMG bs=1 seek=BYTEOFFSET conv=notrunc

その後、私のホームディレクトリが戻ってきました！

それでは、これら3つの異なるファイルが何であったかを調べてみましょう...

Inode   Pathname
36438023    /pietro/.cache/gdm/session.log
36438209    /pietro/.config/liferea
36438139    /pietro/.local/share/zeitgeist/fts.index

そこにある唯一の重要なことはLifereaの構成ディレクトリですが、それが壊れているとは思いません。それは was OSD1の1つでした-異なるもの。

そして、最後のブロックにある16個のiノードについて調べてみましょう。これは回復できませんでした。

Inode   Pathname
36448176    /pietro/k2
36448175    /pietro/Downloads/sOMe4P7.jpg
36448174    /pietro/Downloads/picture.png
36448164    /pietro/Downloads/tumblr_nfjvg292T21s4pk45o1_1280.png
36448169    /pietro/Downloads/METROID Super Zeromission v.2.3+HARD_v2.4.Zip
36448165    /pietro/Downloads/tumblr_mrfex1kuxa1sbx6kgo1_500.jpg
36448173    /pietro/Downloads/1*-vuzP4JAoPf9S6ZdHNR_Jg.jpeg
36448162    /pietro/.cache/upstart/gnome-settings-daemon.log.6.gz
36448163    /pietro/.cache/upstart/dbus.log.7.gz
36448171    /pietro/.cache/upstart/gnome-settings-daemon.log.3.gz
36448161    /pietro/.local/share/applications/Knytt Underground.desktop
36448166    /pietro/Documents/Screenshots/Screenshot from 2014-12-03 15:47:29.png
36448170    /pietro/Documents/Screenshots/Screenshot from 2014-12-03 16:51:26.png
36448172    /pietro/Documents/Screenshots/Screenshot from 2014-12-03 19:08:54.png
36448168    /pietro/Documents/transactions/premiere to operating transaction 4305747926.pdf
36448167    /pietro/Documents/transactions/transaction 4315883542.pdf

要するに：

  • 日付スタンプとチャットログにもあることがわかっているので、ブルートフォースで取り戻すことができるものが1つか2つしかないテキストファイル
  • インターネットからダウンロードしたいくつかの画像。 Firefoxの履歴からURLを取り戻せない場合は、photorecを使用できます
  • a ROMインターネットに簡単にアクセスできるハック= P
  • ログファイル;ここで損失はありません
  • steamゲームの.desktopファイル
  • スクリーンショット; gnome-screenshotが日付スタンプをメタデータとして追加したと仮定すると、これらをphotorecで取り戻すことができます
  • 銀行口座の取引記録;銀行から入手できない場合は、photorecで使用できます。

したがって、犠牲者が出ないわけではありませんが、完全な損失ではありません。その過程で、ext4について詳しく学びました。とにかくありがとう！

[〜＃〜]更新[〜＃〜]

これをそこに出すこともできます：

NOT YET     /pietro/k2
FOUND       /pietro/Downloads/sOMe4P7.jpg
NOT YET     /pietro/Downloads/picture.png
FOUND       /pietro/Downloads/tumblr_nfjvg292T21s4pk45o1_1280.png
GOOGLEIT    /pietro/Downloads/METROID Super Zeromission v.2.3+HARD_v2.4.Zip
FOUND       /pietro/Downloads/tumblr_mrfex1kuxa1sbx6kgo1_500.jpg
FOUND       /pietro/Downloads/1*-vuzP4JAoPf9S6ZdHNR_Jg.jpeg
UNNEEDED    /pietro/.cache/upstart/gnome-settings-daemon.log.6.gz
UNNEEDED    /pietro/.cache/upstart/dbus.log.7.gz
UNNEEDED    /pietro/.cache/upstart/gnome-settings-daemon.log.3.gz
UNNEEDED    /pietro/.local/share/applications/Knytt Underground.desktop
NOT YET     /pietro/Documents/Screenshots/Screenshot from 2014-12-03 15:47:29.png
NOT YET     /pietro/Documents/Screenshots/Screenshot from 2014-12-03 16:51:26.png
NOT YET     /pietro/Documents/Screenshots/Screenshot from 2014-12-03 19:08:54.png
NOT YET     /pietro/Documents/transactions/premiere to operating transaction 4305747926.pdf
NOT YET     /pietro/Documents/transactions/transaction 4315883542.pdf

そして、私が十分に奇妙ではない場合のために、ダウンロードされた写真は次のとおりでした：

これらはすべてチャットで友達によって共有されました。

私はこれを更新し続けると思いますか？ （違いが出るとは限りません...）私はすべてを回復できることを知っています。唯一の問題は、= Pの場合です。

5
andlabs