定时任务配置防误删机制：怎样保护关键运维脚本

定时任务误删风险源于脚本内容、权限和环境变量失控，而非cron本身；需校验变量路径、用find替代rm -rf、加白名单、引入回收站机制、最小化执行权限、启用审计与快照回滚。

定时任务本身不会误删，但脚本内容、执行权限和环境变量一旦失控，就可能把“自动清理”变成“自动毁灭”。关键不在 cron 本身，而在脚本怎么写、谁来跑、删什么、删之前有没有留退路。

脚本执行前强制校验路径与变量

很多误删源于脚本里带变量的 rm -rf 操作，比如 rm -rf $LOG_DIR/*。一旦 $LOG_DIR 为空或被覆盖，就会变成 rm -rf /* 或 rm -rf ./*。

• 所有含变量的删除路径，必须先用 test -d "$LOG_DIR" 判断目录是否存在且非空
• 禁止在脚本中直接拼接通配符，改用 find "$LOG_DIR" -maxdepth 1 -type f -name "*.log" -delete 这类更可控的方式
• 对关键路径（如 /data、/backup）加白名单检查，不匹配则 exit 1 并记录告警

用回收站机制替代直接删除

哪怕定时任务执行的是“清理”，也别真删——先挪走，再择机清空。

• 为每个服务/角色建独立回收站目录，例如 /var/log/.trash/nginx/，避免混用
• 清理脚本中用 mv "$file" "/var/log/.trash/nginx/$(basename "$file").$(date +%s)" 替代 rm
• 另设一个低频定时任务（如每周日凌晨）专门清空回收站，且该任务需人工确认或二次密码验证

权限隔离 + 最小化执行身份

让定时任务以最低必要权限运行，是防误删的底层防线。

• 不要用 root 用户跑日常清理脚本；为日志清理、临时文件归档等任务单独创建专用系统用户（如 logclean）
• 该用户仅对目标目录有 rwx 权限，其余路径一律不可写；可通过 setfacl 或目录 umask 进一步限制
• 在 crontab 中显式指定用户，例如：0 2 * * * logclean /opt/scripts/clean-nginx-logs.sh

启用操作审计与快速回滚能力

防不住万一，就得确保能秒级定位+还原。

• 所有清理类脚本开头统一加上日志头：记录执行时间、用户、当前工作目录、关键变量值
• 对核心目录（如 /etc、/var/www）开启 inotify 监控，发现异常批量删除立即告警并暂停后续任务
• 配合定时快照（如 btrfs snapshot 或 rsync 增量归档），保证最近 24 小时内任意时刻可回退到前一状态