主驱动器上的 dd 命令错误 - 如何恢复数据？

Question 1

我假设分区表和启动分区可以轻松地重新创建，所以我将重点关注 ext4 分区。

文件系统的布局在某种程度上取决于创建时使用的选项。我将描述常见情况。您可以通过dumpe2fs在设备上运行来查看这是否与您的情况相匹配（希望在缓存中找到所有顶级元数据，而不是从磁盘读取）。

ext4 文件系统的正常块大小为 4096 字节，因此您丢失了 1024 个块。

首先被覆盖的是块 0，即主超级块。这本身不是问题，因为还有备份超级块。之后是组描述符表，它在文件系统中也有备份。

然后是块位图和 inode 位图。这是消息开始变得稍微糟糕的地方。如果其中任何一个低于块 1024（很可能是这样），您就丢失了有关正在使用哪些 inode 和块的信息。这些信息是多余的，如果所有目录和 inode 都完好无损，fsck 将根据遍历所有目录和 inode 时发现的内容重建这些信息。

但接下来是 inode 表，在这里你可能丢失了很多 inode，包括根目录、日志和其他特殊 inode。如果能找回这些就好了。显然，至少根目录仍然可用，否则你尝试运行的所有命令都会失败。

如果您现在运行dd if=/dev/nvme1n1p2 of=/some/external/device bs=4096 count=1024，您将获得当前缓存中所有内容的备份副本，其中混合了未缓存块的坏数据。然后，在启动救援磁盘后，您可以dd反向执行相同操作，将部分好的数据放回磁盘上，覆盖现在所有坏的数据。

在此之后，您可能会发现自动恢复工具（fsck、testdisk）工作得很好。如果不是，您可以使用一张地图来帮助手动恢复。使用中的“空闲块”列表dumpe2fs，您知道要忽略哪些块。

你丢失的大部分内容可能是 inode。实际上，你很可能没有文件内容在磁盘的前 4MB 中。（我mkfs.ext4在 1TB 图像文件上运行了无任何选项，第一个非元数据块竟然是块 9249）

您设法恢复的每个 inode 都将标识整个文件的数据块。这些数据块可能位于磁盘的各处，而不一定位于附近。

第 2 天

pastebin 上发布的转储揭示了好消息：

Group 0: (Blocks 0-32767) csum 0x9569 [ITABLE_ZEROED]
  Primary superblock at 0, Group descriptors at 1-117
  Reserved GDT blocks at 118-1141
  Block bitmap at 1142 (+1142)
  Inode bitmap at 1158 (+1158)
  Inode table at 1174-1685 (+1174)
  21349 free blocks, 8177 free inodes, 2 directories, 8177 unused inodes
  Free blocks: 11419-32767
  Free inodes: 16-8192

由于我们认为文件系统开头的 4MB 被覆盖了，所以我们只需要担心 0-1023 块。而保留的 GDT 块一直延伸到 1141 块！这种损坏应该可以通过简单的方法e2fsck -b $backup_superblock_number（重启后）进行修复。您至少可以尝试一下，-n看看它是怎么想的。

Answer

我假设分区表和启动分区可以轻松地重新创建，所以我将重点关注 ext4 分区。

文件系统的布局在某种程度上取决于创建时使用的选项。我将描述常见情况。您可以通过dumpe2fs在设备上运行来查看这是否与您的情况相匹配（希望在缓存中找到所有顶级元数据，而不是从磁盘读取）。

ext4 文件系统的正常块大小为 4096 字节，因此您丢失了 1024 个块。

首先被覆盖的是块 0，即主超级块。这本身不是问题，因为还有备份超级块。之后是组描述符表，它在文件系统中也有备份。

然后是块位图和 inode 位图。这是消息开始变得稍微糟糕的地方。如果其中任何一个低于块 1024（很可能是这样），您就丢失了有关正在使用哪些 inode 和块的信息。这些信息是多余的，如果所有目录和 inode 都完好无损，fsck 将根据遍历所有目录和 inode 时发现的内容重建这些信息。

但接下来是 inode 表，在这里你可能丢失了很多 inode，包括根目录、日志和其他特殊 inode。如果能找回这些就好了。显然，至少根目录仍然可用，否则你尝试运行的所有命令都会失败。

如果您现在运行dd if=/dev/nvme1n1p2 of=/some/external/device bs=4096 count=1024，您将获得当前缓存中所有内容的备份副本，其中混合了未缓存块的坏数据。然后，在启动救援磁盘后，您可以dd反向执行相同操作，将部分好的数据放回磁盘上，覆盖现在所有坏的数据。

在此之后，您可能会发现自动恢复工具（fsck、testdisk）工作得很好。如果不是，您可以使用一张地图来帮助手动恢复。使用中的“空闲块”列表dumpe2fs，您知道要忽略哪些块。

你丢失的大部分内容可能是 inode。实际上，你很可能没有文件内容在磁盘的前 4MB 中。（我mkfs.ext4在 1TB 图像文件上运行了无任何选项，第一个非元数据块竟然是块 9249）

