Redis备份需RDB快照与AOF日志协同+主从复制+自动化验证。RDB按写入节奏设bgsave策略；AOF选everysec并定期重写；从节点只读且配RDB/AOF；脚本自动备份、校验、恢复测试并告警。

Redis 数据备份不能只靠一种方式撑全场。定时快照适合快速恢复和资源节省，热备份则保障服务不中断、数据不丢。两者配合使用，才是生产环境里真正稳妥的做法。

定时快照（RDB）怎么设才合理

RDB 是 Redis 默认的备份机制，本质是把内存数据在某个时间点“拍照”存成 dump.rdb 文件。关键不是“要不要用”，而是“什么时候拍、拍多频繁”。

• 别用默认的 save 900 1（15分钟内改1次就拍），业务写入稍一密集就会频繁触发，加重 fork 开销
• 根据实际写入节奏调整：比如每小时最多改几百个 key，可设为 save 3600 100（1小时改100次才拍）
• 始终用 bgsave 手动触发，避免 save 命令阻塞主线程
• 快照文件路径建议单独配置，例如 dir /data/redis-backup，方便统一管理与权限隔离

AOF 日志作为热备份的基础

AOF 不是替代 RDB，而是补它的短板——数据丢失窗口。它把每个写命令追加进日志，重启时重放即可还原状态。但直接全量开启 AOF 会影响性能，所以重点在策略选择：

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• everysec 是生产首选：命令先写缓冲区，每秒刷盘一次，兼顾安全性与吞吐
• 禁用 always（每次写都落盘），除非你明确接受写性能下降 3–5 倍
• 定期执行 bgrewriteaof，自动压缩 AOF 文件，避免体积无限膨胀
• 可以同时开启 RDB + AOF，Redis 启动时优先用 AOF 恢复（更完整），RDB 仅作辅助或归档用途

主从复制实现真正的热备份

单机 RDB/AOF 再可靠，也无法应对硬件故障或误操作。主从复制让一台从节点实时同步主节点数据，既是高可用基础，也是最实用的热备份方案：

• 从节点配置 slave-read-only yes，防止误写污染数据
• 主节点开启 requirepass 和从节点配置 masterauth，保证复制链路安全
• 定期用 info replication 检查 master_link_status: up 和 slave_repl_offset 是否接近主节点 offset
• 从节点本身也可配置自己的 RDB/AOF，相当于“备份的备份”，进一步降低风险

自动化与验证不能省

再好的策略，没人执行或没验证过，等于没做。备份必须可落地、可验证：

• 用 shell 脚本封装 bgsave + rsync 到远程存储，并加入时间戳命名，例如 dump_$(date +%Y%m%d_%H%M).rdb
• 每天凌晨低峰期执行一次恢复测试：拉起临时 Redis 实例，加载最新 RDB 或重放 AOF，检查 key 数量与关键业务数据是否一致
• 备份文件加上校验码（如 sha256sum），存一份 checksum 到独立位置，防止备份文件静默损坏
• 监控备份任务退出码，失败时通过企业微信或钉钉推送告警，别等出事才发现脚本早挂了