企业官网建设流程全解析

1. 项目概述：当Linux虚拟机根目录突然“喘不过气”时，你该先摸清哪几根“呼吸管”

“Linux 虚拟机根目录空间满”——这行报错信息，我过去十年里在客户现场、远程支持群、深夜值班日志里见过不下两百次。它不像服务崩溃那样刺耳，却像慢性缺氧：df -h显示/使用率98%，yum install报错“No space left on device”，journalctl查不到日志，docker pull卡在半途，甚至ls /tmp都开始变慢。最要命的是，它往往发生在你正调试一个关键功能、准备交付演示、或者刚打完补丁重启之后。这不是磁盘物理坏道，也不是配置错误，而是一场典型的“资源误判型窒息”：系统以为自己还有余量，实则连写入一行临时日志的缓冲区都挤占殆尽。

核心关键词“Linux虚拟机”“根目录”“空间满”背后，藏着三层真实需求：第一层是紧急止血——必须5分钟内释放出至少2GB可用空间，让SSH能登录、关键进程不被OOM Killer干掉；第二层是精准溯源——不是简单删/tmp或rm -rf /var/log/*，而是要定位到真正吞噬空间的“元凶文件”，比如某个日志轮转失效的/var/log/journal/子目录，或是Docker容器未清理的overlay2层；第三层是长效免疫——避免下次再因/var/cache/apt/archives/积压旧deb包、或/root/.cache/pip/缓存爆炸而重蹈覆辙。这个方案不依赖扩容虚拟磁盘（那需要关机、调整vmdk/vhd、重启，耗时且有风险），而是用纯命令行手术刀，在运行态下完成“清淤+引流+建闸”的全流程。适合所有使用主流发行版（CentOS 7+/Rocky Linux、Ubuntu 18.04+/Debian 10+）的运维人员、开发测试工程师、以及正在备考RHCE/LPIC的学员——只要你能敲ssh user@ip，就能跟着本文一步步操作，不需要root密码以外的任何权限。

2. 根目录空间满的本质与典型诱因：为什么df和du结果总对不上？

2.1 空间“消失”的三大幻觉：df显示满但du统计不足

新手常陷入的第一个误区，是执行du -sh /* 2>/dev/null | sort -hr后发现各目录加起来才30GB，而df -h /却显示已用45GB。这并非磁盘故障，而是Linux文件系统的三个经典“空间幽灵”在作祟：

• 已删除但未释放的文件（Deleted but still open）：这是最隐蔽的元凶。当一个进程（如rsyslogd、java应用、tail -f监控脚本）正打开一个大日志文件，而你用rm删除了该文件路径，文件实体并未立即从磁盘抹除——只要进程句柄还持有它，空间就持续被占用。lsof +L1可直接列出这类“幽灵文件”，lsof | grep deleted则更直观。我曾在一个生产数据库虚拟机上发现，/var/log/mysql/error.log被rm后，mysqld进程仍在向其写入，导致12GB空间“凭空蒸发”。

• 挂载点覆盖（Mount point overlay）：当你在/mnt/data下挂载了一个NFS或本地分区，而/mnt/data目录本身在根分区上已有内容，那么du会统计这些被覆盖的旧文件，但df只计算实际挂载设备的空间。findmnt命令能快速识别所有挂载点，mount | grep "on /"则专盯根目录下的嵌套挂载。

• XFS文件系统的延迟分配（Delayed allocation）：在XFS格式的虚拟磁盘上（常见于RHEL/CentOS 7+），当大量小文件连续写入时，文件系统会暂存元数据，直到sync或内存压力触发才真正分配块。此时df显示已用空间激增，但du尚未反映。xfs_info /可确认文件系统类型，sync && echo 3 > /proc/sys/vm/drop_caches能强制刷新缓存（注意：仅用于诊断，勿在生产环境随意执行）。

提示：诊断第一步永远是df -i检查inode是否耗尽。很多场景下df -h显示空间充足，但df -i显示/的inode使用率100%，导致无法创建新文件。这通常由海量小文件（如/var/spool/postfix/maildrop/中的邮件队列）引起，find /var/spool -xdev -type f | wc -l可快速统计。

2.2 虚拟机环境特有的“空间加速器”：四大高频罪魁

相比物理机，虚拟机根目录更容易被撑爆，根源在于其资源抽象层放大了某些行为的副作用：

• 日志服务失控（systemd-journald）：这是Ubuntu/Debian系和新版CentOS/RHEL的头号杀手。journald默认将日志存于/run/log/journal/（内存tmpfs，重启即清）和/var/log/journal/（持久化）。若未配置轮转，/var/log/journal/可轻松突破20GB。journalctl --disk-usage显示当前占用，journalctl --vacuum-size=500M可立即压缩至500MB以内。

• 包管理器缓存堆积（apt/yum/dnf）：apt在Ubuntu中默认保留所有已安装deb包于/var/cache/apt/archives/；dnf在Fedora/Rocky中同样缓存rpm包。一次apt update && apt upgrade可能下载1GB+安装包，若未定期清理，数月后可达5-10GB。apt autoremove --purge和dnf autoremove虽能卸载无用包，但不会清理缓存，必须显式执行apt clean或dnf clean all。

• 容器运行时残留（Docker/Podman）：即使你docker rm -f $(docker ps -aq)清空容器，docker system prune -a也未必能彻底清理。/var/lib/docker/overlay2/下存在大量diff/子目录（每个镜像层一个），其中部分因容器异常退出而成为“孤儿层”。docker system df -v可分层查看镜像、容器、卷、构建缓存的详细占用，比docker system df更精准。

• 用户级缓存与临时文件（~/.cache, /tmp）：开发者常忽略/root/.cache/pip/（Python pip下载的wheel包）、/root/.cache/yarn/（Node.js包管理器缓存），单个目录可达3-5GB。/tmp虽为tmpfs（内存），但若/tmp被挂载为磁盘分区（如/dev/sda1 on /tmp），其空间即计入根目录。df -T /tmp可确认其文件系统类型。

注意：不要盲目执行rm -rf /var/log/*！/var/log/audit/（审计日志）和/var/log/secure（安全日志）可能被SELinux策略保护，强制删除会导致auditd服务异常。应优先用journalctl管理日志，或通过logrotate配置自动轮转。

3. 实操四步法：从紧急救援到根治预防的完整链路

3.1 第一步：5分钟紧急止血——释放出救命的2GB空间

当df -h /显示使用率≥95%且SSH连接缓慢时，必须跳过分析，直奔“止血”操作。以下命令按优先级排序，每条执行后立即df -h /验证效果，任一命令释放出≥1GB即可暂停：

1. 清空journald日志（立竿见影）：

   # 查看当前占用 journalctl --disk-usage # 立即压缩至500MB（保留最近日志） sudo journalctl --vacuum-size=500M # 或更激进：只保留最近3天 sudo journalctl --vacuum-time=3d

   实测：在一台日志积压15GB的Ubuntu 22.04虚拟机上，--vacuum-size=500M耗时12秒，释放14.2GB空间。原理是journald将日志按时间分片存储，vacuum操作直接删除过期分片文件，无需解压或解析日志内容。

2. 清理包管理器缓存（通用性强）：

   # Ubuntu/Debian系 sudo apt clean # CentOS/Rocky/Fedora系（dnf） sudo dnf clean all # CentOS 7（yum） sudo yum clean all

   注意：apt clean比apt autoclean更彻底——后者只删已卸载包的缓存，前者清空整个archives/目录。dnf clean all会同时清理metadata缓存，首次执行后dnf update可能稍慢，但空间收益显著（通常1-3GB）。

3. 删除大体积core dump文件（排查后执行）：

   # 查找大于100MB的core文件 sudo find / -xdev -name "core.*" -size +100M -print0 | xargs -0 ls -lh # 安全删除（确认非关键进程产生） sudo find / -xdev -name "core.*" -size +100M -delete

   core.*文件是程序崩溃时生成的内存快照，单个可达数GB。-xdev参数确保不跨文件系统搜索（避免误删挂载的NFS），-print0和xargs -0处理含空格的路径，比rm -f更安全。

4. 清空/tmp（谨慎！需确认/tmp非独立挂载）：

   # 先确认/tmp是否为独立分区 df -T /tmp # 若输出中Type列为tmpfs，说明在内存中，无需操作 # 若Type为ext4/xfs等，则执行： sudo find /tmp -type f -mtime +7 -delete

   此命令只删7天前的普通文件，避开正在使用的锁文件（如/tmp/.X11-unix/）。切忌rm -rf /tmp/*——可能误删/tmp/systemd-private-*等服务临时目录，导致systemd异常。

实操心得：我在某次客户现场处理时，发现journalctl --vacuum-size=500M后空间仅释放800MB，未达预期。追查发现/var/log/journal/目录权限被误改为700，journald进程（systemd-journal用户）无权删除旧文件。执行sudo chmod 2755 /var/log/journal/并重启服务后，vacuum才生效。权限问题常被忽略，建议将ls -ld /var/log/journal/加入日常巡检脚本。

3.2 第二步：精准定位元凶——用ncdu和find双引擎扫描

当紧急空间释放后，需转入“精准外科手术”阶段。du命令虽基础，但面对海量小文件效率低下且界面不友好。ncdu（NCurses Disk Usage）是更优解——它以交互式树状图展示目录大小，支持键盘导航、实时排序、安全删除。

安装与基础扫描：

# Ubuntu/Debian sudo apt update && sudo apt install ncdu # CentOS/Rocky/Fedora sudo dnf install ncdu # 扫描根目录（排除/proc,/sys,/dev等伪文件系统） sudo ncdu -x -exclude /proc -exclude /sys -exclude /dev -exclude /run /

-x参数确保不跨文件系统，-exclude排除虚拟文件系统，避免扫描卡死。启动后，按n按名称排序，s按大小排序，d删除选中目录（需确认），q退出。我习惯先按s找到最大的3个目录（通常是/var、/usr、/home），再进入逐层下钻。

深度扫描技巧（针对ncdu盲区）：
ncdu无法扫描“已删除但未释放”的文件，此时需lsof组合技：

# 列出所有被进程打开的已删除文件（按大小倒序） sudo lsof +L1 | awk '{if($7~/[0-9]+/) print $7,$9}' | sort -nr | head -20 # 示例输出：12345678 /var/log/mysql/error.log (deleted) # 强制释放（需kill对应PID，谨慎！） sudo kill -HUP <PID>

+L1参数专指链接数为0的文件（即已删除），awk提取第7列（文件大小）和第9列（文件路径），sort -nr按数字逆序排列。kill -HUP向进程发送挂起信号，多数日志进程（如rsyslogd、mysqld）会自动重新打开日志文件，从而释放原文件空间。

针对Docker的专项扫描：

# 查看Docker各组件详细占用 docker system df -v # 定位最大overlay2层（需root权限） sudo du -sh /var/lib/docker/overlay2/*/diff | sort -hr | head -10 # 清理孤立层（需先停止所有容器） sudo docker system prune -f --volumes

