☰

如何从具有“丢弃块”和重写超级块的 ext4 恢复文件

tag-icon • tag-icon linux partitioning filesystems data-recovery ext4
如何从具有“丢弃块”和重写超级块的 ext4 恢复文件

我使用 parted 调整了 ext4 分区的大小，并在网上发现，要调整大小而不丢失数据，我需要运行mke2fs -S /dev/sdxx -t ext4 ; fsck.ext4 /dev/sdxx -p。我查看了命令及其手册页，似乎没问题，因为它们说它们只会覆盖超级块，而不会触及任何其他内容或丢弃其他块。但是，这是输出：

mke2fs 1.45.5 (07-Jan-2020)
/dev/sda1 contains a ext4 file system
    last mounted on Mon Oct 11 10:56:46 2021
Proceed anyway? (y,N) y
Discarding device blocks: done                            
Creating filesystem with 7145382 4k blocks and 1787040 inodes
Filesystem UUID: 55863129-4a43-4b9c-82eb-4432b623e0d0
Superblock backups stored on blocks: 
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
    4096000

Allocating group tables: done                            
/dev/sda1 may be further corrupted by superblock rewrite
Proceed anyway? (y,N)

这已经非常令人担忧了，因为它说它正在“丢弃块”。然后，我运行了 fsck 命令，其输出包含

fsck from util-linux 2.34
e2fsck 1.45.5 (07-Jan-2020)
Superblock has an invalid journal (inode 8).
Clear<y>? yes
*** journal has been deleted ***

和

Root inode is not a directory.  Clear<y>? yes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Root inode not allocated.  Allocate<y>? yes

此时，我基本知道 FS 已经完蛋了。

非常感谢您的任何建议。最重要的文档是 ODT 文件，因此从技术上讲是 ZIP 存档。我已经尝试编写一个小程序来提取带有 PK[3,4] 标头的所有内容，但由于文件系统的结构，这失败了。

答案1

你发现的调整大小过程似乎很奇怪：盲目地在旧超级块上创建新的超级块是有风险的即使文件系统的其他部分保持不变，但如果文件系统的尺寸发生变化，似乎不太可能真正发挥作用——新的超级块将期望在完全不同的位置找到 inode 和块组；它想“/” inode 可能包含一些距离真实 inode 很远的垃圾数据。

（甚至手册页也指出-S“这是一种极端措施，仅在所有[超级块]都损坏的极不可能的情况下采取”并且“不能保证任何数据都可以挽救”。）

正确的步骤应该是使用该resize2fs程序，该程序已与 mkfs.ext4 和 fsck.ext4 包含在同一个包中超过二十年；它会根据需要调整文件系统结构的大小和重新定位。

但是，此时不要尝试对损坏的文件系统进行 resize2fs 或对其进行任何其他操作 - 而是testdisk在其上运行以抓取它仍能找到的尽可能多的文件。Testdisk 的工作原理与您尝试编写的程序非常相似，只是处理更多格式（而不仅仅是 zip）。

但是，如果你有足够的磁盘空间来制作损坏的文件系统的映像，你可以尝试调整分区大小后退恢复到其原始大小并再次使用 mkfs -S。（在制作备份映像后，在映像上执行此操作！）这实际上可能最终得到一个具有与原始超级块相同参数的超级块，并且如果原始数据结构尚未损坏，则有望指向原始数据结构。

相关内容