直接用 cp 拷运行中的 dump.rdb 会失败——文件可能正被 BGSAVE 重写，导致损坏；正确做法是 redis-cli --rdb 主动触发完整快照，加时间戳、校验和、元数据标签及生命周期策略，并记录 master_repl_offset 保障 RPO。
直接用 cp 拷运行中的 dump.rdb 到异地存储，90% 会失败——文件可能正在被 BGSAVE 重写，导致损坏或不一致。
必须用 redis-cli --rdb 主动触发新快照
运行中 Redis 的 dump.rdb 是动态文件，cp 它等于赌运气。正确做法是让 Redis 主动写一个干净、完整、带时间戳的新 RDB 文件：
- 命令示例：
redis-cli --rdb /backup/redis-$(date -u +%Y%m%dT%H%M%SZ).rdb - 该命令会阻塞直到写完，保证文件一致性；不依赖
save配置，也不干扰当前BGSAVE进程 - 别把备份路径设在 Redis 的
dir目录下（如/var/lib/redis），否则磁盘满时 Redis 和备份一起挂 - 执行前先
CONFIG GET dir确认 Redis 工作目录，避免权限或路径冲突
上传前必须加 sha256sum 校验和与元数据标签
对象存储（S3/OSS）上传中断、网络丢包、客户端 bug 都可能导致文件截断，但错误日志里只显示 “200 OK”，你根本不知道文件是否完整。
- 上传后立刻生成校验文件：
sha256sum backup-20261019.rdb > backup-20261019.rdb.sha256 - 上传时打上关键元数据：AWS 用
x-amz-tagging，阿里云用x-oss-tagging，内容至少含redis_version=7.2.4和backup_time=20261019T120000Z - 设置生命周期策略（如保留最近 7 天 + 每月 1 号），防止备份无限堆积挤爆存储空间
纯 RDB 冷备无法满足低 RPO，必须配套记录 master_repl_offset
如果业务要求 RPO
- 每次生成 RDB 后，立即执行
INFO replication，提取master_repl_offset值 - 把这个 offset 和 RDB 文件名、时间戳一起存进元数据（例如 JSON 文件或数据库记录）
- 异地恢复时：先加载 RDB，再用
redis-cli --pipe重放最近几小时归档的 AOF 片段（需提前切片），最后靠PSYNC连主库追平剩余差异 - 注意：AOF 必须开启（
appendonly yes），且配置auto-aof-rewrite-percentage 100和auto-aof-rewrite-min-size 64mb控制体积
真正容易被跳过的不是脚本编写，而是恢复验证——没在隔离环境（比如 Docker）里跑过一次 redis-server --dbfilename backup.rdb 并连上去 KEYS * 看数据是否完整，那这个备份就等于没做。