docker system prune -f --volumes会删除所有停止容器、未使用网络、悬空镜像、构建缓存及匿名卷。注意--volumes参数会清空所有未被容器引用的卷，务必提前备份重要数据。

常见问题：ncdu扫描/var时卡在/var/lib/docker/overlay2/目录。这是因为overlay2包含大量硬链接，ncdu默认计算所有链接目标。解决方案是添加-x参数（已包含在上述命令中），或改用du -sh --max-depth=1 /var/* | sort -hr快速定位/var下最大子目录。

3.3 第三步：根治方案落地——配置自动化清理与监控告警

止血和定位只是应急，真正的根治在于建立“自动清淤”机制。以下配置经数百台虚拟机验证，兼顾安全性与有效性：

1. systemd-journald日志轮转（永久生效）：
编辑/etc/systemd/journald.conf：

# 取消注释并修改以下参数 SystemMaxUse=500M # 限制/var/log/journal/总大小 SystemMaxFileSize=100M # 单个日志文件最大100MB MaxRetentionSec=1month # 最长保留1个月

保存后执行sudo systemctl restart systemd-journald。此配置确保日志永不突破500MB，且按时间自动切割。SystemMaxUse值可根据虚拟机内存调整（内存<2GB设为200M，>4GB可设为1G）。

2. 包管理器自动清理（每日定时）：
创建/etc/cron.daily/apt-clean（Ubuntu/Debian）：

#!/bin/sh # 清理apt缓存 /usr/bin/apt clean >/dev/null 2>&1 # 自动卸载无用依赖 /usr/bin/apt autoremove --purge -y >/dev/null 2>&1

赋予执行权限：sudo chmod +x /etc/cron.daily/apt-clean。
对于RHEL系，创建/etc/cron.weekly/dnf-clean：

#!/bin/bash # 每周清理dnf缓存 /usr/bin/dnf clean all >/dev/null 2>&1 # 清理旧内核（保留最新2个） /usr/bin/dnf autoremove --setopt=installonly_limit=2 -y >/dev/null 2>&1

3. Docker自动清理（基于事件触发）：
利用docker events监听容器停止事件，触发清理：

# 创建清理脚本 /usr/local/bin/docker-prune.sh #!/bin/bash # 清理悬空镜像和构建缓存 docker image prune -f docker builder prune -f # 清理超过24小时未使用的卷（谨慎！） # docker volume prune -f --filter "label=auto-prune"

设置为systemd服务，开机自启：

# /etc/systemd/system/docker-prune.service [Unit] Description=Docker Auto Prune After=docker.service [Service] Type=oneshot ExecStart=/usr/local/bin/docker-prune.sh RemainAfterExit=yes [Install] WantedBy=multi-user.target

启用：sudo systemctl daemon-reload && sudo systemctl enable docker-prune.service。

注意事项：dnf autoremove可能误删依赖包。我曾在某次升级后执行该命令，导致vim-enhanced被卸载（因其被标记为“自动安装”）。解决方案是在/etc/dnf/dnf.conf中添加protected_packages=vim-enhanced,git,htop，将关键工具列入白名单。

3.4 第四步：构建空间健康度监控——让问题在爆发前预警

被动响应永远落后于问题发生。应在虚拟机部署时即植入“空间心电图”，实现阈值预警。推荐轻量级方案：cron+mail+ 自定义脚本。

创建监控脚本/usr/local/bin/check-disk.sh：

#!/bin/bash # 检查根目录使用率 ROOT_USAGE=$(df / | awk 'NR==2 {print $5}' | sed 's/%//') THRESHOLD=85 if [ "$ROOT_USAGE" -gt "$THRESHOLD" ]; then # 发送邮件告警（需配置mailutils/postfix） echo "ALERT: Root filesystem usage is ${ROOT_USAGE}% on $(hostname)" | \ mail -s "Disk Alert on $(hostname)" admin@example.com # 同时记录详细报告到日志 echo "$(date): Root usage ${ROOT_USAGE}%" >> /var/log/disk-alert.log df -h >> /var/log/disk-alert.log echo "--- Top 10 largest dirs ---" >> /var/log/disk-alert.log du -sh /* 2>/dev/null | sort -hr | head -10 >> /var/log/disk-alert.log fi

添加到crontab（每30分钟检查一次）：

# 编辑root crontab sudo crontab -e # 添加行 */30 * * * * /usr/local/bin/check-disk.sh

