GCE resize disk后空盘、OS错误、SSH故障、网站宕机修复方法

所有操作优先保证数据安全，禁止直接操作原故障磁盘，避免二次损坏导致数据永久丢失。

前置止损操作 #

• 立刻进入GCE控制台磁盘列表，找到故障实例挂载的异常持久盘，创建全量快照，所有后续修复操作均基于该快照生成的副本盘开展。
• 强制停止故障VM实例，待快照创建完成后，将原故障盘从实例上卸载，暂时留存不要删除。

搭建临时修复环境 #

• 在故障实例所在可用区，新建一台同操作系统版本的最低规格临时救援VM，确保该实例可以正常启动、SSH连接即可。
• 基于之前创建的故障盘快照，生成一块新的持久盘，容量与扩容后显示的异常容量（即你看到的两倍预期容量值）保持一致，将该副本盘作为非启动盘挂载到临时救援VM上。
• SSH连接到临时救援VM，执行lsblk查看块设备列表，识别到挂载的副本盘（通常设备名为sdb，救援VM自身系统盘为sda）。如果执行fdisk -l /dev/sdb提示无有效分区表、分区容量异常，即为扩容操作导致分区表损坏、文件系统超级块错位，对应你遇到的OS识别磁盘为空、容量显示异常问题。

分区与文件系统修复 #

• 先修复分区表：
  • 若原磁盘为GPT分区格式：执行gdisk /dev/sdb进入交互界面，输入r进入修复菜单，输入b调用磁盘尾部备份的GPT分区表覆盖损坏的主分区表，输入w写入配置后退出，该操作可解决80%以上GCE在线扩容触发的GPT头损坏问题。
  • 若原磁盘为MBR分区格式：先通过系统包管理器安装testdisk工具，执行工具后选择对应副本盘，按照引导执行快速扫描，识别到原有根分区、swap分区的正确起始扇区后，将正确的分区表写入磁盘即可。
• 分区表修复完成后，执行文件系统一致性检查与修复，不要直接挂载分区：
  • 若文件系统为ext4格式：执行e2fsck -f -y /dev/sdb1（sdb1为修复后识别到的原系统根分区，根据实际设备名调整）；如果提示超级块损坏，先执行mke2fs -n /dev/sdb1查看备份超级块的存储位置，再执行e2fsck -b 备份超级块扇区位置 /dev/sdb1完成修复。
  • 若文件系统为xfs格式：执行xfs_repair /dev/sdb1完成修复。
• 修复完成后创建临时挂载点：mkdir -p /mnt/repair && mount /dev/sdb1 /mnt/repair，进入挂载目录检查原系统的/etc配置目录、/home用户目录、站点存储目录（通常在/var/www或自定义业务路径），确认3个托管网站的程序文件、数据库文件完整无缺失。

业务恢复与验证 #

• 确认数据完整后，先执行umount /mnt/repair卸载副本盘，再在GCE控制台将该副本盘从临时救援VM上卸载。
• 新建VM实例，实例规格、网络配置、防火墙规则与原故障实例完全一致，将修复完成的副本盘作为启动盘挂载到新实例上，启动实例。
• 实例启动后先验证22端口连通性，SSH连接成功后执行df -h确认根分区容量显示为扩容后的预期值，无识别错误。
• 依次启动Web服务、数据库服务、站点相关的进程守护服务，逐个验证3个网站的访问可用性，确认业务完全恢复。
• 业务稳定运行24小时无异常后，可清理原故障实例、原故障盘、临时救援VM，故障初期创建的磁盘快照建议留存至少7天，确认无数据遗漏后再删除。

注意：后续执行磁盘扩容操作前必须先创建磁盘快照，尽量在实例运行状态下发起扩容操作，扩容完成后先在系统内执行分区扩容、文件系统扩容指令，禁止在实例关机状态下反复调整磁盘容量，极易触发分区表错位、磁盘识别异常问题。如果修复过程中分区扫描结果不符合预期，不要执行任何写入操作，基于快照重新生成副本盘再次尝试修复即可。

内容的提问来源于stack exchange，提问作者tlmtransmogrify