主页 / computer / 问题 / 1508109
Accepted
ConductedForce
Asked: 2019-12-07 15:08:14 +0800 CST

GPT 表恢复

  • 772

我已经将自己引入了无法阅读和破坏自己的东西的用户行列。

上周日，在尝试将较大的 Windows 7 NTFS 分区复制到较小的分区时，我炸毁了我认为是 3TB 硬盘上的分区表。对于上下文：

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

Bonehead 移到一边，我现在处于损害控制之中。我已开始关注此Ubuntu 论坛指南，目前已开始扫描驱动器以查找分区标题，以便恢复整个驱动器。

I've entered the following command so far: gpart /dev/sdb. It has been scanning the drive for about 4 days, 20 hours.

I have a few questions regarding my procedure here:

  1. How long will this take? My best estimates were looking at the HDD activity light and counting a maximum of one blink per second. I assumed that single blink was one sector read, and that each sector was 4096 (it is on a flash drive). 2,720,000 MB on the 3TB drive at a 4 MB per second read time gives me about 7.87 days. The shortest time would be double that speed, and it would be done by now. The last "Possible partition" output was two days ago and gave an offset of 1421742mb while the first possible was at offset 1mb. I did see somewhere that sector sizes might be smaller. Am I close?

  2. 我是否采取了合适的行动来拯救我的驾驶？Ubuntu 论坛指南看起来很合理且非常相关。我的驱动器上只有一个分区，以前还有更多，但我已经擦除了它并只用一个重新开始。我记得它是事故前列出的唯一分区，并且使用了整个驱动器。我不确定上面是否有几个 MB 未使用的部分之一（这个奇怪的空白未分区点有时会在您创建分区时在 GParted 中完成，它会以未使用的 1mib 开头。）

  3. If I restore the partition using parted and I don't add all the sectors, or I add too many, would data still show up on that partition? The guide says to use the units of sectors to rebuild the partition table. If I use too few or too many units, will data still show up when I mount the drive and read it?

  4. I read there is a primary and secondary partition table or something, do those exist, can I copy them, how would I view them to confirm which one I want for recovery?

I need a second damage control option aside from sending it to a professional service. This isn't a business computer, but there are some important things to recover.

End Goal: Recover the single partition on the 3TB drive.

Update: Post gpart scan

As seen in reference pictures, the scan failed near the end of the drive. I've since placed the drive in a newer computer where I've run TestDisk. The quick scan found some of what gpart saw, but not what I know is there. I used the Deeper Scan option where within minutes it picked up on the partition in question, named Big Mongo. This is what I had named the drive in Windows.

Update 2: Post TestDisk scan

TestDisk completed (see additional ref pics) and identified my missing partition. I am able to have it list files within the program. Note the size at the bottom of the completed scan. The scan completed in a cool 10 hours vs 8 days from gpart.

Conclusion: For inquiring minds

运行 TestDisk 后，它找到了分区，但创建的表不正确，所以我运行gdisk并使用2048作为开始和最大大小作为结束重新构建它（见标记的答案）。让它处于休眠状态，启动没有问题。

参考图片
gdisk -l 评论https://isstatic.askoverflow.dev/9znYj.jpg
gpart scan 1/2 https://isstatic.askoverflow.dev/rWxuC.jpg
gpart scan 2/2 https:// /i.stack.imgur.com/HQYJ8.jpg

TestDisk 快速扫描

在此处输入图像描述

TestDisk 深度扫描初步

在此处输入图像描述

测试磁盘完成

在此处输入图像描述

partitioning gpt