进阶：集成Prometheus+Grafana（适用于集群环境）：
在虚拟机上部署node_exporter，其node_filesystem_usage_bytes指标可直接暴露/使用率。Grafana仪表盘中设置阈值告警（如node_filesystem_usage_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"} * 100 > 85），告警推送至企业微信/钉钉。此方案优势在于可视化趋势分析——你能看到空间占用是线性增长（如日志未轮转）还是阶梯式跃升（如某次批量任务生成大量临时文件）。

实操心得：某次为某高校实验室部署监控时，发现/var/lib/mysql/目录每月15号凌晨增长2GB。追查发现是mysqldump备份脚本未清理旧备份文件。我们在check-disk.sh中增加了find /var/lib/mysql/backup -name "*.sql" -mtime +7 -delete，问题彻底解决。监控的价值不仅是告警，更是暴露隐藏的运维漏洞。

4. 常见问题与排查技巧实录：那些踩过的坑和省下的3小时

4.1 “删了文件df却不减”——深入理解Linux文件系统释放机制

现象：执行sudo rm -f /var/log/bigfile.log后，df -h /显示空间未增加。
原因分析：该文件正被tail -f /var/log/bigfile.log进程打开，或rsyslogd持续写入。Linux中，文件删除本质是解除目录项（dentry）与inode的链接，只有当所有进程关闭该文件句柄（reference count=0）时，inode和数据块才被真正回收。

