必须轮询rdb_last_save_time并校验文件非空，因bgsave异步返回ok不保证写入完成；需用绝对路径调用redis-cli，备份文件须带时间戳且保留48小时小时级+30天天级，配合超时保护与远程校验。
不能只用 crontab 直接调用 bgsave —— 因为它返回 OK 仅表示“已触发”，不保证文件已写完，脚本紧接着拷贝大概率拿到空文件或旧文件。
为什么 redis-cli bgsave 在 crontab 里常“假成功”
常见错误现象：crontab 日志显示执行成功，但备份目录里是零字节文件、时间戳没更新、或内容仍是几小时前的快照。
-
crontab默认环境缺少PATH，redis-cli可能根本找不到（需写绝对路径） -
bgsave是异步命令，Redis 主进程 fork 子进程后立即返回OK，而 RDB 写入可能还在进行中 - 脚本若立刻
cp或stat，会读到未完成的文件或上一轮残留 - 硬编码
/var/lib/redis/dump.rdb风险高：实际路径由config get dir和config get dbfilename决定，不同部署可能不同
必须校验 RDB 是否真正写入完成
不能依赖 sleep 固定时长（网络延迟、磁盘 IO 波动会让 2 秒或 10 秒都不够稳），要用 Redis 自身状态反馈。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 轮询
redis-cli info persistence | grep rdb_last_save_time，确认该时间戳已更新且距当前不超过 300 秒 - 再检查目标文件：
[[ -s "$RDB_PATH" ]]（-s判非空，比-f更安全） - 加超时保护：整个等待过程最多 60 秒，避免卡死（例如子进程被 OOM kill）
- 示例判断逻辑：
LAST_SAVE=$($REDIS_CLI -h $HOST -p $PORT info persistence | grep rdb_last_save_time | cut -d: -f2 | tr -d '\r\n')<br>if [[ "$LAST_SAVE" =~ ^[0-9]+$ ]] && [ $(($(date +%s) - LAST_SAVE)) -lt 300 ]; then break; fi
备份文件必须带时间戳并做生命周期管理
直接覆盖 dump.rdb 没法回溯、无法定位故障点、更谈不上跨机容灾。
- 用
date +%Y%m%d_%H%M%S命名副本，例如dump_20260903_152401.rdb - 小时级备份保留最近 48 小时（注意：不是“48 个文件”，是按时间删），天级备份保留最近 30 天
- 清理动作必须放在拷贝成功之后，否则可能误删最新备份
- 远程备份建议用
rsync --remove-source-files或scp+ 校验（如sha256sum），别只传不管结果
最易被忽略的一点：bgsave 触发后，若 Redis 正在加载 AOF 或发生 fork 失败（内存不足），rdb_last_save_time 不会更新，但脚本可能仍认为“等到了”。务必把 redis-cli info persistence 的完整输出临时记录下来，出问题时能快速区分是写入失败，还是校验逻辑漏判。
