crontab 不支持自动重试，必须在备份脚本中实现重试逻辑：通过 exit code 检测失败、while 循环控制次数、sleep 避免重压、日志记录全过程，并配合绝对路径调用、合理调度与校验措施提升鲁棒性。
Crontab 本身不支持“自动重试”逻辑——它只负责在指定时间点触发命令，不会判断上一次是否失败、也不会自动补跑或重试。要实现备份失败后的自动重试，必须把重试逻辑写进备份脚本里，而不是依赖 crontab 调度机制。
在备份脚本中嵌入重试逻辑
核心思路：让脚本自己检测上次执行是否成功，若失败则按策略重试（如最多3次，间隔30秒），并记录过程。以下是一个典型结构：
- 用 exit code 判断命令是否成功（例如
mysqldump或tar执行后检查$?） - 用 while 循环 + 计数器 控制重试次数
- 每次失败后用
sleep暂停，避免瞬时重压（如数据库连接拒绝） - 将每次尝试的时间、结果、错误信息写入日志，便于排查
示例：带重试的 MySQL 备份脚本片段
以下代码可直接放入你的 backup_mysql.sh 中（注意替换数据库参数和路径）：
宝塔Linux面板11.3.0
下载
宝塔面板11.3.0是一款针对Linux服务器设计的可视化管理工具，通过重构核心模块实现资源占用显著降低，尤其适合低配置服务器环境。它将复杂的命令行操作转化为直观的图形界面，帮助开发者快速完成网站部署、环境配置及日常运维工作，无需专业技术背景即可高效管理服务器。
#!/bin/bash
DB_USER="backup_user"
DB_PASS="secure_pass"
DB_NAME="myapp"
BACKUP_DIR="/backup/mysql"
DATE=$(date +\%Y\%m\%d_\%H\%M)
LOG_FILE="$BACKUP_DIR/backup.log"
<p>mkdir -p "$BACKUP_DIR"</p><h1>设置最大重试次数和初始计数</h1><p>MAX_RETRY=3
RETRY_COUNT=0</p><p>while [ $RETRY_COUNT -lt $MAX_RETRY ]; do
echo "[$(date)] 尝试第 $((RETRY_COUNT + 1)) 次备份..." >> "$LOG_FILE"
if mysqldump -u "$DB_USER" -p"$DB_PASS" "$DB_NAME" | gzip > "$BACKUP_DIR/${DB<em>NAME}</em>${DATE}.sql.gz" 2>> "$LOG_FILE"; then
echo "[$(date)] 备份成功: ${DB<em>NAME}</em>${DATE}.sql.gz" >> "$LOG_FILE"
exit 0
else
echo "[$(date)] 第 $((RETRY_COUNT + 1)) 次备份失败，等待30秒后重试..." >> "$LOG_FILE"
sleep 30
RETRY_COUNT=$((RETRY_COUNT + 1))
fi
done</p><p>echo "[$(date)] 已达最大重试次数（$MAX_RETRY），备份终止。请检查日志。" >> "$LOG_FILE"
exit 1
</p>配合 crontab 的合理调度建议
重试是脚本内行为，crontab 只需保证基础调度可靠：
- 使用绝对路径调用脚本（如
/opt/backup/backup_mysql.sh） - 在 crontab 条目中显式重定向输出：
0 3 * * * /opt/backup/backup_mysql.sh >> /var/log/backup_retry.log 2>&1 - 避免高频调度（如每分钟），否则重试叠加可能引发资源争抢；推荐每天固定时段+脚本内重试更稳妥
- 可额外加一条“兜底任务”，比如每天凌晨4点检查前一日是否有成功备份文件，无则发告警（需另写校验脚本）
补充：重试之外的关键保障措施
仅靠重试不够，还需组合其他手段提升备份鲁棒性：
-
备份前校验目标目录可写：用
test -w "$BACKUP_DIR"防止磁盘满或权限丢失 -
备份后验证压缩包完整性：对生成的
.sql.gz执行gzip -t，失败则标记为无效并触发下一轮重试 -
避免密码明文暴露：改用
~/.my.cnf配置文件存放 DB 凭据，并设chmod 600 -
限制旧备份数量：重试成功后，再执行
find $BACKUP_DIR -name "*.sql.gz" -mtime +7 -delete清理过期文件
