☰

GPT 表恢复

tag-icon • tag-icon partitioning gpt hard-drive-recovery partition-recovery
GPT 表恢复

我已经把自己归入了不能阅读和破坏自己的东西的用户行列。

上周日，当我尝试将较大的 Windows 7 NTFS 分区复制到较小的分区时，我破坏了 3TB HDD 上的分区表。背景信息如下：

sdb (3TB drive/partition)
sdh2 (1.57 TB partition)(2TB drive)

我正在运行 PartedMagic 2018（现在仍在运行），然后输入了以下内容：

sgdisk -R /dev/sdb /dev/sdh2

当我打开 Gparted 时，我意识到我输入了错误的命令。它被列在 SE 问题中，作为解决将较大分区移动到较小分区的问题的答案。回答输入如下：

sgdisk -R /dev/sdY /dev/sdX
where:
sdX = Disk A
sdY = Disk B

笨蛋滚开，我现在要控制损失。我已经开始关注这个Ubuntu 论坛指南并且目前已开始扫描驱动器以查找分区头，以便我可以恢复整个驱动器。

到目前为止，我已经输入了以下命令：gpart /dev/sdb。它已经扫描驱动器大约 4 天 20 小时。

我对我的程序有几个问题：

  1. 这需要多长时间？我最好的估计是查看硬盘活动指示灯并计算每秒最多闪烁一次。我假设一次闪烁表示读取一个扇区，每个扇区为 4096（它在闪存驱动器上）。3TB 驱动器上的 2,720,000 MB 以每秒 4 MB 的读取速度给我大约 7.87 天。最短的时间将是该速度的两倍，现在应该已经完成​​了。最后一个“可能的分区”输出是两天前，给出的偏移量为 1421742mb，而第一个可能的偏移量为 1mb。我确实在某处看到过扇区大小可能更小。我接近了吗？

  2. 我是否采取了适当的措施来挽救我的驱动器？Ubuntu 论坛指南似乎很合理，而且非常具有可比性。我的驱动器上只有一个分区，以前还有更多分区，但我已将其擦除，然后从这一个分区重新开始。据我回忆，这是事故发生前列出的唯一分区，使用了整个驱动器。我不确定上面是否有那些几 MB 未使用的部分（这个奇怪的空白未分区点有时会在 GParted 中创建分区时出现，它会以 1mib 未使用开头。）

  3. 如果我使用 恢复分区parted，但没有添加所有扇区，或者添加了太多扇区，数据是否仍会显示在分区上？指南说使用扇区单位来重建分区表。如果我使用的单位太少或太多，安装驱动器并读取数据时是否仍会显示数据？

  4. 我读到有一个主分区表和次分区表或类似的东西，这些存在吗，我可以复制它们吗，我如何查看它们以确认我想要恢复哪一个？

除了送去专业服务机构之外，我还需要第二个损害控制选项。这不是商用电脑，但有一些重要的东西需要恢复。

最终目标：恢复 3TB 驱动器上的单个分区。

更新：发布 gpart 扫描

如参考图片所示，扫描在驱动器末端附近失败。此后，我将驱动器放在了较新的计算机中，并在其中运行了TestDisk。快速扫描发现了一些gpart我看到的内容，但不是我知道的内容。我使用了“深度扫描”选项，几分钟内它就找到了有问题的分区，名为Big Mongo。这是我在 Windows 中为驱动器命名的。

更新 2：TestDisk 扫描后

TestDisk 已完成（参见其他参考图片）并确定了我丢失的分区。我能够让它在程序中列出文件。请注意已完成扫描底部的大小。扫描在 10 小时内完成，而之前则需要 8 天gpart。

结论：对于有探究精神的人来说

运行 TestDisk 后，它找到了分区，但创建了错误的表，因此我运行gdisk并重建了它，使用2048起始大小和最大大小作为结束大小（参见标记的答案）。将其置于休眠状态，启动时没有问题。

参考图
gdisk -l 查看注释https://i.stack.imgur.com/9znYj.jpg
gpart 扫描 1/2https://i.stack.imgur.com/rWxuC.jpg
gpart 扫描 2/2https://i.stack.imgur.com/HQYJ8.jpg

TestDisk 快速扫描

在此处输入图片描述

TestDisk 深度扫描初步

在此处输入图片描述

TestDisk 完成

在此处输入图片描述

答案1

分析

您使用的命令

sgdisk -R /dev/sdb /dev/sdh2

将 GUID 分区表（GPT）从 复制/dev/sdh2到/dev/sdb。

一个问题是/dev/sdh2分区。任何分区都没有有意义的分区表。或者至少不应该有一个。我可以想象分区内有一个有意义的分区表（甚至可以让它工作），但这很麻烦、很奇怪，并不是很有用。

