![GPT 表恢复](https://linux22.com/image/1611240/GPT%20%E8%A1%A8%E6%81%A2%E5%A4%8D.png)
我已经把自己归入了不能阅读和破坏自己的东西的用户行列。
上周日,当我尝试将较大的 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 小时。
我对我的程序有几个问题:
这需要多长时间?我最好的估计是查看硬盘活动指示灯并计算每秒最多闪烁一次。我假设一次闪烁表示读取一个扇区,每个扇区为 4096(它在闪存驱动器上)。3TB 驱动器上的 2,720,000 MB 以每秒 4 MB 的读取速度给我大约 7.87 天。最短的时间将是该速度的两倍,现在应该已经完成了。最后一个“可能的分区”输出是两天前,给出的偏移量为 1421742mb,而第一个可能的偏移量为 1mb。我确实在某处看到过扇区大小可能更小。我接近了吗?
我是否采取了适当的措施来挽救我的驱动器?Ubuntu 论坛指南似乎很合理,而且非常具有可比性。我的驱动器上只有一个分区,以前还有更多分区,但我已将其擦除,然后从这一个分区重新开始。据我回忆,这是事故发生前列出的唯一分区,使用了整个驱动器。我不确定上面是否有那些几 MB 未使用的部分(这个奇怪的空白未分区点有时会在 GParted 中创建分区时出现,它会以 1mib 未使用开头。)
如果我使用 恢复分区
parted
,但没有添加所有扇区,或者添加了太多扇区,数据是否仍会显示在分区上?指南说使用扇区单位来重建分区表。如果我使用的单位太少或太多,安装驱动器并读取数据时是否仍会显示数据?我读到有一个主分区表和次分区表或类似的东西,这些存在吗,我可以复制它们吗,我如何查看它们以确认我想要恢复哪一个?
除了送去专业服务机构之外,我还需要第二个损害控制选项。这不是商用电脑,但有一些重要的东西需要恢复。
最终目标:恢复 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) …
其中一个屏幕截图中就有这个。这让我相信文件系统确实比新分区小。这本身不是问题,但如果您想在文件系统结束后创建另一个分区,或者如果您仍想将设置复制到较小的磁盘,缩小分区是一个好主意。
步骤:
umount
文件系统(若已安装)。- 从分区表中删除该条目。
- 像上一段一样创建一个新条目,但这次指定刚刚计算的扇区数。请注意,我们讨论的是新分区的大小,而不是结束扇区。如果您需要知道结束扇区,请使用以下公式:
start+size-1=end
。任何分区的末尾对齐都无关紧要(开头很重要),但如果工具坚持将末尾稍微移向磁盘末尾,请让它移动。 - 保存分区表,
partprobe
以防万一运行。 - 验证
/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 -l
fdisk -l