谷歌云代理商拿货 GCP Compute Engine 磁盘空间爆满（Disk Full）导致系统崩溃救援步骤
这类故障最常见的现场不是“磁盘突然坏了”，而是 / 分区、/var、/tmp、数据库目录或日志目录先被写满，随后 SSH 登录失败、服务起不来、监控报警刷屏。真正需要先解决的，不是“为什么会满”，而是先让机器恢复可登录、可写入、可备份。
按我处理 GCP Compute Engine 故障的经验，Disk Full 事件里，70% 以上可以不重装系统，优先级通常是：保数据 > 恢复服务 > 再谈优化。
一、先判断你碰到的是哪一种“满盘”
很多人一上来就删文件，结果删错了方向。先看两项：
- df -h：看文件系统容量是否已满。
- 谷歌云代理商拿货 df -i：看 inode 是否耗尽。磁盘还有空间，但小文件太多时，同样会崩。
如果你发现 /var 100%，而根分区还有空间，通常是日志、缓存、容器层文件在膨胀；如果 / 直接满了，连系统命令都可能报错，这时就不要在原机上“慢慢找”，直接切救援流程。
二、10 分钟内要做的救援动作
- 谷歌云代理商拿货 先停写入：暂停 Web、数据库、定时任务、日志采集器，避免继续扩写。
- 立刻做快照：GCP Console 里对受影响的 Persistent Disk 先建 snapshot。业务很急也要先留证据，别边删边赌。
- 能登录就先腾空间：优先清理大文件、日志、缓存，而不是整个目录乱删。
- 不能登录就走救援盘：停止实例，把启动盘挂到另一台临时 VM 上做离线修复。
常用清理顺序一般是：
/var/log：应用日志、系统日志、审计日志/var/lib：Docker、数据库、包管理缓存/tmp、/var/tmp：临时文件- 包缓存：
apt clean、yum clean all - 日志压缩：
journalctl --vacuum-time=7d或--vacuum-size=500M
如果你有权限执行命令，可以先找出大户：
sudo du -xhd1 / | sort -h
sudo du -xhd1 /var | sort -h
sudo find /var/log -type f -name "*.log" -size +100M三、不能 SSH 登录时，GCP 上更稳的处理方式
很多故障现场不是“不会修”，而是“根本登不进去”。这时我通常建议按下面顺序：
- 控制台串口：如果你之前启用了 serial port access，可以在 GCP 控制台看启动输出，判断是磁盘满还是文件系统损坏。
- 挂载到救援机：停止故障 VM，把启动盘拆下来，挂到同区域一台临时 VM 上当数据盘。
- 离线清理：在救援机上挂载后删除日志、备份包、临时文件，再卸载回装。
- 必要时扩容：GCP 的 Persistent Disk 可以先扩容，再在系统里把文件系统扩上去。
注意：如果你的系统盘是 LVM、RAID、或有自定义分区，离线扩容/修复前最好先确认分区结构。很多“扩了盘但容量没涨”的问题，实际上卡在文件系统没执行 resize。
四、账号、实名认证、充值续费：救援时最容易被忽略的坑
Disk Full 不是纯运维问题，GCP 账号状态也会决定你能不能立刻处理。
| 环节 | 常见卡点 | 实际影响 |
|---|---|---|
| 账号开通 | 资料不完整、地区不匹配、组织信息填错 | Billing 绑定失败，后续无法扩盘 |
| 支付方式 | 信用卡拒付、虚拟卡风控、卡段与账单地址不一致 | 账单账号被暂停，实例可能停机 |
| 实名认证/风控 | 企业主体和付款主体不一致 | 可能触发人工审核，紧急操作被延后 |
| 续费/结算 | 卡片过期、额度不足、扣款失败 | 磁盘扩容、快照、临时 VM 都可能受影响 |
实操里最麻烦的是：你已经找到解决方案，但账单账号先挂了。所以如果这是生产环境，建议提前确认至少两点：
- 绑定的卡可长期扣款，不要只靠一次性虚拟卡。
- 账单联系人能及时收到扣款失败通知，别等实例停了才发现。
五、费用怎么选：扩容、快照恢复、还是临时救援机？
救援时不要只看“能不能修”，还要看成本和恢复速度。
| 方案 | 适用场景 | 优点 | 成本感受 |
|---|---|---|---|
| 直接扩容磁盘 | 系统还能进，主要是空间不够 | 最快，业务中断短 | 按扩容后的磁盘容量计费，适合长期保留 |
| 快照 + 新盘恢复 | 怀疑文件系统损坏、担心误删 | 可回滚，适合保数据 | 多一份 snapshot 费用，短期略高但更稳 |
| 救援机离线修复 | SSH 失效、系统起不来 | 不依赖原系统状态 | 多一台临时 VM 费用，按小时计 |
我的建议很直接：能在线扩容就别重装，能快照就别直接删数据。对于数据库、订单系统、日志审计系统，恢复速度和数据完整性比省几美元更重要。
六、为什么会反复满盘：不是“磁盘太小”这么简单
- 日志没轮转：应用异常后疯狂写日志，1 小时能吃掉几十 GB。
- 容器镜像堆积：Docker / containerd 未定期清理，
/var/lib/docker迅速膨胀。 - 数据库未做归档：binlog、WAL、dump 文件长期不清。
- 临时文件泄漏：任务失败后把中间文件留在
/tmp。 - 监控只看 CPU，不看磁盘：等告警时已经来不及。
如果你是生产环境，建议把磁盘告警线设在 70% / 85% / 95% 三档，而不是等到 100% 才通知。95% 以后，很多服务已经开始出现连锁故障。
七、常见问题：最容易在救援现场踩坑的点
Q1：磁盘扩容后，系统为什么还是显示原容量？
A：GCP 上只是把云盘变大了，系统里还要做分区和文件系统扩展。很多人只在控制台点了扩容，没进系统执行后续步骤。
Q2：我没有绑信用卡，能不能临时开 GCP 账号救火？
A：不建议。GCP 账单账号一旦不能通过支付验证，后续快照、扩盘、临时 VM 都可能受阻。紧急生产环境最好提前把账单和支付方式准备好。
Q3：虚拟信用卡能用吗？
A：能不能用和风控状态有关，很多账号会在首次扣款、续费、异常地区登录时被要求二次验证。救援场景里，稳定支付方式比“能刷一次”更重要。
Q4：如果是 Windows 机怎么办？
A：思路一样：先停写入、做快照、查临时文件和日志，再考虑扩盘。区别只是命令不同，通常从事件查看器、临时目录、更新缓存入手。
最后给一个实战建议
如果你现在就遇到 GCP Compute Engine Disk Full，我建议按这个顺序做：先快照，再判断能否在线清理；不能登录就挂救援盘；清理后马上扩容和补监控。如果你还没出故障，那就先检查账单账号、支付方式、磁盘告警和日志轮转，别等系统崩了才补手续。
