事情本身不复杂，线索都在日志里。一台 CentOS 7 用 dd 往盘尾写测试数据做压测，写完 reboot 后 fdisk -l 报 PMBR 与 GPT 不一致，parted 提示备份分区表不在磁盘末尾。
第一反应是「parted 的 fix 选项只修一侧，修完不核对另一侧仍然报错」，验证下来不成立。
把日志和配置对完，能解释这个现象的基本就这几处。GPT 在盘首存主分区表、盘尾存备份表，覆盖盘尾让两者校验对不上。另一种情况是内核为避免误判拒绝加载分区，设备节点存在但没有任何分区。
少数情况下是云盘容量被扩过而备份表还停在旧位置，同样触发这种提示。
动手时先看内核实际识别到哪些分区
lsblk -o NAME,SIZE,PARTTYPENAME && dmesg | tail -20再往下用 parted 交互方式修复两侧 GPT
parted /dev/vdb unit s print然后把备份表写回盘尾
sgdisk -e /dev/vdb && sgdisk -v /dev/vdb等前面都确认过，再重新读取分区表并挂载
partprobe /dev/vdb && mount /dev/vdb1 /data怎么算真的好了，看的是同一批现象。sgdisk -v 输出 no problems found，lsblk 能看到三个分区且大小与之前一致，挂载后 df 容量正确并可以读写。
这里还有个坑。分区表修好不代表数据没事，写盘尾可能已经压到文件系统尾部；修完立刻 fsck -n 检查，重要盘先做整盘镜像再动。这类问题最好一次改到位，反复小改反而容易把原因搅混。