RDB快照自动化必须用BGSAVE而非SAVE，因其异步非阻塞；需轮询INFO persistence中rdb_bgsave_in_progress=0并校验rdb_last_save_time更新、文件头“REDIS”及权限，再安全拷贝，避免使用自动save配置以确保可控可审计。
如何在CI/CD或定时任务里安全触发RDB快照
自动化流程里不能用 SAVE，它会阻塞Redis主线程，导致服务不可用。必须用 BGSAVE，但要注意它只是“发起异步任务”，不保证立即完成。
-
BGSAVE返回Background saving started后，需确认是否真正写完，否则拷贝的dump.rdb可能是空文件或不完整 - 推荐轮询
INFO persistence中的rdb_bgsave_in_progress字段，值为0才表示完成 - 若脚本执行环境无法连 Redis（如离线备份机），可用
redis-cli --raw INFO persistence | grep rdb_bgsave_in_progress解析 - 生产中建议加超时控制（比如最多等 60 秒），避免卡死流水线
备份脚本里复制RDB文件的关键检查点
直接 cp /var/lib/redis/dump.rdb /backup/ 很危险——RDB 文件在 BGSAVE 过程中由子进程写入临时文件，再原子重命名为 dump.rdb。如果在重命名前拷贝，可能拿到旧快照甚至损坏文件。
- 务必等
rdb_bgsave_in_progress=0且rdb_last_save_time更新后再拷贝 - 用
stat -c "%Y" /var/lib/redis/dump.rdb检查文件修改时间，确保比触发BGSAVE的时间晚 - 备份前校验文件头：
head -c5 /var/lib/redis/dump.rdb | grep -q "REDIS"，防止误拷非RDB文件 - 压缩前先
chmod 400设置只读权限，避免被意外覆盖
还原RDB到新实例时的路径与权限陷阱
还原失败最常见的原因是Redis启动时根本没加载RDB文件，不是数据不对，而是压根没读进去。
- 确认
redis.conf中的dir配置和实际挂载路径一致，Docker里尤其容易错：比如-v /host/data:/data，但dir写的是/var/lib/redis - RDB文件名必须是
dump.rdb（除非改了dbfilename配置），且权限要让Redis进程可读（常被忽略：容器内redis用户UID可能不是1000） - 启动日志里必须出现
Loading RDB，没这句说明配置或路径有误；如果出现Failed opening .rdb for reading，优先查SELinux或mount参数（如noexec） - 跨版本还原要小心：
redis-check-rdb dump.rdb可提前验证兼容性，避免启动失败
为什么不能只靠自动save配置做备份
redis.conf 里的 save 规则（如 save 900 1）只控制服务端自动触发时机，对运维流水线不可控、不可观测、不可审计。
- 自动save依赖写操作频率，低峰期可能几小时都不触发，备份窗口不可预测
- 无法知道某次save是否成功：失败时Redis只记日志，不会抛出错误给外部系统
- 多实例统一管理时，每个Redis的
save策略可能不同，流水线需要统一调度逻辑 - 真正可靠的自动化备份，必须主动调用
BGSAVE+ 显式等待 + 校验 + 归档，把控制权握在自己手里
最易被忽略的一点：RDB还原是启动时一次性加载，没有“增量应用”概念。如果你在还原后立刻写入新数据，又没开AOF，那两次备份之间的变更就彻底丢失了——这不是RDB的问题，而是备份策略本身没覆盖写入持续性场景。
