问题
我的基于 Armbian 的 Orange Pi 网络服务器崩溃了（可能是因为断电）。我认为这会很好，因为 ext4 更具弹性，而且过去通常都是这样，但由于某种原因，这一次，它没有重新启动，而是挂起了。当我检查时，似乎是“驱动器”（实际上是存储卡）“没有有效的文件系统”。
我取出该卡并制作了一个备份映像（卡上 32GB 空间的容量约为 4.5GB），并在十六进制编辑器和各种程序中对其进行了检查。我还将 Armbian ISO 刻录到相同的存储卡上以比较元数据值。
我确实在不同的（不相同的卡）上有几年前的系统副本，但从那时起服务器已经发生了相当大的变化。希望它至少可以提供更多信息进行比较。
观察结果
我注意到几个问题：
大多数程序无法检测到该卡包含文件系统。不，，，
fsck等等testdisk不起作用，他们抱怨bad magic number，或者wrong fs type, bad option, bad superblock, or missing codepage，或者filesystem seems damaged，或者bad relative sector，或者其他阻塞错误。超级块已损坏（并且我找不到备份）；看起来大多数条目都没有问题，但以下条目肯定有不寻常/无效的值。我将损坏的系统的值与新系统的值进行了比较，忽略了分区大小或安装计数等自然会有所不同的值。带问号的预期值是我不确定是否特定于驱动器的值，也就是说，我不知道它们是否不正确。
| 场地 | 实际价值 | 期望值 |
|---|---|---|
| 每组块数 | 0 | 32768 |
| 每组片段 | 0 | 32768 |
| 每组索引节点数 | 5680 | ？ 8160 |
| 最大安装数 | 0x7777 | 0xffff |
| 魔术签名 | 0x6753 | 0xef53 |
| 文件系统状态 |
答案1
ext2/3/4 文件系统只是同一文件系统的不同变体，添加了更新的功能，因此磁盘结构上的很多内容都是相同的。这就是为什么文件系统的所有三个变体都只有一个神奇值。 ext3 中主要的新功能是has_journal，而 ext4extents则添加了一些其他功能。
您可以考虑下载并构建 e2fsprogs 源代码（在不同的系统/卡上）以获得该程序的副本findsuper。无论分区表是否损坏，它都会对设备进行扇区扫描，查找超级块中的 ext2/3/4 magic 值。这将识别每个文件系统所在分区的起始偏移量（以字节为单位），这可以帮助您重建/恢复分区。
答案2
正如所讨论的 ext/ext2/3/4 非常相似，源自超高速文件系统/FFS（也可以看看1和2）它们按照索引节点、块和指针（间接块等）以相同的方式对数据进行排序，这些对于 FFS（Unix 的第一个文件系统）来说都是常见的。 Linux 是 unix 的衍生版本，ext 是带有一些附加功能的 FFS。 linux 文件系统 API 内置于内核中，兼容所有版本的 ext
就重新创建索引节点表而言，文件系统的核心是指向包含每个文件数据的块的指针列表。如果没有此列表，则只能猜测与每个文件对应的块。 Ext4 尤其擅长分配连续的块（它包含“多块分配”或 mballoc 功能）所以这个猜测可能没问题。但对于可能存在碎片的大文件，任务变得很困难，据我所知，没有已知的工具可以从碎片块重建文件。我要重申的是，ext2 擅长分配连续的块（给定文件的块几乎总是靠近在一起）。您可以在这里阅读有关 ext2/3/4 的低级结构。在出现碎片的情况下，您必须自己手动定位块，这对于大文件来说将非常困难。较大的文件更有可能出现碎片。
元数据（对应于每个文件的索引节点）与数据本身一样重要，如果没有元数据，您的数据将不再被视为存在 - 即使它仍然以不变的方式存在于磁盘上 - 严格来说，无法重建数据块按顺序排列，因此如果没有 inode 表，大的碎片文件就等于丢失
唯一的选择是使用数据雕刻工具（例如 PhotoRec 或最重要的）以及您自己对数据组成的启发式工具，这可能有助于重建您的文件。
考虑到元数据的重要性以及它很容易被损坏，您可以考虑定期安排e2image，仅允许备份元数据 - 这是完整备份大小的一小部分。当然，如果文件系统在备份后发生变化，元数据将变得无关紧要