Linux运维常用脚本实战：巡检、日志清理与备份

简介：Shell脚本是自动化运维的基石，通过封装高频命令，能将系统巡检、日志清理和数据备份从重复劳动变成标准化操作。日常运维中，磁盘使用率告警、进程异常、日志膨胀等问题频发，手动执行free、df、pgrep不仅效率低，还容易遗漏关键指标。而合理设计的巡检脚本可以一次性采集CPU、内存、磁盘和进程状态，并输出带阈值的结论区，让管理员一眼定位风险。日志清理看似简单，直接find删除却可能误删正在写入的文件或触发空间不释放问题，配合dry-run与lsof检查才能真正安全落地。备份脚本同样需要兼顾全量策略、压缩验证与轮替保留，并定期演练恢复流程。借助cron定时任务、shellcheck静态检查以及bash -n语法校验，运维脚本才能从临时工具升级为可靠的生产保障。本文以可复用的脚本示例，梳理这些核心场景的实践要点。

1. 一套Linux运维常用脚本到底能省多少事

凌晨两点被工单叫醒，登录服务器看到磁盘使用率95%，日志把分区写满，应用反复重启——这种场景在运维手里基本是“家常便饭”。真正让人崩溃的不是问题本身，而是同样的检查命令每周要重复几十次：free、df、pgrep、tail，每台机器都来一遍，赶上批量操作就变成纯体力活。所谓 Linux运维常用脚本，就是把这类高频动作固化成标准输出：巡检、日志清理、备份、账号检查，每条命令都带明确阈值和退出码，能跑在三五十台机器上也心里有底。适合刚接手的运维新人，也适合要维护多台服务器却懒得半夜翻命令历史的开发者。它不是万能的监控系统，却是能让你少踩一半坑的“工具底稿”。

2. 先把日常巡检脚本立住：CPU、内存、磁盘、进程一次拉全

2.1 巡检脚本示例：一台机器两分钟出体检报告

巡检这种事最容易被“手动习惯”糊弄过去。今天敲一下free，明天看一眼df -h，后天发现昨天那台机器内存已经红了，却没人记得它是什么时候红的。我一般会先写一个sys_check.sh，把固定检查项一次性输出到终端，同时落一份带时间戳的日志。常见做法是从/proc目录拿数据和用系统命令两个路子结合，尽量避免解析那些不同发行版输出格式差异很大的命令。

#!/usr/bin/env bash # sys_check.sh：基础巡检脚本 # 用法：bash sys_check.sh [输出目录] # 默认输出到 /tmp/sys_check，文件名带主机名和时间戳 LOG_DIR="${1:-/tmp/sys_check}" LOG_FILE="${LOG_DIR}/sys_$(hostname)_$(date +%Y%m%d_%H%M%S).log" mkdir -p "${LOG_DIR}" { echo "======== 系统时间 ========" date '+%Y-%m-%d %H:%M:%S %Z' echo "======== 运行时长 / 负载 ========" uptime -s cat /proc/loadavg echo "======== 内存(MB) ========" free -m echo "======== 磁盘 ========" df -hT echo "======== 关键进程 ========" for proc_name in nginx mysqld redis-server; do if pgrep -f "${proc_name}" >/dev/null 2>&1; then echo "${proc_name}: 运行中" else echo "${proc_name}: 未运行" fi done } | tee "${LOG_FILE}" echo "巡检报告：${LOG_FILE}" exit 0

这段脚本的逻辑很简单：先定义一个日志目录，默认在/tmp/sys_check下，不会污染业务目录。然后把需要的信息用块结构包起来，一次执行完，再用tee同时输出到屏幕和文件，方便事后翻历史记录。参数部分，$1是输出目录，后续如果想加阈值判断，直接在这个块结构里追加就行。

有个细节要注意：uptime -s这个参数不是所有Linux版本都支持。我在老系统上遇到过它直接报错的情况，这时可以降级用/proc/uptime换算：

awk '{printf "启动时间: %.2f天\n", $1/86400}' /proc/uptime

这套写法适合绝大多数CentOS 7以上和常见Debian系发行版。如果机器上是裁剪过的嵌入式系统，free -m的输出列序可能不一样，建议先手动跑一下free -m确认列索引再决定awk怎么取。

2.2 把输出做成“一眼能看懂”的格式

