cron 实现 linux 业务数据自动备份需确保定时、执行、清理、验证四环节闭环：脚本自包含、路径写死、日志可查、失败有反馈；cron 条目封装脚本调用并重定向日志；清理嵌入脚本按 mtime 删除旧文件；验证须检查文件非空、结构完整及定期还原测试。
用 Cron 实现 Linux 业务数据自动备份，核心不是堆命令，而是让定时、执行、清理、验证四个环节环环相扣。关键在于脚本要自包含、路径要写死、日志要可查、失败要有反馈。
备份脚本必须独立可靠
脚本不能依赖登录环境，所有路径和变量都要显式声明：
- 首行固定解释器：#!/bin/bash
- 开头立即设置 PATH：PATH=/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin；export PATH
- 数据库工具（如 mysqldump）或同步工具（如 rsync）必须用绝对路径，例如 /usr/bin/mysqldump 或 /usr/bin/rsync
- 时间戳用 date +%Y%m%d_%H%M，避免空格和特殊字符影响文件名解析
- 密码不写在脚本里，MySQL 推荐用 ~/.my.cnf 配置认证，PostgreSQL 用 ~/.pgpass
Cron 条目要防“静默失败”
直接写命令容易因环境缺失而失效，稳妥做法是封装脚本再调用，并重定向输出：
- crontab 中不写 $(date) 这类 shell 扩展，它在 cron 环境下不生效；统一交给脚本内部处理
- 每条任务末尾加日志重定向：>> /var/log/backup.log 2>&1
- 避免用 * * * * * 这类高频调度，业务备份一般设为每天低峰期，如 0 2 * * *（凌晨2点）
- 集群多节点时，在 crontab 里加 sleep $((RANDOM % 300)) 防止瞬时 I/O 冲突
保留策略与空间管理要落地
只备份不清理，迟早填满磁盘。清理逻辑应嵌入脚本，而非靠人工干预：
- tar 或 rsync 备份后，立刻执行 find 命令清理旧文件，例如：
find /backup -name "backup_*.tar.gz" -mtime +7 -delete - 用 -maxdepth 1 防止误删子目录下的其他文件
- 对数据库 SQL 备份，同样按 mtime 清理，但注意 mysqldump 输出可能带换行，建议先用 -type f 限定
- 定期检查目标分区使用率，可在脚本开头加入 df 命令判断，剩余空间低于15%时跳过本次备份并记录告警
验证机制不能省略
备份成功 ≠ 能恢复。至少要做三步轻量验证：
- 检查压缩包是否生成且非空：[ -s "$BACKUP_DIR/$FILENAME" ]
- 对 tar 包执行 tar -tzf 检查结构完整性（不解压）
- 对 SQL 文件 grep -q "INSERT INTO" 或检查行数是否明显异常（如只有几十行可能是失败导出）
- 每月抽一份备份，手动 scp 到测试机尝试还原一次，确认流程通路