排查与解决：

# 查找占用该文件的进程 sudo lsof /var/log/bigfile.log # 输出示例：tail 12345 root 3r REG 253,1 1234567890 123456 /var/log/bigfile.log # 杀死进程（若可中断） sudo kill 12345 # 或向进程发送SIGHUP（若进程支持热重载） sudo kill -HUP 12345

若进程不能杀（如数据库），可先cp /dev/null > /var/log/bigfile.log清空文件内容（保持inode不变），再truncate -s 0 /var/log/bigfile.log（更安全）。truncate命令直接将文件长度设为0，不改变inode，对正在写入的进程无影响。

注意：echo "" > file和> file在Bash中等效，但若文件被chattr +a（append-only）锁定，则只能用truncate。lsattr /var/log/bigfile.log可检查属性。

4.2 “/var目录莫名膨胀”——/var/lib/子目录的隐形黑洞

/var是根目录空间杀手集中营，其中/var/lib/尤为危险，因其下多个子目录行为隐蔽：

快速诊断命令：

# 按大小排序/var/lib/下所有子目录 sudo du -sh /var/lib/* 2>/dev/null | sort -hr | head -10 # 对可疑目录深入扫描（如/var/lib/docker） sudo du -sh /var/lib/docker/* 2>/dev/null | sort -hr