裸输出只能算“把信息堆在一起”，离“排查报告”还差一步。我习惯在巡检脚本里加一个整体结论区，比如内存使用率超过90%直接打告警标记，磁盘超过85%提示该清理了。这样登录上去不用一行行读数字，扫一眼结论区就知道要不要处理。

# 内存使用率判断，free -m 第一行配 available 列 total=$(free -m | awk '/^Mem:/{print $2}') available=$(free -m | awk '/^Mem:/{print $7}') if [ -n "${available}" ] && [ "${total}" -gt 0 ]; then mem_usage=$(( (total - available) * 100 / total )) echo "内存使用率: ${mem_usage}%" if [ "${mem_usage}" -ge 90 ]; then echo "内存告警: 使用率超过90%，请检查是否有进程泄漏" fi fi

这段代码用available列而不是简单的used列，是因为新版free命令里used包含缓存，直接用used算出来的使用率会虚高，看起来永远快满，实际业务却正常。available列才是真正可分配给新进程的内存。如果机器上的free没有available列，通常说明版本太老，脚本会跳过判断而不是误报，这也是我给脚本加空值校验的原因。

2.3 批量执行的两种方式：for循环与日志回收

巡检脚本在一台机器上写得再好，也要能推得出去才算数。最直接的办法是用ssh在for循环里逐台跑：

for host in 192.0.2.10 192.0.2.11 192.0.2.12; do ssh -o BatchMode=yes -o ConnectTimeout=5 "${host}" \ "bash -s" < ./sys_check.sh /var/log/sys_check done

这里的BatchMode=yes很关键，它让ssh在密钥不可用时直接失败而不是卡在密码提示上，适合无人值守批量执行。ConnectTimeout限制每台连接时长，避免某台机器网络不通拖死整个循环。跑完后每台机器的报告都会落在各自机器的/var/log/sys_check目录下，文件名里带主机名，收集的时候按hostname归档就行。

如果机器数量到几十台，for循环串行执行会比较慢，可以改成后台加等待：

for host in "${hosts[@]}"; do ssh -o BatchMode=yes "${host}" "bash -s" < ./sys_check.sh /var/log/sys_check & done wait

这样所有ssh会话并行发起，整体时间大幅缩短。注意任务并发后，输出会交织在一起，所以脚本必须落文件，不能只依赖终端输出。

2.4 阈值怎么定：先观察再设告警

阈值写进脚本前，先想明白一个问题：你这台机器是扛业务的还是只做日志中转的？两者阈值完全不同。我一般先裸跑一周原始输出，把负载基线摸清楚，再给具体指标设阈值。下表是我个人常用的初始值，适合多数中小业务，不代表所有场景都该照抄：

设定阈值的原则是“先低后高”，宁可第一周多报几次警，也不要一开始把阈值拉太高，把真正的问题漏过去。报警是为了发现问题，不是为了让脚本显得勤快。

3. 日志清理最容易误删，用有策略的脚本替代裸find

3.1 裸find -delete的雷区

很多教程喜欢教一句find /var/log -type f -mtime +30 -delete，看着很爽，但生产环境里这是一条高危命令。第一个雷是符号链接：如果目录里有指向重要文件的软链，find -type l配合-delete会把软链本身删掉，甚至可能让你以为原始文件也没了。第二个雷是正在写入的日志：你删掉一个被服务进程打开的日志文件，磁盘空间并不会立即释放，因为进程还持有那个文件句柄，直到服务重启才真正收回空间，这中间磁盘使用率依然高得吓人。第三个雷是审计类日志，很多合规要求保留半年甚至更久，一刀切按天数删，真被问起来的时候档案已经没了。

所以我一般把“裸find -delete”当成反面教材，真正上线的清理脚本必须支持dry-run、跳过占用文件、保留策略可配。

3.2 cleanup_logs.sh：先打印再删除

写清理脚本要抱着一个心态：先让它“什么也不做”，再让它“做一点”。第一版脚本可以只有打印功能，确认列出的文件没问题，再切换成真删。

#!/usr/bin/env bash # cleanup_logs.sh：日志轮替清理脚本 # 用法：bash cleanup_logs.sh <日志目录> <保留天数> [匹配模式] [dry-run] # 第四个参数传1表示只打印不删除，传0表示真正执行删除 LOG_DIR="${1:?需要传入日志目录}" KEEP_DAYS="${2:-30}" PATTERN="${3:-*.log}" DRY_RUN="${4:-1}" find "${LOG_DIR}" -type f -name "${PATTERN}" -mtime "+${KEEP_DAYS}" -print0 | while IFS= read -r -d '' file; do if [ "${DRY_RUN}" = 1 ]; then echo "[待清理] ${file}" continue fi lsof "${file}" >/dev/null 2>&1 if [ $? -eq 0 ]; then echo "[跳过-仍被打开] ${file}" continue fi rm -f "${file}" echo "[已清理] ${file}" done

