Linux自动备份核心在于链路可靠：脚本须自包含、路径全绝对、日志必重定向、清理前先测试；cron因PATH极简易报command not found，需显式声明PATH并用绝对路径调用命令。
Linux 中配置自动备份任务，核心不是“加一条 crontab”，而是让整个链路可验证、不静默失败——脚本必须自包含、路径全写死、日志必重定向、清理前先测试。
crontab 条目里为什么总报 command not found
因为 cron 执行时的 PATH 极简（通常只有 /usr/bin:/bin），脚本里写的 tar、mysqldump、rsync 都可能找不到。
- 脚本开头必须显式声明：
PATH=/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin; export PATH - 所有命令用绝对路径：
/bin/tar、/usr/bin/mysqldump、/usr/bin/rsync - 别信
#!/usr/bin/env bash，改用#!/bin/bash，避免环境不可控 - 数据库密码绝不能写在命令行（会出现在
ps输出里），走~/.my.cnf或--defaults-extra-file
备份脚本必须自带时间戳和清理逻辑
没时间戳的备份文件会覆盖；不带清理的脚本跑一周就撑爆磁盘——这两步得写进脚本里，不能靠人肉干预。
- 文件名用
$(date +\%Y\%m\%d_\%H\%M)（注意%要转义），分钟级精度防覆盖 - 清理用
find /backup -name "*.tar.gz" -mtime +7 -print先看要删哪些，确认无误再换-delete - 别用
rm -rf /backup/*，一不小心删掉正在写入的文件就全完了 - 压缩后立刻校验：
if ! tar -tzf backup_*.tar.gz >/dev/null 2>&1; then exit 1; fi
如何让 cron 真正可靠而不是“设完就忘”
cron 只负责准时调用，它不保证脚本成功。真正靠得住的是你是否做了三件事：手动验证、日志重定向、失败捕获。
- 添加 crontab 前，先手动执行一次：
/root/scripts/backup.sh，确认生成文件、权限正常、磁盘有空间 - crontab 条目末尾必须加：
>> /var/log/backup.log 2>&1，否则失败无声无息 - 脚本里关键步骤加状态判断：
if [ $? -ne 0 ]; then echo "$(date) ERROR: tar failed" >&2; exit 1; fi - 检查 cron 服务本身是否在运行：
systemctl status cron（Debian/Ubuntu）或systemctl status crond（RHEL/CentOS）
不同数据类型该用什么工具
用错工具反而降低可靠性：全量打包大目录浪费 IO，只 rsync 配置又没法做数据库一致性快照。
- 系统配置（
/etc、/boot/grub2）：用tar -czf+--preserve-permissions --acls，保留权限和 ACL - 网站文件（
/var/www/html）：用rsync -av --delete，支持增量、断点续传、镜像同步 - MySQL/PostgreSQL：用
mysqldump或pg_dump+ gzip，导出后立即head -n 5看头部是否为 SQL - 跨网或需加密：改用
borgbackup --encryption=repokey-blake2，客户端加密+自动去重
最常被跳过的一步是恢复验证：备份有效的唯一标准，是能真正解压、还原、启动服务。每月至少抽一个备份文件，用 tar -tzf 检查结构，再解压到临时目录实测内容完整性。
