不能只用 crontab 直接调用 redis-cli bgsave，因其返回 ok 仅表示命令下发成功，不保证 rdb 文件已写完、非空或路径正确；需动态获取路径、轮询 rdb_last_save_time 确认完成、校验文件大小及结构，并处理权限与清理。
不能只用 crontab 直接调用 redis-cli bgsave —— 因为它返回 OK 仅表示“已下发”，不代表文件已写完，更不保证文件非空或路径正确。
为什么 redis-cli bgsave 在 crontab 里经常“假成功”
常见错误现象：脚本跑完，/backup/ 下出现空的 dump-20260713.rdb，或者压根没生成新文件，但日志里全是 OK。
-
crontab默认环境缺失PATH和HOME，redis-cli可能根本找不到（尤其装在/usr/local/bin时） -
bgsave是异步的，子进程 fork 后主进程立刻返回，文件写入可能要几秒甚至几十秒，尤其数据量大或磁盘慢时 - 硬编码
/var/lib/redis/dump.rdb很危险：实际路径由config get dir和config get dbfilename决定，不同实例可能不同
必须等待 RDB 写入完成，而不是靠 sleep
用固定 sleep 10 或 sleep 30 极不可靠：小实例 2 秒就写完，大实例可能要 90 秒；等不够会拷贝旧文件，等太长又拖慢调度。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 正确做法是轮询
redis-cli info persistence | grep rdb_last_save_time，对比当前时间戳，确认更新发生在最近 5 分钟内 - 每次轮询间隔 1 秒，最多等 60 秒（避免卡死），超时即失败退出
- 注意：
rdb_last_save_time是 Unix 时间戳，需用$(date +%s)对齐计算
校验 RDB 文件是否真实生成且可用
光看文件存在不够——bgsave 失败时可能残留上一轮的 dump.rdb，或者写入中途被 OOM kill 导致文件截断。
- 必须用
[[ -s "$RDB_PATH" ]]检查文件大小 > 0 字节 - 建议加一步
redis-check-rdb $RDB_PATH &>/dev/null验证二进制结构完整性（可选但强烈推荐） - 备份前先
mkdir -p $BACKUP_DIR，避免因目录不存在导致cp静默失败
动态获取路径、加超时、做轮转清理
生产环境不能接受“一次写错全崩”，脚本得自己扛住配置漂移和磁盘满等现实问题。
- 用
$REDIS_CLI config get dir和config get dbfilename动态拼出RDB_PATH，别硬编码 - 所有
redis-cli调用前加timeout 30（如timeout 30 $REDIS_CLI bgsave），防网络卡顿或 Redis 假死 - 清理旧备份用
find $BACKUP_DIR -name "dump-*.rdb*" -mtime +7 -delete，比rm -rf时间戳更可靠
最易被忽略的是：RDB 文件权限继承自 Redis 进程用户（通常是 redis），但备份脚本常以 root 运行，cp 出来的文件属主可能变成 root:root，后续恢复时若没改权限会导致 Redis 启动失败。