您设法恢复的每个 inode 都将标识整个文件的数据块。这些数据块可能位于磁盘的各处，而不一定位于附近。

第 2 天

pastebin 上发布的转储揭示了好消息：

Group 0: (Blocks 0-32767) csum 0x9569 [ITABLE_ZEROED]
  Primary superblock at 0, Group descriptors at 1-117
  Reserved GDT blocks at 118-1141
  Block bitmap at 1142 (+1142)
  Inode bitmap at 1158 (+1158)
  Inode table at 1174-1685 (+1174)
  21349 free blocks, 8177 free inodes, 2 directories, 8177 unused inodes
  Free blocks: 11419-32767
  Free inodes: 16-8192

由于我们认为文件系统开头的 4MB 被覆盖了，所以我们只需要担心 0-1023 块。而保留的 GDT 块一直延伸到 1141 块！这种损坏应该可以通过简单的方法e2fsck -b $backup_superblock_number（重启后）进行修复。您至少可以尝试一下，-n看看它是怎么想的。

Question 2

如果磁盘使用 GPT，则可以使用磁盘末尾的备份 GPT 数据恢复分区表。您可以使用执行此操作gdisk；请参阅gdisk数据恢复文档了解详情。简而言之：当您gdisk在磁盘上启动时，它将大概注意到损坏并询问您是否要使用备份 GPT 数据或 MBR 数据。如果您选择 GPT 选项然后写入更改，分区表将被修复。如果gdisk没有询问要使用哪个分区表，您可能仍然可以使用恢复和转换菜单上的选项加载备份表c。

/sys/block/nvme1n1/nvme1n1p1/start如果失败，您仍然可以使用和/sys/block/nvme1n1/nvme1n1p1/size文件中的数据（以及中的数据）重新创建分区表（或至少是分区的起点和终点）/dev/nvme1n1p2。但是，如果您求助于这些数据，则必须不是关闭计算机，这与 hek2mgl 的建议相反。话虽如此，hek2mgl 认为继续使用当前状态的磁盘可能会使情况变得更糟，这一点并没有错。总的来说，我认为最好的折衷方案是尽快修复分区表问题，然后关闭计算机并从紧急磁盘修复文件系统问题。

不幸的是，您的 ESP 已损坏。考虑到您的磁盘布局，我猜您将 ESP 安装在了/boot并将内核存储在那里。因此，您需要使用chroot或其他方式重新安装内核包。您的引导加载程序或引导管理器也是如此。

Answer

如果磁盘使用 GPT，则可以使用磁盘末尾的备份 GPT 数据恢复分区表。您可以使用执行此操作gdisk；请参阅gdisk数据恢复文档了解详情。简而言之：当您gdisk在磁盘上启动时，它将大概注意到损坏并询问您是否要使用备份 GPT 数据或 MBR 数据。如果您选择 GPT 选项然后写入更改，分区表将被修复。如果gdisk没有询问要使用哪个分区表，您可能仍然可以使用恢复和转换菜单上的选项加载备份表c。

/sys/block/nvme1n1/nvme1n1p1/start如果失败，您仍然可以使用和/sys/block/nvme1n1/nvme1n1p1/size文件中的数据（以及中的数据）重新创建分区表（或至少是分区的起点和终点）/dev/nvme1n1p2。但是，如果您求助于这些数据，则必须不是关闭计算机，这与 hek2mgl 的建议相反。话虽如此，hek2mgl 认为继续使用当前状态的磁盘可能会使情况变得更糟，这一点并没有错。总的来说，我认为最好的折衷方案是尽快修复分区表问题，然后关闭计算机并从紧急磁盘修复文件系统问题。

不幸的是，您的 ESP 已损坏。考虑到您的磁盘布局，我猜您将 ESP 安装在了/boot并将内核存储在那里。因此，您需要使用chroot或其他方式重新安装内核包。您的引导加载程序或引导管理器也是如此。

Question 3

立即关闭计算机
使用救援系统启动它。
运行testdisk以尝试恢复您的数据。（如果您有足够的空间，请使用该设备获取图像并在该图像上dd运行）testdisk

为什么要立即关闭计算机？如果要创建新文件（可能在 /run 中）或将新文件附加到（/var/log/...），则文件系统需要查看现有（错误！）信息以决定将数据存储在何处。当根据错误信息做出此决定时，现有数据块被覆盖的风险很高。这会使它们永远丢失。即使对于像testdisk和这样的工具也是如此photorec。

Answer

立即关闭计算机
使用救援系统启动它。
运行testdisk以尝试恢复您的数据。（如果您有足够的空间，请使用该设备获取图像并在该图像上dd运行）testdisk

为什么要立即关闭计算机？如果要创建新文件（可能在 /run 中）或将新文件附加到（/var/log/...），则文件系统需要查看现有（错误！）信息以决定将数据存储在何处。当根据错误信息做出此决定时，现有数据块被覆盖的风险很高。这会使它们永远丢失。即使对于像testdisk和这样的工具也是如此photorec。

主驱动器上的 dd 命令错误 - 如何恢复数据？

答案1

第 2 天

答案2

答案3

相关内容