逻辑说明：先用find找出超过保留天数、符合后缀条件的文件，print0配合read -d ''是为了处理带空格的文件名，比传统的xargs字符串拆分安全。dry-run模式下只列出不删除，属于后悔药机制。真要删除时先用lsof判断文件是否正被进程打开，如果被占用就跳过，避免删了白删。

参数说明：第二个参数是保留天数，例如30代表清理30天前的文件。第三个参数是文件名匹配模式，默认*.log，如果日志是log.20250101这种格式，可以传app.log.*。第四个参数只删开关，默认1是dry-run，确认无误后传0才是真删。

3.3 正在写入的日志：rm还是truncate

清理日志时要区分两种状态：已经轮替掉的老文件和正在被进程写入的活跃文件。对活跃文件，rm之后进程仍然持有旧inode，空间不释放，服务重启前磁盘一直是满的。遇到这种场景，常见做法是truncate而不是删除：

truncate -s 0 /var/log/app/app.log

用truncate的好处是inode不变，服务进程无需感知，继续往同一个文件里写。缺点是这个文件以后会从0开始长，不会有历史内容。如果业务要求保留最近N行现场，那就别用truncate，而是先cp一份再truncate，或者干脆让应用自己配置日志轮替。

3.4 定时任务：手动执行正确不等于自动执行正确

清理脚本手动跑没问题，改到cron里又是另一回事。cron默认环境变量非常精简，PATH通常只包含/usr/bin和/bin，脚本里用到的lsof在/usr/sbin下，直接执行会报command not found。这是最常见的“手动正常定时不跑”原因。

我一般会在cron里这样写：

0 3 * * * cd /opt/ops-scripts && /usr/bin/env bash cleanup_logs.sh /var/log/app 30 'app.log.*' 1 >> /var/log/cleanup_dry.log 2>&1

注意这里先用1也就是dry-run跑几天，让系统积累一份“本来会被删掉的文件清单”。确认清单里没有重要文件后，再把1改成0，正式启用删除。cron里重定向到日志很重要，不然脚本报错时你会完全蒙在鼓里。

如果磁盘超过85%才触发清理，可以在删除前加一层保护：

df -P -B1G /var | awk 'NR==2 {gsub("%","",$5); if ($5>=85) print "磁盘告警: "$5"%"}'

意思是只有当分区使用率超过85%时才提示告警，防止日志还很充裕时脚本天天空转。

4. 备份脚本：先存得下，再考虑恢复

4.1 备份方案选型：全量、增量与保留份数

备份脚本不是越复杂越好，先想清楚三个问题：数据量多大、能接受丢失多少、恢复要多久。以目录备份为例，如果数据量在几十GB级别，全量压缩备份完全可行；到几百GB甚至上TB，全量每天跑会拖垮磁盘IO，就得考虑增量。

我给的脚本按全量+保留份数设计，原因是中小数据量场景下它最直观，恢复时只要解压一个文件，不用把几十个增量串起来，排障的时候少一步纠结。

4.2 backup_snapshot.sh：目录快照与轮替

#!/usr/bin/env bash # backup_snapshot.sh：目录快照备份，保留最近N份 # 用法：bash backup_snapshot.sh <源目录> <备份根目录> [保留份数] set -euo pipefail SRC_DIR="${1:?需要传入源目录}" BACKUP_ROOT="${2:?需要传入备份根目录}" KEEP="${3:-7}" STAMP="$(date +%Y%m%d_%H%M%S)" BACKUP_DIR="${BACKUP_ROOT}/${STAMP}" mkdir -p "${BACKUP_DIR}" tar --exclude='*.cache' --exclude='tmp' \ -czf "${BACKUP_DIR}/snapshot.tar.gz" \ -C "$(dirname "${SRC_DIR}")" "$(basename "${SRC_DIR}")" echo "备份完成: ${BACKUP_DIR}/snapshot.tar.gz" du -sh "${BACKUP_DIR}/snapshot.tar.gz" # 轮替：只保留最近 KEEP 份备份目录 mapfile -d '' -t backup_dirs < <( find "${BACKUP_ROOT}" -maxdepth 1 -type d -name '20*' -print0 | sort -z -r ) for ((i = KEEP; i < ${#backup_dirs[@]}; i++)); do rm -rf "${backup_dirs[$i]}" echo "[旧备份已清理] ${backup_dirs[$i]}" done