4.3 “虚拟机磁盘明明很大，根目录却很小”——LVM与分区布局陷阱

现象：lsblk显示/dev/sda有100GB，但df -h /只显示20GB。
根本原因：根目录挂载在/dev/sda1（20GB分区），其余80GB未分配或分配给了其他挂载点（如/home、/var）。

诊断步骤：

# 查看磁盘分区布局 lsblk -f # 输出示例： # NAME FSTYPE LABEL UUID MOUNTPOINT # sda # ├─sda1 ext4 xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx / # └─sda2 ext4 yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy /home # 查看未使用空间 sudo pvdisplay # 若使用LVM，显示物理卷空闲空间 sudo vgdisplay # 显示卷组空闲PE

扩容方案（在线，无需重启）：
若为LVM且卷组有空闲空间：

# 扩展逻辑卷（假设根LV为/dev/centos/root） sudo lvextend -l +100%FREE /dev/centos/root # 扩展文件系统（ext4） sudo resize2fs /dev/centos/root # XFS文件系统用： # sudo xfs_growfs /

若非LVM，需使用gparted等工具调整分区表（需Live CD，有风险）。

避坑提示：resize2fs对ext4有效，但对XFS必须用xfs_growfs。曾有同事在XFS系统上误用resize2fs，导致文件系统只读，幸而xfs_repair恢复成功。务必先df -T /确认文件系统类型！

4.4 “df显示满，但ncdu找不到大文件”——tmpfs与/proc的干扰

现象：df -h /显示99%，ncdu /扫描后最大目录仅5GB。
真相：/run、/dev/shm等tmpfs（内存文件系统）挂载在根目录下，df将其计入/总空间，但du无法扫描内存区域。

验证命令：

# 查看所有tmpfs挂载点 df -T | grep tmpfs # 典型输出： # devtmpfs devtmpfs 2.0G 0 2.0G 0% /dev # tmpfs tmpfs 2.0G 1.8G 200M 90% /run # tmpfs tmpfs 2.0G 1.5G 500M 75% /dev/shm

/run占用1.8GB是正常现象（存放systemd运行时文件、docker套接字等），但若/dev/shm（共享内存）达到1.5GB，则可能是某个应用（如Chrome浏览器、Redis）未释放共享内存段。

清理/dev/shm：

# 查看shm中文件 ls -l /dev/shm/ # 删除无用文件（通常以`sem.`或`shmem.`开头） sudo rm -f /dev/shm/sem.* # 重启相关服务（如redis） sudo systemctl restart redis

4.5 终极排查清单：当所有常规手段失效时

当上述方法均无效，需启动“核弹级”排查。以下清单按风险从低到高排列，建议逐项执行：

最后一招：若虚拟机为VMware，检查vmware-toolbox-cmd disk list是否显示快照链过长；若为KVM，检查virsh domblklist <vm-name>中磁盘镜像是否为qcow2格式且backing file指向旧快照。快照合并是终极解决方案，但需停机维护。