1 个回答

  1. Best Answer

    分析

    你使用的命令

    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。

    调整大小

    Now when there is /dev/sdb1 available, you can easily query the filesystem for its size. I mean what the filesystem knows its size is. In general this is different than the size of corresponding partition. There are at least two tools you can use:

    • file -s /dev/sdb1

      You are interested in where it says sectors NNNNNN. Do not worry about hidden sectors (compare similar doubt for FAT).

    • ntfsresize --info /dev/sdb1

      You are interested in "Current volume size". Express it in 512-byte sectors (i.e. divide by 512).

    The number calculated from the output of ntfsresize may be little different than what file says. I think this has something to do with cluster size. In my tests it seems after mkfs.ntfs is asked to use a whole partition, file reports one sector less than the number of sectors in the partition. So use rather file, not ntfsresize, identify sectors NNNNNN, add one. This is how big the partition needs to be. In case of any doubt add 2048 sectors. It's overkill, but only 1 MiB of wasted space, not a lot; it will keep you safe for sure.

    If the partition (created in the previous paragraph) is bigger, you may want to shrink it. I note your final goal was to copy the filesystem to a smaller disk; and there is this Possible partition … size(764432mb) … in one of the screenshots. This makes me believe the filesystem is indeed smaller than the new partition. This is not a problem by itself, but if you'd like to create another partition after where the filesystem ends, or if you still want to copy the setup to a smaller disk, shrinking the partition is a good idea.

    The procedure:

    1. umount the filesystem if mounted.
    2. Remove the entry from the partition table.
    3. Create a new entry like in the previous paragraph, but this time specify the number of sectors just calculated. Note we're talking about the size of the new partition, not the end sector. If you need to know the end sector, use this formula: start+size-1=end. The alignment of the end of any partition shouldn't matter (it matters for the beginning) but if the tool insists to move the end slightly towards the end of the disk, let it.
    4. Save the partition table, run partprobe just in case.
    5. Verify that /dev/sdb1 mounts without errors. At first mount read-only (mount -o ro …) just in case.

    If the filesystem mounts fine, you're basically done. The partition table is now sane.

    Possible problems

    • The new partition will have a new unique partition GUID. On the other hand the "UUID" stored in the filesystem remains. You may need to reconfigure any tool/OS that relies on the former (or retrieve the old value from some configuration and apply it to the new partition, this single move will make all such configs valid again). I don't know which ID Windows uses to tell if it has seen the partition/filesystem before.
    • I can see the disk reports logical/physical sector size as 512/4096. Please read this question and the explanation in my answer to it. If there is at least one USB enclosure involved and the disk used to be connected differently than it is now (i.e. in a different enclosure; or via SATA now, in enclosure earlier; or vice versa) and you haven't verified that /dev/sdb1 mounts before you invoked sgdisk -R, then maybe the original (lost) partition table was valid for logical size of 4096; and if you tried to mount the partition before the mishap then you would experience the same problem as in the linked question. My point is my answer helps you create a partition table valid for the current setup. If this problem was going to hit you, it will hit you when you connect the drive in the original setup. Then you would need to adjust the partition table again. My answer to the linked question will help.

    • If the above bullet applies and if size(764432mb) is wrong then it's possible you had (and overwrote) a DOS partition table in MBR (not GPT) that defined one large partition spanning to the very end of the disk, and the filesystem itself spanned to (almost) the very end of the disk. In such case sgdisk -R created the secondary (backup) GPT at the end where a part of the filesystem should be. If the filesystem mounts fine then this is probably not the case. In general it may be. This is a scenario where you actually may have lost data; and you may lose more unless you fix it (ask a separate question if needed).

      Note if you're sure you had GPT then you're safe (because the secondary table was "always" there). And if you're sure the previous bullet doesn't apply then you're safe (because with logical sector size of 512 and with DOS partition table in the MBR the partition starting at the sector 2048 couldn't span to the end of your large disk).

    After you fix the partition table you will probably want to continue with your original plan. Then:

    • The other disk may have a different logical sector size. I'm not sure if (properly used) sgdisk -R recalculates entries between different sizes. I expect it to. In case it doesn't, you know what to do.
    • But maybe you wanted to clone the only partition of /dev/sdb (i.e. /dev/sdb1 or so) to /dev/sdh2; and there is /dev/sdh1 you want to keep. If so, sgdisk -R is not what you want to do. Copying the partition table from /dev/sdb to /dev/sdh2 (which is a partition) will give you nothing. Copying it to /dev/sdh will replace the current partition table there and mess with the current /dev/sdh2 (and /dev/sdh1 if any). Use sgdisk -R only if the target disk contains no data you want to keep. In case of any doubt ask a separate question after you fix the partition table of /dev/sdb. The new question should contain the output of gdisk -l (or fdisk -l) 对于两个磁盘，您应该清楚地说明要克隆到哪个分区，哪些分区是可消耗的，哪些分区应该保持不变。
    • 1

相关问题