冷备需主动触发redis-cli --rdb生成带时间戳的完整RDB快照，避免直接cp运行中dump.rdb；上传前计算sha256并存为同名校验文件，打版本与时间标签，设生命周期策略清理旧备份；纯RDB无法满足低RPO，需结合AOF与复制偏移。
冷备就是定期拷RDB，但别直接cp到NFS或对象存储
Redis冷备的本质是保存某个时间点的完整数据快照，RDB文件天然适合——它小、可压缩、校验方便。但很多人一上来就写个定时任务 cp /var/lib/redis/dump.rdb s3://my-bucket/，这会出问题：dump.rdb 在Redis运行时可能正在被重写（BGSAVE），直接拷会导致文件损坏或不一致。
- 必须等
SAVE或BGSAVE完成后再拷，推荐监听CONFIG GET dir+INFO persistence中的rdb_bgsave_in_progress:0 - 更稳妥的做法：用
redis-cli --rdb /tmp/backup-$(date -u +%Y%m%dT%H%M%SZ).rdb主动触发一次新备份，它会阻塞直到写完，且生成带时间戳的独立文件 - 别把备份路径设在Redis的
dir目录下——否则万一磁盘满，Redis和备份全挂
上传到对象存储前，务必加校验和与过期标签
云存储不是保险箱。S3、OSS这类服务虽高可用，但上传中断、网络丢包、客户端bug都可能导致文件截断或错位。只传一个 .rdb 文件，恢复时发现打不开，根本分不清是Redis版本不兼容，还是上传坏了。
- 上传后立刻计算并保存
sha256sum，存为同名.rdb.sha256文件（例如backup-20240520.rdb.sha256） - 给对象加
x-amz-tagging（AWS）或x-oss-tagging（阿里云），标上redis_version=7.2.4&backup_time=20240520T120000Z，避免恢复时拿错版本 - 设置生命周期规则自动清理旧备份，比如保留最近7天+每月1号的，防止无限堆积
异地容灾不能只靠RDB，AOF+复制偏移是关键补丁
纯RDB冷备只能恢复到某次快照时刻，中间丢失的数据无法找回。如果业务要求RPO
- 开启
appendonly yes并配置appendfilename "appendonly.aof"，再配合auto-aof-rewrite-percentage 100和auto-aof-rewrite-min-size 64mb，让AOF文件保持可控大小 - 每次上传RDB时，顺手记下当前
INFO replication输出里的master_repl_offset，存进备份元数据里——这是恢复后做增量追平的起点 - 异地节点启动时先加载RDB，再用
redis-cli --pipe把最近几小时的AOF片段（需提前切片归档）重放，最后用PSYNC连主库同步剩余差异
恢复验证常被跳过，但它是冷备是否真有效的唯一判据
备份脚本跑通、上传状态200、日志显示“success”，不代表能恢复。没验证过的备份等于没备份。
- 每月至少一次，在隔离环境（如Docker）中拉取最新RDB+对应AOF片段，启动Redis并执行
DBSIZE、KEYS *（小数据集）、SCAN随机抽样校验 - 重点检查：
redis-server --test-memory 100确保RDB没内存损坏；用redis-check-rdb扫描文件结构完整性 - 别用生产Redis实例做验证——
redis-check-rdb会读整个文件，大RDB可能卡住主进程
冷备真正难的不是拷文件，而是让每一次备份都自带上下文（时间、版本、偏移、校验）和可验证路径。少一个环节，故障时就多一分不确定性。
