开源Redis集群RDB文件备份至S3的最优策略咨询

一、最优备份策略：无需上传全部6个RDB #

你不需要把6个节点的RDB都传到S3，只需要备份每个主节点的最新RDB文件即可，原因如下：

• 从节点的数据完全同步自对应主节点，属于冗余副本，备份主节点RDB就足够覆盖全量数据
• 减少S3存储占用和备份带宽消耗，降低成本

具体执行步骤：

• 统一触发主节点快照：不要依赖自动快照的随机时间，而是在备份窗口手动给所有主节点发送BGSAVE命令（比如通过脚本批量执行），确保各主节点的RDB生成时间尽可能接近，减少跨分片的数据不一致
• 规范RDB命名：给每个主节点的RDB文件命名时带上节点ID、时间戳，比如redis-master-{node-id}-202405201200.rdb，方便后续快速识别对应节点
• 同步哈希槽元数据：备份RDB的同时，执行redis-cli cluster nodes命令，导出集群的哈希槽分配信息（哪个主节点负责哪些槽），将这份元数据和RDB文件一起上传到S3，这是后续恢复的关键
• S3归档策略：按日期或版本组织备份目录（比如s3://your-bucket/redis-backups/20240520/），保留多版本备份（如最近7天每日备份、最近30天每周备份），同时开启S3版本控制防止误删，设置生命周期规则自动清理过期备份

二、灾难恢复：如何选择RDB文件 #

当集群拓扑变化（比如从节点升主），恢复时核心是匹配RDB与对应的哈希槽范围，具体步骤：

1. 准备新集群：重新搭建3主3从的Redis集群（节点ID可以和原集群不同）
2. 匹配RDB与哈希槽：拿出备份的哈希槽元数据，找到每个主节点RDB对应的哈希槽范围
3. 替换RDB并启动节点：停止新集群的主节点，将对应的RDB文件放到节点的数据目录，修改权限后启动节点
4. 恢复哈希槽分配：根据备份的元数据，用redis-cli cluster addslots命令给每个主节点分配对应的哈希槽，完成后启动从节点并让它们同步对应主节点的数据
5. 验证数据：执行redis-cli cluster check确认槽位分配正确，再抽样检查数据完整性

注意：恢复时不需要使用从节点的RDB，主节点恢复完成后，从节点可以通过全量同步（PSYNC）获取最新数据，避免额外的备份管理成本

额外注意事项 #

• 备份前务必确认BGSAVE执行成功：检查节点日志中的Background saving terminated successfully条目，避免上传不完整的RDB文件
• 定期测试恢复流程：每月模拟一次灾难恢复，确保备份文件和元数据可用，避免真正故障时手忙脚乱
• 加密备份数据：在S3端开启服务器端加密（SSE），或者上传前对RDB文件加密，保障数据安全

内容的提问来源于stack exchange，提问作者Ankit Sahay