Redis灾备不能只靠主从复制，因其无法应对节点故障、网络分区或误操作；真正可回退的是RDB快照和AOF日志的异地备份，需严格校验生成状态、完整性及时间点一致性。
Redis灾备为什么不能只靠主从复制
主从复制本身不构成灾备——从节点故障、网络分区或误操作（比如 FLUSHALL）会立刻同步到所有从库。真正能回退到某个时间点的，只有本地生成的持久化文件：RDB 快照和 AOF 日志。异地备份的本质，就是把这两类文件定期、可靠地传到另一个物理位置。
RDB文件异地备份的关键控制点
RDB 是二进制快照，体积小、恢复快，但默认是异步生成（SAVE 会阻塞，BGSAVE 才是生产环境唯一选择）。它的问题在于「可能丢数据」：两次 BGSAVE 之间写入的数据不会落盘。
- 用
save 900 1这类配置时，要确认业务写入频率是否真能满足——如果每分钟写 5000 次 key，那 RDB 实际触发间隔可能是 2 分钟而非 15 分钟 - 备份脚本必须校验
redis-cli bgsave返回值，失败时不能静默跳过（常见于磁盘满或 fork 失败） - 传输前务必用
sha256sum计算校验和，避免网络中断导致文件截断却误认为上传成功 - 不要直接 rsync 整个
/var/lib/redis/目录——RDB 文件可能正在被BGSAVE覆盖，应先redis-cli config get dbfilename获取当前文件名，再配合ls -lt取最新修改的 .rdb 文件
AOF文件异地备份比RDB更难处理
AOF 记录的是写命令文本，天然可读，但有三个硬伤：体积大、重写（BGREWRITEAOF）期间会生成临时文件、且重写完成前旧 AOF 仍持续追加。直接拷贝正在使用的 appendonly.aof 极易损坏。
- 必须等
redis-cli config get appendfilename返回的文件不再被写入——可通过redis-cli info persistence | grep aof_rewrite_in_progress确认为0 - 若启用了
aof-use-rdb-preamble yes（Redis 7.0+ 默认），最终 AOF 文件头部是 RDB 格式，尾部是命令，备份时需整份传输，不可切片 - 异地传输 AOF 前建议先
redis-check-aof --fix，尤其当 Redis 非正常退出后，AOF 可能末尾有破损命令 - 不要用定时任务每 5 分钟 cp 一次 AOF——它没有 RDB 那种“原子生成”特性，频繁拷贝大概率拿到中间态
备份策略组合与落地要点
纯 RDB 备份恢复快但最多丢 15 分钟数据；纯 AOF 备份数据最全但恢复慢、存储成本高。生产中几乎都采用「RDB 基线 + AOF 增量」混合方式，但要注意：
- Redis 本身不提供跨机房的 AOF 实时同步机制，所谓「实时灾备」只能靠外部工具（如 inotifywait + rsync）监听 AOF 文件变更，延迟通常在秒级
- 异地备份目录结构要保留时间戳，例如
s3://my-redis-backup/prod/rdb/2024-06-15T14:22:00Z/dump.rdb，否则无法做时间点恢复 - 恢复验证不能只 check 文件存在——必须在隔离环境启动 Redis，执行
redis-cli info keyspace确认 key 数量与预期一致，再抽样GET几个关键业务 key - 云厂商提供的 Redis 服务（如阿里云 Tair、AWS MemoryDB）往往封装了自动备份，但其底层仍是 RDB 或 AOF 导出，你要清楚它是否包含 AOF 重写后的最终文件，还是仅导出某一刻的原始 AOF
异地备份不是“设好 cron 就完事”，核心难点始终在：如何确认你传走的那个文件，确实是 Redis 认为「此刻已落盘、可安全读取」的状态。任何跳过状态校验的自动化，迟早会在凌晨三点让你面对一个空的 keys * 结果。