生成的副本是一个空的 GPT，因为显然里面的相关（但无意义）值/dev/sdh2导致了这样的表格。这并不重要。

重要的是，您覆盖了 上的原始 GPT /dev/sdb。您使用的命令仅修改了分区表，其他所有结构应仍然存在。文件系统本身应该没问题（除非您稍后尝试恢复时不幸损坏了它）。您只是失去了一种方便的方法来访问文件系统。请阅读我的这个答案，其开头部分总结了分区和文件系统的区别。

您现在的目标是以某种方式恢复原始 GPT。请注意，您的情况就像您正处于上述答案中描述的过程的中间：您已经销毁了分区表条目，但尚未创建新的条目。不同之处在于您不一定想创建更大的分区，并且您不知道分区应该从哪个偏移量（起始扇区）开始。

GPT 由主表和辅助（备份）表组成。辅助表无法帮助您恢复旧状态，因为sgdisk -R修改了两个表以使整个 GPT 保持一致状态。

查找偏移量

有一些工具可以扫描磁盘、查找文件系统签名、从签名中读取文件系统大小并提出分区表条目，该条目将正确将文件系统嵌入到新定义的分区中，以便轻松挂载。 其中一个这样的工具是testdisk。 如果只是旧的分区表被清除，testdisk应该能够找到文件系统并创建合理的 GPT。 扫描可能需要一段时间。

或者，您可以尝试猜测正确的偏移量。事实上，您只有一个分区，这是一个优势。

请阅读这是我的另一个答案。就您的情况而言（逻辑扇区大小为512），最可能的起始扇区是2048，可能起作用的命令是：

mount -o ro,offset=$((512*2048)) /dev/sdb /some/mountpoint/

以只读方式挂载不会影响迄今为止幸存的数据，因此尝试应该是安全的。如果命令成功并且您验证文件和目录出现在 下/some/mountpoint/，则表示偏移量是正确的。

注意512*2048正好是 1 MiB。在其中一个屏幕截图中，您有：

Possible partition … offset(1mb)

我认为就是这个。testdisk如果你使用这个工具，你也很有可能找到它。

手动创建分区表条目

如果您选择不使用testdisk（或类似），发现偏移量似乎正确，那么您可以手动创建具有合理条目的分区表（使用gdisk，sgdisk或任何能够执行此操作的工具）。请遵循以下提示：

  • 如果文件系统已安装（例如mount -o ro,offset=… …来自上一段），umount它。
  • 保留 GPT。如果逻辑扇区大小正确，则不太可能您最初在 MBR 中有 DOS 分区表。即使有，从扇区开始的分区也不可能2048到达磁盘的末尾。因此，即使最初没有，也可以安全地在磁盘的末尾创建一个辅助 GPT（此外，sgdisk -R无论如何已经写了一个，您不能让情况变得更糟）。但请参阅本答案后面的“可能的问题”部分，以防万一。
  • 起始扇区应该是2048因为这是您找到的偏移量。
  • 大小应等于或大于文件系统的大小。目前你唯一的提示是size(764432mb)，我不确定mb这是否意味着MB 或 MiB，或者如果它不是完全错误的。最安全的方法是（暂时）使用您可以获得的最大值作为结束扇区。通过另一张屏幕截图，我相信结束扇区的最大值是5860533134。
  • [分区类型 GUID] 应该是适合 NTFS：EBD0A0A2-B9E5-4433-87C0-68B6B72699C7。请注意，gdisk您可以使用的短代码0700来实现这一点。
  • 该工具不得触及文件系统，它只能影响分区表。如果它试图格式化（mkfs）“新”分区或擦除它（wipefs），则它不是正确的工具。我相信gdisk是安全的。我会非常小心地使用 GUI 一体化分区工具（包括 Windows 原生工具）。坦率地说，在这种情况下，“非常小心”意味着我根本不会使用它们。

创建正确的条目并将新分区表写入设备后，/dev/sdb1应该会出现。如果没有出现，请调用partprobe。

确认您能够安装/dev/sdb1。

调整尺寸

现在，只要有/dev/sdb1可用文件，您就可以轻松地查询文件系统的大小。我的意思是文件系统知道它的大小。一般来说，这与相应分区的大小不同。您至少可以使用两种工具：

  • file -s /dev/sdb1

    你感兴趣的是它说的地方sectors NNNNNN。不用担心hidden sectors（比较对 FAT 也有类似疑问）。

  • ntfsresize --info /dev/sdb1

    您对“当前卷大小”感兴趣。以 512 字节扇区表示（即除以 512）。

