磁盘容量规划需匹配业务增长节奏，避免盲目预留或告警扩容；应分日志、数据库、上传目录估算写入量，分离分区并设分层监控阈值，按文件系统类型选择正确扩容方式。
磁盘容量规划不是一次性配置，而是要和业务增长节奏对齐的持续过程。盲目预留 50% 空间或等告警再扩容，大概率会遇到 df -h 显示 Use% = 100%、write error: No space left on device 这类阻断性故障。
怎么估算初始容量：看日志、数据库、文件上传三类主力写入源
很多团队直接按当前 df -h 结果乘以 2 或 3，这忽略了写入模式差异。真实增长往往集中在少数路径：
-
/var/log/下服务日志：查journalctl --disk-usage或du -sh /var/log/* | sort -hr | head -5，重点关注nginx、mysql、app类目录 -
/var/lib/mysql/或/data/pgdata/：运行SELECT pg_size_pretty(pg_database_size('dbname'));（PostgreSQL）或SELECT table_schema, SUM(data_length + index_length) FROM information_schema.TABLES GROUP BY table_schema;（MySQL） - 用户上传目录（如
/opt/app/uploads/）：用find /opt/app/uploads -type f -mtime -30 | xargs du -ch | tail -1估算月增体积
分区策略必须匹配恢复与运维需求
把所有数据塞进 / 根分区看似省事，但一旦 /var/log 写满，systemd-journald 崩溃、sshd 日志无法写入、甚至系统无法登录。关键原则是分离可增长路径：
-
/分区保留 15–20 GB 足够，只放系统和静态二进制 -
/var单独挂载（尤其含/var/log、/var/lib），初始给 40–60 GB，并启用logrotate配置压缩与轮转周期 -
/home或业务数据目录（如/data）务必独立分区，支持在线扩容（LVM 或 XFS +xfs_growfs） - 避免
/tmp使用tmpfs存放大文件——内存溢出风险远高于磁盘满
监控阈值不能只设 85%：要分层+预测
单纯用 df -h 告警在高写入场景下等于“等死”。必须叠加时间维度判断是否来得及人工介入：
- 基础层：
df -h警戒线设为 75%，严重线设为 88%，触发后自动发钉钉/企业微信 - 预测层：每天凌晨跑脚本记录
df --output=avail /data | tail -1，用最近 7 天下降斜率推算耗尽时间（单位：小时），if [ $hours_left -lt 48 ]; then send_alert "less than 2 days"; fi - 例外处理：监控需排除临时文件干扰，例如
lsof +L1查找被删除但仍被进程占用的文件（常见于未重启的 Java 服务），这类空间不会被df释放，但lsof能定位
LVM 扩容不是银弹：XFS 和 ext4 行为完全不同
线上扩容失败常因文件系统类型误判。LVM 逻辑卷能扩大，但底层文件系统未必支持在线扩展：
- XFS：支持在线扩容，执行
lvextend -l +100%FREE /dev/vg01/lv_data && xfs_growfs /data即可，无需卸载 - ext4：同样支持在线扩容，但必须先
resize2fs /dev/vg01/lv_data（注意：参数是设备路径，不是挂载点）；若之前用mkfs.ext4 -m 5创建，5% 的保留空间会吃掉有效容量，生产环境建议改用-m 1 - ext3 或老旧系统：不支持在线 resize，必须
umount后操作，且需提前验证备份可用性
#!/bin/bash
# 示例：自动检测文件系统类型并执行对应扩容命令
FS_TYPE=$(stat -fc "%T" /data)
LV_PATH=$(lsblk -no MOUNTPOINT,PKNAME /data | awk '/data/ {print "/dev/" $2}')
case $FS_TYPE in
"xfs") xfs_growfs /data ;;
"ext4") resize2fs $LV_PATH ;;
*) echo "unsupported fs: $FS_TYPE"; exit 1 ;;
esac真正难的不是扩容命令本身，而是搞清哪些目录在持续写入、哪些日志没配轮转、哪些应用把临时文件硬编码到根分区——这些细节不会出现在架构图里，但会在凌晨三点决定你能不能睡个好觉。
