购买云服务器时，系统盘选 40G、80G 还是更大，很多人只看“Linux 安装完还剩多少”。结果上线几个月后，Docker 镜像、应用日志、数据库文件和临时包把根分区塞满，Nginx 无法写日志、容器启动失败，甚至数据库进入只读或异常退出。

系统盘是否够用，不能只看当前占用，而要计算增长速度、更新峰值、回滚空间和安全余量。本文给出一套可执行的方法，帮助你判断 40G 是否足够、什么时候应扩容，以及哪些数据应该迁到独立云盘。

一、40G 系统盘适合哪些场景

40G 并非一定小。以下场景在治理得当时通常可以使用：

• 只运行 Nginx、轻量 API、运维代理等少量服务；
• Docker 镜像数量少，并且定期清理旧版本；
• 日志已轮转，或发送到远端日志系统；
• 数据库、对象文件和备份均不放在根分区；
• 发布过程不会同时保留大量镜像、构建缓存和安装包；
• 监控能够在磁盘达到阈值前告警。

如果同一台机器同时运行数据库、CI 构建、多个 Docker 服务，或需要保留较长时间的本地日志，40G 很容易变成容量风险点。

二、先查清楚：空间到底被谁占用

先看文件系统和挂载关系：

df -hT
lsblk -f
findmnt

然后统计根目录下一级目录，不跨越其他挂载点：

sudo du -xhd1 / 2>/dev/null | sort -h
sudo du -xhd1 /var 2>/dev/null | sort -h

常见大户主要有四类。

1. Docker 镜像、容器层和构建缓存

docker system df -v
sudo du -sh /var/lib/docker 2>/dev/null

不要看到 RECLAIMABLE 就直接执行全量清理。先确认旧镜像是否仍用于回滚、停止容器是否需要保留，以及构建缓存是否影响下一次发布。

2. systemd 和应用日志

journalctl --disk-usage
sudo find /var/log -type f -printf '%s %p\n' 2>/dev/null | sort -nr | head -20

如果日志文件已经删除，空间却没有释放，检查仍持有文件句柄的进程：

sudo lsof +L1

3. 数据库与业务上传文件

sudo du -sh /var/lib/mysql /var/lib/postgresql /srv /data 2>/dev/null

数据库数据、二进制日志、WAL、上传文件和本地备份不应混在一起估算。它们的增长速度、恢复方式和 IO 特征都不同。

4. 软件包缓存与临时文件

sudo du -sh /var/cache /tmp /var/tmp 2>/dev/null
sudo find /tmp /var/tmp -xdev -type f -size +500M -ls 2>/dev/null

清理前确认文件归属和业务影响，不要把正在上传、转码或导入的数据当作无用临时文件。

三、用增长量计算系统盘，而不是凭感觉选容量

可以用下面的公式估算：

所需容量 = 固定占用
         + 日均增长量 × 本地保留天数
         + 发布与升级峰值空间
         + 回滚所需空间
         + 安全余量

假设一台云服务器当前固定占用 13G：

• 系统和软件：7G；
• 当前 Docker 镜像与容器层：4G；
• 应用文件：2G；
• 日志每天净增长 600MB，本地保留 14 天；
• 发布时新旧两个镜像并存，需要额外 5G；
• 预留 20%～30% 安全余量。

仅增长和发布峰值就需要约 13.4G，再加固定占用已经超过 26G。若系统盘是 40G，短期可能够，但容错空间并不宽裕；只要日志轮转失败、镜像未清理或一次大版本升级，就可能越过安全线。

不要把示例数字直接套到自己的机器。应连续记录至少 7 天，覆盖一次发布和业务高峰。

date
df -B1 /
sudo du -sx --block-size=1 /var/lib/docker /var/log /var/lib/mysql 2>/dev/null

每天同一时间采样，用末值减初值再除以天数，就能得到各目录的平均净增长。容量波动大的业务还要看单日最大增长，而不只是平均值。

四、配置判断：哪些数据留系统盘，哪些放独立云盘

建议留在系统盘

• 操作系统、软件包和基础配置；
• 容量可控的应用程序；
• 少量可轮转日志；
• 能够重新拉取的运行时文件。

更适合独立数据盘

• MySQL、PostgreSQL 等持续增长的数据目录；
• 用户上传、媒体素材和长期归档；
• 容量较大的 Docker 数据目录；
• 需要单独扩容、快照或备份策略的数据；
• 与系统盘有明显 IO 竞争的工作负载。

分盘的价值不只是“多一个盘符”。它能让系统升级、数据扩容、快照策略和故障恢复边界更清晰。不过独立云盘并不会自动带来高可用，仍需设计备份、校验和恢复演练。

