Redis自动RDB备份不能仅用crontab调用bgsa ve，因BGSA VE异步返回OK不保证写入完成，需校验rdb_last_sa ve_time和文件非空，并动态获取路径、加超时、轮转清理。
如果你打算用 crontab 配合 redis-cli bgsa ve 来实现 Redis 的自动 RDB 备份，那可得小心了——这个组合看似简单，实则暗藏玄机。问题核心在于，BGSA VE 是一个异步命令，它返回的 OK 仅仅意味着“后台保存任务已启动”，而 crontab 对此后的一切都一无所知。脚本执行是否成功？RDB 文件是否真的生成？旧备份是否需要清理？这些关键环节，一个简单的 crontab 任务根本无法感知和保障。
为什么 redis-cli bgsa ve 在 crontab 里容易“看似运行实则失效”
这里有两个典型的陷阱。首先，crontab 的执行环境通常是“干净”甚至“残缺”的，它可能缺失常规的 PATH 和 HOME 环境变量，导致 redis-cli 命令根本找不到。其次，也是更隐蔽的一点：BGSA VE 命令的异步特性。它一收到命令就返回 OK，但此时 Redis 主进程可能还在 fork 子进程，或者子进程正在将数据写入磁盘。如果脚本紧接着就去检查文件修改时间或进行压缩打包，大概率会拿到一个空文件，或者更糟——上一次备份残留的旧文件。
- 必须等待写入完成：不能依赖命令返回值。正确做法是，通过
redis-cli info persistence | grep rdb_last_sa ve_time来获取最近一次成功保存的时间戳，并确认这个时间戳已经更新到最近。 - 动态获取备份路径：不要想当然地硬编码路径如
/var/lib/redis/dump.rdb。Redis 的持久化目录和文件名是可配置的，务必使用redis-cli config get dir和config get dbfilename来动态读取实际路径。 - 设置安全超时：后台保存过程可能因内存不足（OOM）或其它原因被终止。为整个备份流程加上一个超时机制（例如
timeout 300），可以有效防止脚本因意外情况而无限期挂起。
一个安全可用的自动备份脚本（含状态校验与轮转）
纸上谈兵不如动手实践。下面这个脚本整合了上述所有要点，你可以将其保存为 /usr/local/bin/redis-rdb-backup.sh，并记得用 chmod +x 赋予执行权限。
#!/bin/bash
REDIS_CLI="/usr/bin/redis-cli"
REDIS_HOST="127.0.0.1"
REDIS_PORT="6379"
BACKUP_DIR="/data/redis-backup"
KEEP_DAYS=7
# 获取实际 RDB 路径
RDB_DIR=$($REDIS_CLI -h $REDIS_HOST -p $REDIS_PORT config get dir | tail -n 1)
RDB_NAME=$($REDIS_CLI -h $REDIS_HOST -p $REDIS_PORT config get dbfilename | tail -n 1)
RDB_PATH="$RDB_DIR/$RDB_NAME"
# 触发 BGSA VE
if ! $REDIS_CLI -h $REDIS_HOST -p $REDIS_PORT bgsa ve 2>/dev/null | grep -q "OK"; then
echo "[$(date)] BGSA VE failed" >&2
exit 1
fi
# 等待写入完成（最多等 60 秒）
for i in $(seq 1 60); do
LAST_SA VE=$($REDIS_CLI -h $REDIS_HOST -p $REDIS_PORT info persistence | grep rdb_last_sa ve_time | cut -d: -f2 | tr -d '\r\n')
if [[ "$LAST_SA VE" =~ ^[0-9]+$ ]] && [ $(($(date +%s) - LAST_SA VE)) -lt 300 ]; then
break
fi
sleep 1
done
# 检查 RDB 文件是否存在且非空
if [[ ! -s "$RDB_PATH" ]]; then
echo "[$(date)] RDB file missing or empty: $RDB_PATH" >&2
exit 1
fi
# 复制并打时间戳
mkdir -p "$BACKUP_DIR"
TS=$(date +"%Y%m%d_%H%M%S")
cp "$RDB_PATH" "$BACKUP_DIR/dump_$TS.rdb"
gzip "$BACKUP_DIR/dump_$TS.rdb"
# 清理 7 天前的备份
find "$BACKUP_DIR" -name "dump_*.rdb.gz" -mtime +$KEEP_DAYS -delete
这里有个细节需要特别注意：通过 config get 命令获取配置时，输出格式是“键值对”两行。因此，$RDB_DIR 和 $RDB_NAME 的赋值必须使用 tail -n 1 来提取真正的值（第二行），否则路径拼接会包含键名，导致后续操作失败。
crontab 正确配置方式（带环境与日志）
脚本写好了，在 crontab 里直接调用就行了吗？当然不是。像 * */6 * * * redis-cli bgsa ve 这样的写法基本是无效的。正确的配置需要考虑到执行环境和可观测性：
# 编辑 root 的 crontab：crontab -e SHELL=/bin/bash PATH=/usr/local/bin:/usr/bin:/bin 0 */6 * * * /usr/local/bin/redis-rdb-backup.sh >> /var/log/redis-backup.log 2>&1
- 显式设置环境变量：必须在 crontab 文件顶部或任务行中明确设置
PATH，确保系统能找到redis-cli等命令。 - 重定向日志输出：将脚本的标准输出和错误输出都重定向到一个日志文件（如
/var/log/redis-backup.log）。这对于排查“静默失败”至关重要，比如连接超时、权限拒绝等错误，如果没有日志，你将毫无头绪。 - 合理设置备份频率：切忌使用
*/6（每6分钟）这样的高频率。频繁触发BGSA VE会导致 Redis 主进程频繁 fork，产生显著的 CPU 和内存开销。对于生产环境，每4小时或6小时备份一次通常是更合理的选择。
说到底，实现一个可靠的自动备份，真正的难点不在于触发 BGSA VE 这个动作，而在于如何确认数据确实已经安全落地。线上不乏这样的案例：备份脚本常年返回成功退出码（0），但关键时刻却发现最新的 RDB 文件是几个月前的。因此，对 rdb_last_sa ve_time 的校验和对文件大小（-s）的检查，两者缺一不可。这才是保障数据安全的最后一道防线。
