能修，但需区分主头、备份头、分区条目区状态：当gdisk提示“invalid main GPT header, but valid backup”时，说明主头损坏、备份头完好，可直接运行sudo gdisk /dev/sdX后按v验证、w写入，gdisk自动用备份头重建主头并重算CRC，再执行sudo partprobe刷新内核识别。
能修，但必须分清主头、备份头、分区条目区各自状态——直接 gdisk -l 报 “invalid main GPT header, but valid backup” 就说明主头坏了、备份头还活着，这时候根本不用扫描，gdisk 自己就能重建。
用 gdisk 一键恢复主GPT头（备份头完好时）
这是最常见也最省事的场景：系统提示 “The primary GPT table is corrupt, but the backup appears OK”，内核已自动 fallback 到备份表，lsblk 能看到 sdb1 等子设备，但 fdisk -l 显示混乱或报错。此时修复本质就是把备份头复制回 LBA 1。
- 运行
sudo gdisk /dev/sdX（替换为真实设备，如/dev/sdb） - 进入后直接按
v验证，确认输出含Found invalid GPT and valid backup - 按
w写入——gdisk会自动用备份头重建主头、重算 CRC，并同步更新分区数组校验和 - 退出后执行
sudo partprobe /dev/sdX让内核重新读取分区表
注意：w 不等于“保存当前编辑”，它专指“用备份结构覆盖主结构”。只要备份头没被覆写过，这步成功率接近 100%。
主头 & 备份头都损坏时，必须用 testdisk 深度扫描
当 gdisk -l /dev/sdX 输出 Found invalid GPT and invalid MBR，或 parted -l 显示 Partition Table: unknown，说明两份 GPT 头都失效，无法靠冗余恢复，只能靠文件系统签名反推原始分区边界。
- 安装：
sudo apt install testdisk（Debian/Ubuntu）或sudo yum install testdisk（RHEL/CentOS） - 启动：
sudo testdisk /dev/sdX→ 选EFI GPT→Analyse - 先跑
Quick Search：适用于断电、误删、快速格式化等场景，几秒出结果 - 若无果，退回选
Deeper Search：逐扇区扫描 NTFS/ext4/XFS 等签名，2TB 盘约耗 10–20 分钟 - 找到分区后按
P预览目录，确认能看到真实文件名和时间戳再选Write
关键点：testdisk 不依赖任何 GPT 元数据，它从物理扇区里捞 ext4 superblock 或 NTFS $MFT 起始位置，所以即使整个 GPT 区（LBA 1–33）全被 dd 清空也能恢复。
修复后仍挂载失败？先查是不是文件系统层问题
分区表修好了，lsblk 显示 sdb1，但 mount /dev/sdb1 /mnt 报 wrong fs type 或 bad magic number，说明问题已下沉到文件系统层，不是 GPT 的事了。
- 用
sudo file -s /dev/sdX1快速判断：返回Linux rev 1.0 ext4 filesystem data→ 文件系统结构尚存；返回data或cannot open→ 可能是分区表修复错位，或底层扇区损坏 - 确认结构存在后，再针对性修复：
sudo e2fsck -y /dev/sdX1（ext4）、sudo xfs_repair /dev/sdX1（XFS） - 切勿在未验证分区表正确性前运行
fsck：起始扇区偏 1 个，e2fsck就会把文件系统当成垃圾数据清掉
真正容易被忽略的是：GPT 分区表修复完成 ≠ 数据可访问。很多用户卡在最后一步，以为修完 gdisk 就万事大吉，结果 mount 失败就慌着重格，反而把还能救的文件系统给毁了。