五、系统盘快满时，先止血再扩容

第一步：确认是否真的快满

df -h /
df -ih /

df -h 看块空间，df -ih 看 inode。容量有余但 inode 用尽，也会出现无法创建文件。

第二步：执行可回滚的安全清理

先列出候选，不要直接删除：

docker image ls
docker container ls -a
docker builder du
journalctl --disk-usage

确认无回滚需求后，按对象逐项清理；同时配置日志轮转和镜像保留规则，避免几天后再次占满。

第三步：决定扩系统盘还是迁移数据

适合直接扩系统盘的情况：

• 增长主要来自系统、软件和可控镜像；
• 数据量不大，未来增长可预测；
• 当前挂载结构简单，希望快速降低风险。

更适合新增数据盘并迁移的情况：

• 数据库、上传文件或 Docker 目录持续增长；
• 需要独立的性能、快照、备份或扩容策略；
• 根分区和业务数据存在明显 IO 竞争；
• 希望重装或替换系统盘时保留数据边界。

六、扩容后还要扩分区和文件系统

云控制台扩大磁盘容量后，Linux 文件系统不一定自动变大。先确认设备与分区：

lsblk
df -hT
sudo fdisk -l

常见分区可以使用 growpart 扩展，例如：

sudo growpart /dev/vda 1

ext4 文件系统常用：

sudo resize2fs /dev/vda1

XFS 文件系统通常按挂载点扩展：

sudo xfs_growfs /

设备名、分区号和文件系统必须以实际输出为准。执行前应创建可用备份或快照，确认云平台支持的扩容流程，并准备回滚方案；不要照抄示例设备名。

如果使用 LVM，还需先扩展物理卷和逻辑卷，再扩文件系统：

sudo pvs
sudo vgs
sudo lvs

七、迁移到数据盘的基本流程

以一个业务目录为例，推荐遵循“挂载、同步、停写、增量同步、切换、验证、保留回滚”的顺序：

sudo rsync -aHAX --numeric-ids /原目录/ /data/新目录/

完成首轮同步后：

1. 停止对应服务，避免继续写入；
2. 再执行一次增量同步；
3. 校验文件数量、容量、属主和权限；
4. 修改服务配置或挂载关系；
5. 启动服务并验证读写；
6. 保留原目录一段观察期，确认无误后再清理。

数据库不能仅靠复制正在写入的数据目录完成可靠迁移，应使用数据库支持的停机复制、物理备份或复制切换方案，并验证一致性。

八、如何验证扩容或迁移成功

完成后不要只看 df。至少检查：

lsblk -f
findmnt
df -hT
df -ih

同时验证：

• 服务能够启动并持续写入；
• 重启后数据盘能按预期自动挂载；
• /etc/fstab 使用稳定的 UUID，而不是易变化的设备名；
• 应用日志、Docker 或数据库确实写入新路径；
• 原目录没有继续增长；
• 监控和告警已覆盖新挂载点；
• 备份任务包含迁移后的数据位置。

建议设置两级告警，例如提前预警和紧急告警，并同时监控剩余字节、使用率、inode 与日增长速度。固定的 80% 阈值并不适合所有容量：1TB 磁盘剩余 20% 和 40G 磁盘剩余 20%，可用时间完全不同。

九、常见误区

1. 系统装完只占几 GB，所以 40G 永远够：真正增长的是日志、镜像、数据库和临时文件。
2. 根分区满了就执行 docker system prune -a：可能删除仍需回滚的镜像和停止容器资源。
3. 扩了云盘就等于扩了文件系统：分区和文件系统可能仍保持原容量。
4. 把数据库移到数据盘就等于有备份：独立磁盘、快照和可恢复备份不是同一件事。
5. 只监控百分比，不看增长速度：无法判断剩余空间还能支撑几天。
6. 迁移后立刻删除原目录：一旦权限、挂载或配置错误，就失去快速回滚条件。

结语：把容量、性能和恢复边界一起规划

选择云服务器磁盘时，先统计操作系统、Docker、日志、数据库和发布峰值的真实占用，再根据 7 天增长数据估算保留周期与安全余量。可控、可重建的数据可以留在系统盘；持续增长、需要独立备份或性能保障的数据，更适合使用独立云盘。

如果系统盘在未来一个扩容周期内会越过安全线，不要等到写满再处理。应结合容量增长、磁盘 IO、快照与备份、业务停机窗口，选择扩系统盘、增加数据盘或迁移到更合适的云服务器存储规格。这样购买和升级的依据是可验证的数据，而不是一个看起来“应该够用”的数字。