AWS国际站 EBS 磁盘满了导致 EC2 无法启动？不停机扩容与根分区修复全过程
如果需要更深入咨询了解可以联系全球代理上TG: @cloudcup 他们在云平台领域有更专业的知识和建议，他们有国际阿里云，国际腾讯云，国际华为云，aws亚马逊，谷歌云一级代理的渠道，微软云开户充值。oss防风控上传加密系统。客服1V1服务，支持免实名、免备案、免绑卡。开通即享专属VIP优惠、充值秒到账、官网下单享双重售后支持。EBS 磁盘满了导致 EC2 无法启动，现场最怕的不是空间不够，而是顺手重启、盲目删文件，或者账号和付款状态没准备好，结果救援实例、快照和扩容都卡住。处理这类问题，顺序比动作更重要。
先判断能不能在线扩容；已经起不来的，目标是把停机时间压到最短，而不是硬追求零中断。
EBS 磁盘满了导致 EC2 无法启动时，先别急着重启
先看这几个信号：如果还能登录，执行 df -h 和 df -i；如果空间没满但 inode 满了，表现也会像磁盘满；如果启动时直接进 emergency mode，通常还要查文件系统和 /etc/fstab。
- 容量满：根分区 100%，服务日志、临时文件、包管理都会报错。
- inode 满：小文件太多，哪怕还有剩余容量也写不进去。
- 文件系统损坏：异常关机、强制重启后更容易出现。
不停机扩容的完整流程
只要实例还在运行，EBS 扩容本身可以在线完成。关键是不要只改卷大小，改完后还要把分区和文件系统一起扩进去。
- 先做快照。哪怕只是临时救火，也别跳过这一步。
- 在控制台修改 EBS 卷大小，或者用对应 API/CLI 提交扩容。
- AWS国际站 进入系统后确认设备名。Nitro 实例常见是 /dev/nvme0n1，老架构可能是 /dev/xvda。
- 先扩分区，再扩文件系统。常见顺序是 growpart 后接 resize2fs，若是 XFS 则用 xfs_growfs。
- 如果根盘套了 LVM，还要多做 pvresize 和 lvextend，不要直接跳到文件系统扩容。
- 最后再看 df -h、df -i，确认新空间已经挂到根分区。
| 场景 | 推荐动作 | 容易漏掉的点 |
|---|---|---|
| 还能 SSH，业务还在跑 | 在线扩容 | 卷改大后，分区和文件系统不会自动变大 |
| 能进系统但已经频繁报错 | 先扩容，再清日志 | 别在 100% 磁盘上大量删除后又忘了扩文件系统 |
| 完全起不来，进不了登录界面 | 离线救援 | 这时很难做到真正不停机，只能把停机时间压短 |
AWS国际站 如果已经无法启动，根分区修复要按救援流程走
严格来说，实例已经起不来，就不要再强调零停机了。更稳妥的做法是：先把根盘救出来，确认是空间问题还是文件系统问题，再决定清理还是扩容。
- 先拍快照，保留回滚点。
- 停止目标实例，分离根 EBS 卷。
- 把根卷挂到同一个可用区里的救援实例上。
- 在救援实例里识别磁盘，确认哪个分区是原来的根分区。
- 如果怀疑文件系统损坏，先做 fsck；如果只是日志和临时文件撑爆，先挂载后清理。
- 检查 /etc/fstab、UUID 和启动参数，避免因为挂载项写错导致再次进 emergency mode。
- 修复完成后再挂回原实例，启动验证。
很多人会忽略一个细节：磁盘满不是只有日志爆掉一种情况。数据库写满、Docker overlay2 膨胀、上传目录失控、包缓存堆积，都会在重启时把系统拖进半启动状态。
账号购买、实名认证、企业认证和支付状态，为什么会影响扩容
如果你是通过国际云账号、企业统一采购或渠道代付来做 AWS 资源管理，扩容时最常见的卡点不在技术，而在账号侧。救援实例、快照、EBS 卷、临时公网出口这些资源都要能正常下单，账号一旦被风控、付款失败或权限不足，修复就会中断。
| 要先确认的项 | 常见卡点 | 建议 |
|---|---|---|
| 账号状态 | 账单异常、付款失败、账号限制 | 先确保计费正常，别等到扩容时才发现下单被拒 |
| 支付方式 | 信用卡失效、账单地址不一致、企业月结未开通 | 提前维护主支付方式，保留备用付款链路 |
| 实名认证和企业认证 | 资料不完整、主体信息不一致 | 统一公司主体、联系人和付款主体，减少审核回退 |
| 风控审核 | 新号、异地登录、突增资源申请 | 紧急场景不要临时换卡、换主体、换登录环境 |
| 资源权限 | 没有修改卷、创建快照、挂载磁盘的权限 | 给运维账号预置最小但够用的 IAM 权限 |
| 资源配额 | 可用区、实例族、EBS 数量或快照额度不够 | 修复前先查配额，必要时先申请提升 |
如果你的采购模式里还有充值续费流程，别把账期和磁盘修复混在一起处理。先确认资金链路能跑通，再做扩容；否则最坏的情况是系统盘还没修好，余额或额度先断了。
成本控制别忽略：救火和长期扩容不是一回事
EBS 只要改大，费用就会按新容量计算。很多团队在应急时习惯一次性放大很多，后面却没有配套的日志轮转、保留周期和自动清理，结果成本一直挂着不降。更稳妥的方式是先把业务拉回安全线，再根据增长速度定二次扩容。
- 临时救援实例选最小可用规格，修完就释放。
- 快照保留到确认业务稳定后再决定是否长期留存。
- 日志目录、缓存目录、Docker 数据目录要分开评估，别只盯根分区。
- AWS国际站 如果经常满盘，应该把高增长目录单独挂盘，而不是每次都扩系统盘。
常见错误
- 一上来先重启，结果系统反复进入启动失败状态。
- 只扩了 EBS 卷，没有扩分区和文件系统。
- 把 inode 满误判成容量满，删了很多文件却没有解决写入失败。
- 在错误的可用区找救援实例，导致卷无法挂载。
- XFS 盘用了 resize2fs，或者 ext4 盘用了错误的扩容命令。
- 修完不检查 /etc/fstab，下一次启动还是回到同一个坑。
FAQ
Q1：能不能做到完全不停机？
如果实例还在运行，EBS 在线扩容可以做到业务不停机；如果已经无法启动，只能走救援和修复流程，严格意义上不可能完全零停机。
Q2：扩容后为什么 df 看不到新空间？
通常是只改了卷大小，分区和文件系统还没扩。先看 lsblk，再按分区类型处理，最后再看 df。
Q3：磁盘满了以后，是先删文件还是先扩容？
如果还能正常登录，优先扩容，再做清理；如果已经连 SSH 都不稳，先保住最小可启动空间，避免删到一半服务彻底起不来。
如果你这台 EC2 已经因为 EBS 满盘进不了系统，最实用的原则就一句：先保留回滚点，再分清是容量问题、inode 问题还是文件系统问题，然后按在线扩容或离线救援走。把账号权限、支付状态、风控和配额一起检查，通常比单纯盯着磁盘更能节省时间。
