那些遇到过的问题

我可以找出给定的 ext4 块是否在 inode 表中，如果是，我可以手动从没有标题的日志中挑选出来吗？

and*_*abs 6 ext4 data-recovery journaling ddrescue

因此，在从旧笔记本电脑到新笔记本电脑的途中，旧笔记本电脑的硬盘受到了一些物理损坏。badblocks报告 64 个坏道。我有一个两个月大的 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  +
Run Code Online (Sandbox Code Playgroud)

我使用 debugfsicheck和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
Run Code Online (Sandbox Code Playgroud)

所以我的问题是：

  1. 如果不是 inode 条目，我能准确找出这五个未知块是什么吗？我怀疑它们是 inode 表条目，但icheck不想说。如果是，我可以找出哪些 inode 吗？
  2. 即使日志的前 10 个块丢失，我仍然可以手动从日志中恢复这些 inode 表条目吗？

我宁愿不使用 进行此数据恢复fsck，它只会将我所有的文件转储/lost+found到一大堆扁平目录结构和重复文件中...

谢谢。

and*_*abs 5

好的，所以对于第一个问题，结果是debugfs stats命令告诉了组中每个部分的起始块是什么。另外，我猜测innumbers必须是连续的和递增的，所以在inode表和imap命令中基本添加偏移量给了我第一个innumbers；它还证实了我对最后一个坏扇区的怀疑，我的块组计算表明它在错误的组中。

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
Run Code Online (Sandbox Code Playgroud)

由于块是 4096 字节，每个 inode 表条目是 256 字节，因此每个块有 16 个 inode。所以我现在有所有 80 个丢失的 inode 表条目。

现在让我们转向期刊。我写了一个小工具，可以在日志的每个块中转储信息。由于缺少日志超级块，因此丢失了我需要的两条信息：

  • 日志是否持有 64 位区块号
  • 期刊是否使用版本 3 校验和

幸运的是，如果我强制打开其中一个（或两个）开关，日志中的一些描述符块会溢出其块，证明这些标志未设置。

一个 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
Run Code Online (Sandbox Code Playgroud)

有了这个，另一个 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
Run Code Online (Sandbox Code Playgroud)

所以最后一个块真的丢失了:(运气好的话，我可以用debugfs'sncheck命令找出那里有哪些文件。

所以我有一堆积木。他们似乎都不同！怎么办？

我可以通过撤销记录，但我似乎无法有意义地解析该结构。我可以查看提交记录时间戳，但在尝试之前，我想看看每个 inode 表块有何不同。所以我写了另一个快速程序( diff.go) 来找出答案。

在大多数情况下，确实不同的文件仅在时间戳上有所不同，因此我们可以选择具有最新时间戳的文件。我们稍后再做。对于所有其他文件，我们得到：

36438023 - size differs
36438139 - OSD1 (file version high dword) differs
36438209 - OSD1 differs
Run Code Online (Sandbox Code Playgroud)

嗯，那不好...不同大小的文件将是一个问题，我不知道如何处理两个OSD1文件。我也尝试使用debugfs'sncheck来查看文件是什么，但我们没有匹配项。

然后我发现了哪些块转储现在具有最新的时间戳（相同的 repo，latest.go）。需要注意的重要一点是，我按提交时间按时间顺序扫描了块。这不一定与按块编号的数字顺序相同；日志并不总是按时间递增的顺序存储。

然而，事实证明，最新的块（按提交时间）确实是具有最新时间戳的块！

让我们尝试这些最新的块，看看我们是否可以从中恢复任何东西。

sudo dd if=BLOCKFILE of=DDRESCUEIMG bs=1 seek=BYTEOFFSET conv=notrunc
Run Code Online (Sandbox Code Playgroud)

之后我的主目录又回来了！

现在让我们找出这三个不同的文件是什么......

Inode   Pathname
36438023    /pietro/.cache/gdm/session.log
36438209    /pietro/.config/liferea
36438139    /pietro/.local/share/zeitgeist/fts.index
Run Code Online (Sandbox Code Playgroud)

唯一重要的是 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
Run Code Online (Sandbox Code Playgroud)

简而言之：

  • 一个只有一两件事的文本文件，因为我知道它有一个日期戳和一些也在我的聊天记录中的东西，所以我可以用蛮力取回
  • 从网上下载的一些图片；如果我无法从 Firefox 的历史记录中取回 URL，那么我可以使用 photorec
  • 一个 ROM hack，我可以很容易地再次上网 =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
Run Code Online (Sandbox Code Playgroud)

如果我不够奇怪，下载的图片是：

这些都是朋友在聊天中分享的。

我想我会保持更新吗？（不像它会有所作为...）我知道我可以恢复一切；唯一的问题是什么时候 =P

归档时间：

查看次数：

3332 次

最近记录：

8 年，8 月 前
相关归档
为什么“ls”在以前很大的小目录中需要很长时间？如何解决这个问题？ 43
用于损坏驱动器（IO 错误）的高级 NTFS 分区文件恢复技术？ 8
tune2fs - 在大型 ext4 文件系统上保留多少空间 8
如何配置文件系统+LVM以有效使用SSD？ 6
如何在linux ext-4上使用“文件无读取权限”使恶意软件文件可读？ 6
VMware：为什么需要零填充 ext4 可用空间来缩小 *.vmdk 文件？ 6
从损坏的 DVD 中恢复文件 5
从损坏的 (NTFS) 分区恢复数据 5
从本地文件服务器取消删除文件 4
une2fs：尝试打开 /dev/sda1 时超级块中的错误幻数 1
难疑归档
如何在 unix 命令行上压缩/解压缩？ 634
分段错误如何在后台工作？ 272
为什么*不*解析`ls`（以及该怎么做）？ 249
如何设置用户环境变量？（永久，不是会话） 161
如何在 Unix/linux 中查看特定用户创建的进程 138
有没有办法在单个命令中获取数字列表的最小值、最大值、中值和平均值？ 123
如何将命令的输出分配给 shell 变量？ 95
如何避免 ssh 请求许可？ 85
如何判断一个包是否通过 yum 安装在 bash 脚本中？ 84
如何在 GNU Screen 中垂直拆分窗口？ 83