从输出计算出的数字ntfsresize可能与显示的数字略有不同file。我认为这与簇大小有关。在我的测试中，似乎在mkfs.ntfs要求使用整个分区后，file报告少一个部门比分区中的扇区数多。因此使用 而不是file，ntfsresize识别sectors NNNNNN，加一。这就是分区所需的大小。如有疑问，请添加2048扇区。这有点过分，但浪费的空间只有 1 MiB，不是很多；它肯定会保证您的安全。

如果分区（在上一段中创建）较大，您可能需要缩小它。我注意到您的最终目标是将文件系统复制到较小的磁盘；Possible partition … size(764432mb) …其中一个屏幕截图中就有这个。这让我相信文件系统确实比新分区小。这本身不是问题，但如果您想在文件系统结束后创建另一个分区，或者如果您仍想将设置复制到较小的磁盘，缩小分区是一个好主意。

步骤：

  1. umount文件系统（若已安装）。
  2. 从分区表中删除该条目。
  3. 像上一段一样创建一个新条目，但这次指定刚刚计算的扇区数。请注意，我们讨论的是新分区的大小，而不是结束扇区。如果您需要知道结束扇区，请使用以下公式：start+size-1=end。任何分区的末尾对齐都无关紧要（开头很重要），但如果工具坚持将末尾稍微移向磁盘末尾，请让它移动。
  4. 保存分区表，partprobe以防万一运行。
  5. 验证/dev/sdb1挂载是否无错误。首先以只读方式挂载（mount -o ro …）以防万一。

如果文件系统挂载正常，那么基本上就大功告成了。分区表现在很正常。

可能出现的问题

  • 新分区将具有新的唯一分区 GUID。另一方面存储在文件系统中的“UUID”仍然存在。您可能需要重新配置任何依赖前者的工具/操作系统（或从某些配置中检索旧值并将其应用于新分区，这一举动将使所有此类配置再次有效）。我不知道 Windows 使用哪个 ID 来判断它是否之前见过该分区/文件系统。
  • 我可以看到磁盘报告的逻辑/物理扇区大小为512/4096。请阅读这个问题以及我对此的回答中的解释。如果至少有一个 USB 外壳参与其中，并且磁盘的连接方式与现在不同（即在不同的外壳中；或者现在通过 SATA，以前在外壳中；反之亦然），并且您/dev/sdb1在调用之前尚未验证是否已安装sgdisk -R，那么或许原始（丢失）分区表对逻辑大小有效4096；如果您在事故发生前尝试安装分区，那么您将遇到与链接问题中相同的问题。我的观点是我的答案可以帮助您创建对有效的分区表当前的设置。如果您遇到了这个问题，那么当您在原始设置中连接驱动器时，它就会出现。然后您需要再次调整分区表。我对链接问题的回答会有所帮助。

  • 如果上述内容适用且size(764432mb)错误，则可能是您在 MBR（而非 GPT）中有一个 DOS 分区表（并对其进行了覆盖），该分区表定义了一个大分区，该分区跨越到磁盘的最末端，并且文件系统本身跨越到（几乎）磁盘的最末端。在这种情况下，sgdisk -R在文件系统的一部分应该所在的末端创建了辅助（备份）GPT。如果文件系统安装正常，则可能并非如此。一般来说可能是这样。在这种情况下，您实际上可能已经丢失了数据；除非您修复它，否则您可能会丢失更多数据（如果需要，请单独提问）。

    请注意，如果您确定您有 GPT，那么您是安全的（因为辅助表“始终”在那里）。如果您确定上一条不适用，那么您是安全的（因为逻辑扇区大小为，512并且 MBR 中的 DOS 分区表从扇区开始的分区2048 无法跨越到大磁盘的末尾）。

修复分区表后，您可能希望继续执行原始计划。然后：

  • 另一个磁盘可能具有不同的逻辑扇区大小。我不确定（正确使用）是否sgdisk -R会重新计算不同大小之间的条目。我希望它会。如果没有，你知道该做什么。
  • 但或许您希望将 的唯一分区/dev/sdb（即/dev/sdb1左右）克隆到/dev/sdh2；并且 是/dev/sdh1您想要保留的。如果是，sgdisk -R是不是您要执行的操作。将分区表从 复制/dev/sdb到/dev/sdh2（即分区）不会给您带来任何结果。将其复制到/dev/sdh将替换那里的当前分区表并扰乱当前分区表/dev/sdh2（/dev/sdh1如果有的话）。sgdisk -R仅当目标磁盘不包含要保留的数据时才使用。如有任何疑问，请在修复 的分区表后提出单独的问题。新问题应包含两个磁盘的（或）/dev/sdb的输出，并且您应该清楚地说明要将哪个分区克隆到哪里，哪些分区是可消耗的，哪些分区应该保持不变。gdisk -lfdisk -l

相关内容