血的教训！生产环境Linux的/var分区，你绝对不能再只分几个G了！

运维的深夜，最怕磁盘告警。而罪魁祸首，往往是那个被低估的/var分区。

很多Linux新手，甚至有些老手，在安装系统时都会犯同一个错误：对/var分区的重要性认识不足，只默认分配几个G的空间。结果就是，在生产环境运行一段时间后，各种诡异问题接踵而至。

一、/var分区：Linux系统的“动态数据心脏”

/var，全称variable（变量），专门存放系统运行过程中经常变化的数据。把它比作系统的“日记本和工作间”再合适不过。

为什么默认的几个G根本不够用？因为这里存放的都是“增长大户”：

1. 日志文件（/var/log）—— 最大的“空间杀手”

• 系统日志（syslog、journald）
• Web服务器日志（Nginx、Apache）
• 数据库日志（MySQL、PostgreSQL）
• 应用服务日志

2. 软件包缓存（/var/cache）—— 容易被忽视的“囤积者”

• apt/yum/dnf等包管理器的下载缓存
• 长期不清理，轻松占用几个G

3. 数据库数据（/var/lib）—— 潜在的“巨无霸”

• MySQL默认数据目录：/var/lib/mysql
• PostgreSQL默认数据目录：/var/lib/pgsql
• 业务数据增长起来，几百GB都不够用

4. Docker存储（/var/lib/docker）—— 容器时代的“新威胁”

• Docker镜像、容器、卷都默认存在这里
• 镜像分层存储机制，占用空间不容小觑

二、科学规划：不同场景下的/var分区大小指南

决策原则：按需分配，留足余量，特殊数据单独处理

三、实战补救：当/var分区真的爆满了怎么办？

即使规划得再好，也可能会遇到空间告急的情况。以下是救命锦囊：

第一步：快速定位问题根源

# 查看整体磁盘使用情况
df -h

# 深入/var目录，找出真正的“空间杀手”
sudo du -sh /var/* | sort -hr

# 使用ncdu工具（更直观）
sudo apt install ncdu  # Ubuntu/Debian
sudo yum install ncdu  # RHEL/CentOS
sudo ncdu /var/

第二步：安全清理（治标）

# 清理包管理器缓存
# Ubuntu/Debian
sudo apt clean          # 清理所有缓存
sudo apt autoclean      # 只清理过时缓存

# RHEL/CentOS/Rocky  
sudo yum clean all
sudo dnf clean all

# 清理日志文件（正确姿势）
sudo truncate -s 0 /var/log/some-huge-log.log  # 清空但不删除文件

# 清理Docker空间
docker system prune -a    # 清理所有未使用资源

第三步：配置日志轮转（治本）

编辑/etc/logrotate.conf和/etc/logrotate.d/下的配置文件，确保日志定期切割和删除：

# 示例：为Nginx日志配置轮转
/var/log/nginx/*.log {
    daily          # 每天轮转
    missingok      # 日志丢失不报错
    rotate 7       # 保留7天的日志
    compress       # 压缩旧日志
    delaycompress  # 延迟一天压缩
    notifempty     # 空文件不轮转
    create 0640 www-data adm  # 创建新文件的权限
    postrotate
        invoke-rc.d nginx rotate >/dev/null 2>&1
    endscript
}

第四步：终极解决方案——扩容

如果使用LVM（逻辑卷管理），扩容相对简单：

# 查看卷组信息
sudo vgdisplay

# 扩展逻辑卷（增加10G）
sudo lvextend -L +10G /dev/mapper/ubuntu-vg/var

# 调整文件系统大小
sudo resize2fs /dev/mapper/ubuntu-vg/var  # 对于ext4
sudo xfs_growfs /dev/mapper/ubuntu-vg/var # 对于xfs

如果没有使用LVM，扩容将非常困难，通常需要备份、重新分区、恢复数据。这再次证明了初期合理规划的重要性。

四、运维最佳实践：防患于未然

1. 角色决定大小：部署前明确服务器用途，依此规划分区
2. 强制使用LVM：为所有生产服务器配置LVM，为未来留足灵活性
3. 关键数据分离：数据库、Docker等大型数据单独分区
4. 日志管理制度化：所有项目上线前必须配置合理的logrotate策略
5. 监控告警必不可少：设置磁盘使用率监控（80%警告，90%严重告警）

五、真实案例分享

某电商公司数据库服务器，最初为/var分区分配了50G空间。随着业务增长，MySQL数据文件半年内增长到200G，导致磁盘频繁告警。

解决方案：

1. 临时清理日志缓解危机
2. 购买新硬盘，通过LVM扩展空间
3. 长期方案：将MySQL数据迁移到单独挂载的SSD阵列（/data目录）

教训：对于数据库服务器，根本不应该让数据文件留在/var分区内。

结语

/var分区虽小，却关系到整个系统的稳定运行。一次合理的规划，胜过无数次的紧急抢救。希望本文能帮助你避免踩坑，让你的Linux服务器运行得更加稳健。

你有过被/var分区坑惨的经历吗？欢迎留言分享你的故事和解决方案！