这段脚本里，set -euo pipefail是保护伞，遇到未定义变量或命令失败会立刻终止，避免带着错误继续往下跑。tar打包时用-C先切到源目录的父级，再用basename，这样打出来的压缩包里不会带一长串绝对路径，解压时直接落在当前目录下。exclude参数排除缓存和临时目录，是控制备份体积的常用手段。

轮替的逻辑是：先用find列出备份根目录下所有以20开头的目录，sort -z -r按文件名倒序，最新的排最前面，mapfile -d ''读到数组里。然后从第KEEP+1个开始逐个删除，这样永远保留最近7份。我习惯用时间戳目录名而不是固定文件名，因为恢复时可以按时间点挑，不会被覆盖。

4.3 数据库导出：单独账号、环境变量传密、压缩验证

目录快照能覆盖配置文件、代码包，数据库还得单独处理。我一般用一个只读权限的备份账号导出，账号权限尽量最小，不要拿root去跑定时备份，否则数据库泄露时连锁风险太大。

DB_NAME="${1:?需要传入数据库名}" MYSQL_PASS="${MYSQL_PASS:?请通过环境变量传入MYSQL_PASS}" mysqldump --single-transaction --routines --triggers \ -u backup_user -p"${MYSQL_PASS}" "${DB_NAME}" | gzip > "${BACKUP_DIR}/${DB_NAME}.sql.gz" gzip -t "${BACKUP_DIR}/${DB_NAME}.sql.gz" && echo "压缩包完整性校验通过"

mysqldump的--single-transaction参数很关键，它让导出过程基于InnoDB的一致性快照，不锁业务表；不加这个参数时，大表导出期间可能锁住正常读写。密码通过环境变量传入，而不是硬编码在脚本里，防止脚本本身变成泄露源。导出后用gzip -t验证压缩包头部和CRC，能确认文件没在写入过程中损坏，但它只校验gzip层，不校验SQL内容。

4.4 备份做完必须验证：没验证过的备份等于没有备份

备份脚本最大的骗局是前面跑得顺利，恢复时才发现压缩包是坏的，或者备份目录压根没写进去。我习惯在备份完成后追加两步验证：

# 1. 确认文件存在且体积大于某个最小值 if [ ! -s "${BACKUP_DIR}/snapshot.tar.gz" ]; then echo "备份文件为空，检查源目录或tar命令日志" exit 1 fi # 2. 列出压缩包里的核心目录，确认结构符合预期 tar -tzf "${BACKUP_DIR}/snapshot.tar.gz" | head -n 5

tar -tzf只读列出压缩包内容而不解压，几秒钟就能确认关键目录在不在包里。数据库备份则建议至少一个月做一次实际恢复演练，拿到一台空闲机器上导入，跑几条SELECT验证数据量对得上。这活儿看起来费时，但它是唯一能发现“备份逻辑本身写错”的手段。

5. 避坑：脚本改三版才明白的几个硬道理

5.1 空变量把目标目录删空了

现象：清理脚本执行后，A同学发现本来只该删临时日志，结果整个业务目录被删掉，好在恢复比较快没有造成灾难。 原因：脚本里写了rm -rf "$DIR"/，而$DIR在某种条件下是空值，命令实际变成rm -rf /，如果恰好没有保护，结果就是一场事故。 解决：永远在脚本开头加set -euo pipefail，并且在删除类命令前做显式判断：

