そのため、既存のノートブックを新しいノートブックに置き換える過程で、既存のノートブックのハードドライブが物理的に破損しています。badblocks64個の不良セクタを報告します。パーティション/とパーティションを含む2ヶ月のUbuntu GNOME設定があります/home。私が知る限り、その中のセクターのいくつかが/破損していますが、これは問題ではありません。一方、/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
だから私の質問は次のようになります
- inodeエントリではない場合、この5つの未知のブロックが何であるかを正確に知ることができますか？私はそれがinodeテーブルエントリだと思いますが、
icheck言いたくありません。それでは、どのインデックスノードがあるかを調べることができますか？ - ログの最初の10ブロックが失われても、ログからこれらのinodeテーブルエントリを手動で回復できますか？
私はすべてのファイルを単純なディレクトリ構造と重複ファイルfsckに捨てるデータ回復を実行したくありません。/lost+found
ありがとうございます。
ベストアンサー1
最初の質問の場合、コマンドはdebugfs statsグループの各部分の開始ブロックが何であるかを示します。さらに、私はinnumberが連続的で増加しなければならないと推測したので、オフセットは基本的にinodeテーブルに追加され、コマンドは私imapに最初のinnumberを提供しました。間違ったグループに属しているということです。
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バイトで、各inodeテーブルエントリは256バイトなので、ブロックあたり16個のinodeがあります。これで、80個の欠落しているinodeテーブルエントリがすべて数字で一覧表示されています。
それでは、日記の書き込みに戻りましょう。私は書いたガジェットログの各ブロックに情報をダンプします。ログスーパーブロックがないため、必要な2つの情報がありません。
- ログに64ビットブロック番号を格納するかどうか
- ジャーナルがバージョン 3 チェックサムを使用するかどうか
幸い、スイッチの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
debugfsncheckしたがって、最後のブロックは実際に欠落しています。運が良ければ。
だから私はたくさんのブロックを持っています。そして彼らはすべて異なって見えます！何をすべきか？
私できるレコードを元に戻して構造を意味的に解析できないようです。私できるコミットレコードのタイムスタンプに従ってください。しかし、試す前に各inodeテーブルブロックがどのように異なるかを確認したかったのです。だから私が書いた別のクイックプログラム（diff.go）調べてみます。
ほとんどの場合、ファイルごとにタイムスタンプだけが異なるため、最新のタイムスタンプを持つファイルを選択できます。この作業は後で行います。他のすべてのファイルの場合は、次のようになります。
36438023 - size differs
36438139 - OSD1 (file version high dword) differs
36438209 - OSD1 differs
まあ、それは良いことではありません...異なるサイズのファイルは問題になる可能性があり、2つのOSD1ファイルをどのようにすべきかわかりません。また、debugfs'sを使用してファイルが何であるかを確認しようとしましたが、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の設定ディレクトリです。しかし、破損しているようではありません。以前はOSD1は別のものです。
回復不能な最後のブロックで16個のinodeを探してみましょう。
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を使用できます。
- インターネットサーフィンを簡単にやり直すことができる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
私が十分に奇妙でない場合、ダウンロードした画像は次のようになります。
sOMe4P7.jpg（「Law & Order」タイトルカードパロディ「ナックルズと一緒に」そこに追加）tumblr_nfjvg292T21s4pk45o1_1280.png（スクリーンショットJKローリングさんのツイート)tumblr_mrfex1kuxa1sbx6kgo1_500.jpg（スポーツイベントとして表示される看板に「Windowsが正常に終了しませんでした」というエラーメッセージが表示された画像）1*-vuzP4JAoPf9S6ZdHNR_Jg.jpeg（この漫画)
チャットで友達が共有した内容です。
ずっと更新したいと思いますか？ （だからといって変わるわけではありません…）すべてを復元できることを知っています。唯一の質問は= Pの時です。