集群备份的特点

集群没有一次备份全集群的官方工具，备份必须按节点逐个做：每个节点各自执行 BGSAVE 生成 RDB，或在 AOF 模式下整目录拷贝 appendonlydir，同时把节点的 nodes.conf 与 redis.conf 一并收走。nodes.conf 保存节点 ID、槽区间与纪元，是恢复拓扑的关键，只备份数据文件恢复后槽分布对不上，客户端路由会乱。

基本信息

典型使用场景

• 每日或每周做一次全集群离线备份，用于误删与逻辑损坏的兜底
• 大版本升级或机房迁移前留一份可回退的完整现场
• 灾备演练时按原拓扑重组集群，验证备份真的能起来
• 单节点快照损坏时用其他节点的备份交叉验证问题范围
• 安全审计要求提供数据资产的定期备份记录与校验结果

逐节点备份示例

for P in 7000 7001 7002; do redis-cli -p $P BGSAVE; done      # 逐节点触发快照
redis-cli -p 7000 INFO persistence | grep rdb_bgsave_in_progress  # 等待进度归零
redis-cli -p 7000 CLUSTER SLOTS > slots-before.txt            # 记录槽分布便于还原
cp /data/redis-7000/nodes-7000.conf ./nodes-7000.conf         # 拓扑文件单独留存
redis-check-rdb /data/redis-7000/dump.rdb                     # 校验快照完整性
tar czf backup-$(date +%F).tgz /data/redis-7000 /data/redis-7001 /data/redis-7002

备份内容与用途

恢复演练顺序

• 先在隔离网段拉起一个临时实例，用节点单独的配置文件与数据目录启动，确认能正常加载
• 核对启动日志里的加载来源：是载入了快照还是空库启动，避免开出一个看似正常但没数据的节点
• 比对 DBSIZE 与备份时记录的键总数，再从几个业务维度抽抽样键确认取值正确
• 确认节点 ID 与 nodes.conf 中的记录一致，否则节点会以新身份重新加入，槽信息全部丢失
• 整套流程走通后再更新文档与值班手册，把演练耗时和踩到的坑记进去