set -euo pipefail if [ -n "${DIR:-}" ] && [ -d "${DIR}" ]; then rm -rf "${DIR}"/* else echo "DIR为空或目录不存在，拒绝删除" exit 1 fi

${DIR:-}的作用是即使DIR没定义，也不会触发set -u直接退出，而是返回空字符串参与判断。这段代码确保只有目录真实存在时才执行删除，不给任何模糊空间。凡是涉及rm -rf的脚本，都值得加这几行。

5.2 磁盘占用超过2GB后，数值判断反而“失真”

现象：磁盘明明用了896G，脚本却显示“磁盘健康”，但分区实际只剩不到10G空间。 原因：df -h输出的是人类可读格式，1G以上的值显示成896G，1T以上显示成1.1T，awk按字符串比较时把“896G”和阈值“85”比，结果永远是健康。 解决：用df -P -B1G固定输出块大小，让第五列的数字可以直接参与运算：

df -P -B1G | awk 'NR>1 {usage=$5; gsub("%","",usage); if (usage+0 > 85) print $6, "usage:" usage "%"}'

-B1G让所有容量按G为单位输出整数，小于1G的显示成0G，这个精度对阈值判断足够用。如果分区的量级到了几十T，建议改成-B1M，避免大数值在部分awk实现里出现精度问题。这是我在脚本踩坑记录里最常提到的一条，因为它不会报错，只是默默算错。

5.3 cron里脚本怎么都不执行，日志却一片空白

现象：手动执行cleanup_logs.sh一切正常，加入cron后没看到任何清理痕迹，日志文件也是空的。 原因：cron环境里PATH只有/usr/bin和/bin，脚本用到的命令可能装在/usr/sbin或/usr/local/bin下，直接报command not found。另外cron默认shell是/bin/sh，和你本地bash行为不一定一样。 解决：脚本首行固定写#!/usr/bin/env bash，cron里调用时用绝对路径，并重定向输出：

0 3 * * * cd /opt/ops-scripts && /usr/bin/env bash /opt/ops-scripts/cleanup_logs.sh /var/log/app 30 'app.log.*' 0 >> /var/log/cleanup.log 2>&1

重定向到日志文件是排查cron问题的第一步，没有日志就没有排查线索。如果需要环境变量，在cron命令行里显式定义，不要指望它读取你登录shell的配置。

5.4 pkill误杀：清理进程把脚本自己干掉了

现象：执行“清理残留worker进程”的脚本后，脚本本身消失，后续步骤全部没跑。 原因：脚本内部用了pkill -f "my_worker"，而脚本命令行本身包含my_worker这个字符串，pkill把自己的父进程或自己匹配杀掉了。 解决：先用pgrep列出精确PID列表，过滤掉当前shell的PID，再决定杀哪些：

for pid in $(pgrep -f "my_worker" | grep -v "^$$\$"); do echo "准备清理PID: $pid" kill "${pid}" done

$$代表当前脚本的PID，grep -v把这一行过滤掉，避免自杀。如果系统里同时存在多个同名实例，建议花点时间改成用PID文件管理进程，启动时写pid文件，清理时读pid文件，这样就不会模糊匹配。

6. 上线前最后一公里：三种验证手段与一条习惯

6.1 静态检查和隔离运行

脚本写完后，别急着往生产机器上放。我这几年的习惯是先做三个检查：bash -n查语法，shellcheck查隐患，隔离机器跑一遍观察行为。

# 1. 语法检查 bash -n sys_check.sh cleanup_logs.sh backup_snapshot.sh # 2. 静态分析，SHELLCHECK是排查未定义变量和误删命令的最快方式 shellcheck -S warning sys_check.sh cleanup_logs.sh backup_snapshot.sh # 3. 在空闲机器上用临时目录模拟一次，观察CPU、内存、写盘量 bash cleanup_logs.sh /tmp/fake_log_dir 30 '*.log' 1

bash -n只做语法解析，不执行代码，适合在持续交付流程里当成前置卡口。shellcheck的-S warning级别会提示未加引号的变量、循环内管道行为等实际问题，比人工review可靠得多。隔离运行阶段用dry-run模式，观察脚本跑完后的输出文件、临时目录残留、CPU峰值，确认都没有异常再考虑定时任务。

6.2 上线清单：六项都过了才碰生产

我给自己固定了一张上线清单，每次改脚本都逐项核对：

这张表不复杂，但它能挡住大多数“脚本写得对但环境不对”的问题。尤其是最后一条，跑完cron后必须去看一眼输出日志，别假设它一定成功。

6.3 一个让脚本从“能用”到“敢用”的习惯

工具脚本最大的风险不是写错逻辑，而是没人验证它就稀里糊涂上了生产。从那以后我每次上新脚本都强制走一遍：先在空闲机器手动跑，再挂cron自动跑，跑完必须看输出日志的第一行和最后一行，确认结果是真的，而不是流程上看起来正常。这习惯帮我避开了至少三次凌晨工单，其中一次就是日志清理脚本在cron里PATH不对，静默失败了三天。希望你也能在新脚本上线前，给它们留出这个验证窗口，二十秒的检查，比半夜爬起来找原因省力得多。希望帮到你。

本文还有配套的精品资源，点击获取