服务器磁盘爆红告警？别慌！运维老司机的 3 步日志清理 + 3 类扩容方案（附避坑指南）
服务器磁盘满并非绝症，80% 的紧急情况都能通过 “诊断 + 日志清理” 快速缓解，剩下的 20% 才需要扩容。本文就从实际运维场景出发，教你用 3 步清理无效日志释放空间，再根据本地磁盘、LVM、云盘 3 种常见场景，给出严谨的扩容方案，全程附实操命令和避坑要点，新手也能跟着做。
一、先诊断：别盲目删文件，搞清楚 “谁占了空间”
磁盘满的第一反应不是删文件，而是先搞清楚哪些目录、哪些文件在占用空间，避免误删关键数据（比如误删数据库文件，哭都来不及）。这里分享 3 个核心诊断命令，从整体到局部定位问题。
1. 用 df 命令看整体磁盘占用：锁定满了的分区
首先执行df -hT，查看所有分区的使用率和文件系统类型（-h 是人性化显示大小，-T 是显示文件系统，比如 EXT4、XFS）：
\[root@server \~]# df -hT
Filesystem Type Size Used Avail Use% Mounted on
/dev/sda3 ext4 40G 38G 500M 98% /var # 这里/var分区98%，是问题分区
/dev/sda2 ext4 20G 8G 11G 42% /
/dev/sdb1 xfs 500G 120G 380G 24% /data重点关注Use%列，找到使用率超过 85% 的分区（一般运维会把告警阈值设为 85%），比如上面的/var分区，接下来就针对这个分区深入排查。
2. 用 du 命令找大目录：定位空间 “黑洞”
知道了/var分区满了，再用du -sh /var/*查看/var下各目录的大小（-s 是汇总大小，-h 是人性化显示）：
\[root@server \~]# du -sh /var/\*
8.2G /var/cache
30G /var/log # 这里/var/log占了30G，是主要问题
2.1G /var/lib
120M /var/spool很明显，/var/log目录占了 30G，这是 Linux 系统默认的日志存储目录，也是磁盘满的 “重灾区”—— 很多时候是日志没配置轮转，或者调试日志没及时清理导致的。
3. 用 ls 命令找大文件：精准定位 “罪魁祸首”
再进入/var/log目录，用ls -lhS查看文件大小（-l 是详细信息，-h 是人性化，-S 是按大小排序）：
\[root@server \~]# cd /var/log
\[root@server log]# ls -lhS
-rw-r--r-- 1 root root 18G Aug 15 02:30 nginx-access.log # Nginx访问日志18G
-rw-r--r-- 1 root root 8G Aug 15 02:30 tomcat-debug.log # Tomcat调试日志8G
-rw-r--r-- 1 root root 2.1G Aug 15 02:30 messages
-rw-r--r-- 1 root root 1.2G Aug 15 02:30 secure到这里就清晰了：Nginx 访问日志和 Tomcat 调试日志占了 26G，这两个是 “无效日志”（访问日志超过 7 天的基本没用，调试日志在问题解决后也可清理），接下来就针对性清理。
二、3 步清理无效日志：安全释放空间，不影响服务运行
很多同学清理日志时会犯两个错：一是直接rm -rf 大日志文件，但如果日志文件正在被进程占用（比如 Nginx 还在写日志），删了之后空间也不会立即释放；二是误删系统关键日志（比如messages、secure），导致后续排查问题没依据。
下面 3 步清理法，既保证安全，又能立即释放空间，适用于 Linux 所有发行版（CentOS、Ubuntu、Debian 都通用）。
第一步：界定 “无效日志”，避免误删
在清理前，先明确哪些日志可以删，哪些不能删，这是安全清理的核心：
像前面案例中的nginx-access.log（实时日志但太大）和tomcat-debug.log（调试日志），就属于可清理范围；而messages（系统实时日志）不能删，只能截断。
第二步：安全清理，两种场景对应两种方法
根据日志是否被进程占用，清理方法不同，这一步一定要用对，否则空间释放不了。
场景 1：日志已停止写入（比如调试日志）—— 直接压缩或删除
如果日志文件已经不产生新内容（比如 Tomcat 调试日志，已经关闭调试模式），可以直接压缩备份，或者删除：
• 压缩备份（推荐，万一后续需要排查问题）：
\# 用gzip压缩，压缩后会生成tomcat-debug.log.gz，原文件会删除
gzip tomcat-debug.log
\# 如果需要保留原文件，用cp先备份
cp tomcat-debug.log tomcat-debug.log.bak
gzip tomcat-debug.log.bak• 直接删除（确认没用的情况下）：
rm -f tomcat-debug.log # -f避免提示，直接删除
场景 2：日志正在被进程占用（比如 Nginx 访问日志）—— 截断文件，不删文件
如果日志还在被进程写入（比如 Nginx 还在运行，持续写 access.log），直接rm删除后，进程还会持有文件句柄，磁盘空间不会释放（用df -h看还是满的）。这时候要截断文件，让文件大小变为 0，同时不影响进程写入。
正确操作步骤：
1. 先确认进程是否在占用日志：用 lsof命令查看（如果没装 lsof，先装yum install lsof -y或apt install lsof -y）：
\[root@server log]# lsof | grep nginx-access.log
nginx 12345 root 5w REG 8,3 18892345678 /var/log/nginx-access.log # 有进程占用1. 截断文件，用 echo >或truncate命令（二选一即可）：
\# 方法1：echo空内容写入文件，快速截断
echo > nginx-access.log
\# 方法2：truncate更灵活，比如截断到100M（适合想保留部分日志的场景）
truncate -s 100M nginx-access.log1. 验证空间是否释放：执行 df -h /var，会发现/var分区的使用率已经降下来了：
\[root@server log]# df -h /var
Filesystem Size Used Avail Use% Mounted on
/dev/sda3 40G 12G 26G 32% /var # 从98%降到32%，空间释放成功第三步：配置长效防护，避免日志再 “爆盘”
清理完日志只是应急，要避免下次再出现同样问题，需要配置日志轮转和定时清理策略，让日志自动 “瘦身”。
1. 系统日志：配置 logrotate（Linux 默认自带）
Linux 系统日志（比如/var/log/messages、/var/log/secure）和大部分应用日志（Nginx、Tomcat）都可以用logrotate实现自动轮转。logrotate的配置文件在/etc/logrotate.conf，应用专属配置在/etc/logrotate.d/目录下。
以 Nginx 日志为例，配置自动轮转：
1. 新建 Nginx 日志轮转配置文件：
vi /etc/logrotate.d/nginx
1. 写入以下配置（注释说明每个参数作用）：
/var/log/nginx-access.log /var/log/nginx-error.log { # 要轮转的日志文件
  daily # 每天轮转1次
  rotate 7 # 保留7天的轮转日志（超过7天自动删除）
  compress # 轮转后压缩日志（节省空间）
  delaycompress # 延迟1天压缩（避免刚轮转的日志还在被读取）
  missingok # 如果日志文件不存在，不报错
  notifempty # 日志为空时不轮转
  create 0644 root root # 新建日志文件的权限和所有者
  sharedscripts # 所有日志轮转完后只执行一次postrotate脚本
  postrotate # 轮转后执行的脚本（让Nginx重新打开日志文件）
  if \[ -f /var/run/nginx.pid ]; then
  kill -USR1 \`cat /var/run/nginx.pid\`
  fi
  endscript
}1. 测试配置是否生效：执行 logrotate -d /etc/logrotate.d/nginx（-d 是调试模式，不实际执行），如果没有报错，说明配置没问题。
2. 自定义日志：用定时任务（crontab）清理
有些应用日志（比如自定义的业务日志）可能不支持 logrotate，这时候可以用 crontab 定时清理。比如每天凌晨 3 点删除/var/log/business/目录下超过 30 天的日志：
1. 新建清理脚本：
vi /usr/local/scripts/clean\_business\_log.sh
1. 写入脚本内容（用 find 命令查找旧日志并删除）：
\#!/bin/bash
\# 清理/var/log/business/下超过30天的.log文件
find /var/log/business/ -name "\*.log" -mtime +30 -exec rm -f {} \\;
\# 清理/var/log/business/下超过15天的.gz压缩日志
find /var/log/business/ -name "\*.log.gz" -mtime +15 -exec rm -f {} \\;1. 给脚本加执行权限：
chmod +x /usr/local/scripts/clean\_business\_log.sh
1. 配置 crontab 定时任务：
crontab -e # 编辑定时任务
1. 加入以下内容（每天凌晨 3 点执行）：
0 3 \* \* \* /usr/local/scripts/clean\_business\_log.sh # 分 时 日 月 周 脚本路径
三、3 类扩容方案：日志清理不够用？按需选择扩容方式
如果日志清理后，磁盘空间还是不够（比如/data分区存储的数据库文件持续增长），就需要扩容。根据服务器存储类型（本地磁盘、LVM、云盘），扩容方案不同，下面分别讲实操步骤。
方案 1：本地物理磁盘扩容（适用于自建服务器）
如果服务器是自己托管的物理机，或者虚拟机（比如 VMware）添加了新磁盘，需要手动挂载并扩容分区。以 CentOS 7 为例，假设新增了一块 500G 的磁盘/dev/sdc，要把它扩容到/data分区（原/data在/dev/sdb1，EXT4 文件系统）。
步骤 1：识别新磁盘，创建分区
1. 查看新磁盘是否被识别：
fdisk -l # 会看到/dev/sdc，大小500G
1. 给新磁盘创建分区：
fdisk /dev/sdc
然后按以下步骤操作（输入对应命令，回车执行）：
• n：新建分区• p：选择主分区• 分区号：默认 1（直接回车） • 起始扇区：默认（直接回车） • 结束扇区：默认（直接回车，用满整个磁盘） • w：保存分区表，退出 fdisk
1. 查看新分区：执行 fdisk -l /dev/sdc，会看到/dev/sdc1分区（500G）。
步骤 2：格式化分区（注意：格式化会清空数据，新磁盘无需担心）
因为原/data分区是 EXT4 文件系统，新分区也要格式化为 EXT4（如果是 XFS，用mkfs.xfs）：
mkfs.ext4 /dev/sdc1 # 格式化/dev/sdc1为EXT4
步骤 3：挂载新分区到现有目录（以 /data 为例）
如果直接挂载到/data，会覆盖原有数据，所以需要先把原有数据迁移到新分区：
1. 新建临时挂载点：
mkdir /mnt/new\_data
1. 挂载新分区到临时目录：
mount /dev/sdc1 /mnt/new\_data
1. 迁移 /data的原有数据到临时目录：
rsync -av /data/ /mnt/new\_data/ # -a保留权限，-v显示进度
1. 备份原有 /data目录（避免迁移失败）：
mv /data /data\_old
1. 新建 /data目录，重新挂载新分区到/data：
mkdir /data
umount /mnt/new\_data # 卸载临时挂载
mount /dev/sdc1 /data # 挂载到/data1. 验证挂载：执行 df -h /data，会看到/data大小变为 500G。2. 设置开机自动挂载：编辑 /etc/fstab，加入以下内容（避免重启后挂载失效）：
/dev/sdc1 /data ext4 defaults 0 0 # 设备路径 挂载点 文件系统 选项 dump fsck
1. 测试开机挂载：执行 mount -a，如果没有报错，说明配置没问题。
方案 2：LVM 逻辑卷扩容（适用于已配置 LVM 的服务器）
如果服务器的分区是用 LVM（逻辑卷管理）创建的（比如/dev/mapper/cl-data），扩容会更灵活，不需要迁移数据。LVM 的核心概念是：物理卷（PV）→ 卷组（VG）→ 逻辑卷（LV）→ 文件系统，扩容就是往卷组里加新物理卷，再扩展逻辑卷和文件系统。
以 CentOS 7 为例，原/data是 LVM 逻辑卷（/dev/cl/data），现在新增一块 500G 磁盘/dev/sdc，要扩容/data。
步骤 1：将新磁盘创建为物理卷（PV）
1. 查看现有 LVM 信息：
pvdisplay # 查看物理卷，会看到原有的PV（比如/dev/sdb1）
vgdisplay # 查看卷组，会看到卷组名（比如cl）和剩余空间
lvdisplay # 查看逻辑卷，会看到/data对应的LV（/dev/cl/data）1. 给新磁盘 /dev/sdc创建 PV：
pvcreate /dev/sdc # 直接用整个磁盘创建PV，也可以先分区再创建
1. 验证 PV 是否创建成功： pvdisplay /dev/sdc，会显示 PV 信息。
步骤 2：将新 PV 加入到现有卷组（VG）
假设原卷组名是cl（用vgdisplay查看），将/dev/sdc加入cl卷组：
vgextend cl /dev/sdc # 卷组名 新PV路径
验证卷组空间：vgdisplay cl，会看到Free PE / Size增加了 500G。
步骤 3：扩展逻辑卷（LV）
扩展/dev/cl/data逻辑卷，将卷组的所有空闲空间都分配给它：
lvextend -l +100%FREE /dev/cl/data # -l +100%FREE表示使用所有空闲空间
\# 如果只想分配200G，用-l +200G（注意单位是G，不是小写g）验证 LV 大小：lvdisplay /dev/cl/data，会看到LV Size增加了 500G。
步骤 4：扩展文件系统（关键！否则空间不显示）
LVM 扩展后，文件系统还没识别到新空间，需要扩展文件系统。根据文件系统类型不同，命令不同：
• 如果是 EXT4（用 df -hT查看）：
resize2fs /dev/cl/data # 扩展EXT4文件系统
• 如果是 XFS（CentOS 7 默认文件系统）：
xfs\_growfs /data # XFS需要指定挂载点，不是LV路径
验证扩容：df -h /data，会看到/data大小已经增加。
方案 3：云盘扩容（适用于阿里云、腾讯云、AWS 等云服务器）
云服务器的磁盘扩容最方便，不需要物理操作，直接在云控制台扩容，再在服务器内扩展文件系统即可。以阿里云 ECS 为例，步骤如下：
步骤 1：在云控制台扩容云盘（注意：需要先停止实例，或选择 “在线扩容”）
1. 登录阿里云 ECS 控制台，进入 “实例” 页面，找到需要扩容的实例。 2. 点击实例名称，进入 “存储”→“云盘” 页面，找到需要扩容的云盘（比如 /dev/vda）。3. 点击 “扩容”，选择扩容后的大小（比如从 40G 扩容到 100G），支付费用后，等待扩容完成（一般 1-2 分钟）。 4. 扩容完成后，启动实例（如果之前停止了）。
步骤 2：在服务器内扩展分区和文件系统
云控制台扩容后，服务器内看到的磁盘大小已经增加（用fdisk -l /dev/vda查看，会看到/dev/vda已经是 100G），但分区大小还没变化（比如/dev/vda3还是 40G），需要扩展分区和文件系统。
以/dev/vda3（挂载到/var）为例，EXT4 文件系统：
1. 查看分区信息： fdisk -l /dev/vda，会看到/dev/vda3的大小还是 40G，后面有未分配空间。2. 扩展分区：用 growpart命令（阿里云默认安装，没有的话装yum install cloud-utils-growpart -y）：
growpart /dev/vda 3 # 扩展/dev/vda的第3个分区（注意中间有空格）
1. 验证分区大小： fdisk -l /dev/vda3，会看到/dev/vda3已经是 100G。2. 扩展文件系统：
resize2fs /dev/vda3 # EXT4文件系统
\# 如果是XFS，用xfs\_growfs /var（挂载点）1. 验证扩容： df -h /var，会看到/var大小变为 100G。
四、运维避坑指南：这 5 个错误千万别犯！
在磁盘清理和扩容过程中，我见过很多新手踩坑，导致数据丢失或服务宕机，这里总结 5 个高频错误，帮你避开：
1. 直接 rm 删除正在被占用的日志文件
错误操作：rm -rf /var/log/nginx-access.log（日志正在被 Nginx 写入）
后果：磁盘空间不释放，因为进程还持有文件句柄，需要重启进程才能释放（但重启会影响服务）。
正确操作：用echo >或truncate截断文件，或者先配置 logrotate 再轮转。
2. 扩容前不备份数据
错误操作：直接给 LVM 或云盘扩容，不备份数据。
后果：如果扩容过程中出现断电、磁盘错误，可能导致数据损坏。
正确操作：扩容前用rsync备份关键数据（比如rsync -av /data /backup/data_bak），云服务器还可以创建快照。
3. 扩展 XFS 文件系统时用错命令
错误操作：resize2fs /dev/cl/data（XFS 文件系统用了 EXT4 的命令）
后果：报错 “Bad magic number in super-block”，文件系统可能损坏。
正确操作：XFS 必须用xfs_growfs 挂载点（比如xfs_growfs /data），且 XFS 只能扩容，不能收缩。
4. 误删系统关键日志
错误操作：rm -rf /var/log/messages（系统核心日志）
后果：系统出现问题时，无法通过日志排查原因，比如登录失败、服务启动失败。
正确操作：系统日志（messages、secure、journal/）只能截断，不能删除，建议配置 logrotate 保留至少 7 天。
5. 挂载时覆盖原有数据
错误操作：直接mount /dev/sdc1 /data（/data已有数据）
后果：原有数据被覆盖，只能通过数据恢复工具抢救（成功率低）。
正确操作：挂载新磁盘前，先把原有数据迁移到临时目录，再挂载到目标目录。
五、运维工具推荐：提高磁盘管理效率
除了命令行，这些工具能帮你更直观地管理磁盘，新手也能快速上手：
1. ncdu：可视化磁盘分析工具，用终端界面显示目录大小，支持交互操作（删除、导航），安装： yum install ncdu -y，使用：ncdu /var。2. gparted：图形化分区工具，适合不熟悉命令行的同学，支持 EXT4、XFS、NTFS 等文件系统，CentOS 安装： yum install gparted -y，Ubuntu：apt install gparted -y。3. Zabbix/Prometheus：磁盘监控工具，设置磁盘使用率告警阈值（比如 85% 警告，95% 紧急），提前预警，避免磁盘满了才发现。 4. logwatch：日志分析工具，每天生成日志摘要报告（比如登录失败次数、服务错误次数），安装： yum install logwatch -y，配置：vi /etc/logwatch/conf/logwatch.conf。
总结：磁盘满了不可怕，按流程操作即可
服务器磁盘满的处理流程可以总结为：先诊断（df→du→ls 定位问题）→ 再清理（3 步清理无效日志 + 配置长效防护）→ 最后扩容（根据存储类型选方案） 。
关键是不要慌，盲目删文件只会导致更严重的问题。记住：80% 的磁盘满是日志问题，清理后就能解决；20% 需要扩容的场景，只要按步骤操作，做好备份，就能安全完成。
最后，建议定期（比如每周）检查磁盘使用情况，配置监控告警，把问题扼杀在萌芽状态 —— 运维的核心不是解决问题，而是避免问题发生。