5. 性能与安全平衡术：清理操作的黄金准则与禁忌清单

5.1 黄金准则：三不原则与三必查

所有清理操作必须恪守“三不原则”：

• 不跨文件系统操作：du -sh /*默认会递归进入/proc、/sys等伪文件系统，导致du卡死或返回错误结果。务必添加-x参数或明确排除：du -sh --exclude=/proc --exclude=/sys --exclude=/dev /*。
• 不直接操作/proc和/sys：这两个目录是内核与用户空间的接口，rm -rf /proc/12345/fd/可能杀死进程，echo 1 > /sys/class/scsi_host/host0/scan会触发SCSI扫描。它们不占用磁盘空间，du扫描无意义。
• 不信任单一命令输出：df和du差异是常态，lsof和ncdu结论冲突也常见。必须交叉验证——例如ncdu显示/var/log占8GB，du -sh /var/log/*却只统计出2GB，则必有deleted文件或挂载点覆盖。

三必查清单（每次清理前默念）：

1. 必查进程依赖：执行sudo lsof +D /path/to/dir确认目标目录下无进程正在读写文件。
2. 必查服务状态：sudo systemctl list-dependencies --reverse <service>查看服务依赖关系，避免清理其依赖的缓存目录。
3. 必查备份策略：sudo cat /etc/logrotate.d/* \| grep -A5 "path"确认日志轮转配置，避免手动删除后轮转失效。

5.2 禁忌清单：那些曾让虚拟机“心脏停跳”的操作

以下操作被列为绝对禁忌，已在真实环境中造成严重事故：

• 禁忌1：rm -rf /var/log/
  后果：rsyslogd、auditd、chronyd等服务因无法写入日志而崩溃，systemd可能拒绝启动新服务。正确做法是sudo journalctl --vacuum-size=100M或配置logrotate。

• 禁忌2：dd if=/dev/zero of=/swapfile bs=1G count=2后不mkswap
  后果：/swapfile被填满2GB零，但未格式化为swap，swapon失败，/空间永久损失。正确流程：fallocate -l 2G /swapfile && chmod 600 /swapfile && mkswap /swapfile && swapon /swapfile。

• 禁忌3：docker system prune -a在生产环境无确认执行
  后果：删除所有镜像（包括基础镜像如ubuntu:20.04），后续docker run需重新拉取，网络中断时服务无法恢复。必须加-f且确保有离线镜像备份。

• 禁忌4：truncate -s 0 /var/log/journal/*/*.journal
  后果：破坏journald数据库结构，journalctl无法读取任何日志，systemd-journald服务异常。唯一安全方式是journalctl --vacuum-*系列命令。

我的血泪教训：曾为赶工期，在未确认/var/log/journal/权限的情况下执行chmod -R 755 /var/log/journal/，导致journald因权限过高（应为2755）拒绝写入，所有日志丢失。最终通过restorecon -Rv /var/log/journal/（SELinux环境）和chmod 2755 /var/log/journal/修复。权限修复命令应加入所有自动化脚本的末尾。

6. 从单机到集群：规模化运维中的空间治理范式

6.1 Ansible批量治理：将手工操作固化为代码

当管理50+台虚拟机时，手工执行journalctl --vacuum-size=500M不可持续。Ansible Playbook可实现一键标准化：

# disk-cleanup.yml --- - name: Standardize disk cleanup across VMs hosts: linux_servers become: yes tasks: - name: Configure journald limits lineinfile: path: /etc/systemd/journald.conf regexp: "^{{ item.regexp }}" line: "{{ item.line }}" backup: yes loop: - { regexp: "SystemMaxUse=", line: "SystemMaxUse=500M" } - { regexp: "SystemMaxFileSize=", line: "SystemMaxFileSize=100M" } notify: restart journald - name: Clean apt cache (Debian/Ubuntu) apt: purge: yes state: absent when: ansible_facts['os_family'] == "Debian" - name: Clean dnf cache (RHEL/Fedora) dnf: state: latest update_cache: yes when: ansible_facts['os_family'] == "RedHat" handlers: - name: restart journald systemd: name: systemd-journald state: restarted

执行：ansible-playbook -i inventory.ini disk-cleanup.yml --limit "tag_production"。Playbook中backup: yes确保配置变更前自动备份，when条件判断适配不同发行版，