必须对每个master节点单独执行BGSAVE，因Redis集群将16384个slot分散在多个master上，仅备份一个节点会导致对应slot数据永久丢失，恢复后出现slot无主、CLUSTER NODES异常；需脚本并发触发各master的BGSAVE并轮询确认完成，命名须含IP、端口及秒级时间戳以防覆盖，恢复前须校验RDB完整性、清空nodes.conf与AOF，并验证slot分配与key路由。
必须对每个 master 节点单独执行 BGSAVE，且所有备份需在极短时间内完成，否则无法保证集群级一致性。
为什么不能只备份一个节点？
Redis Cluster 把 16384 个 slot 分散在多个 master 上，dump.rdb 只包含本节点负责的 slot 数据。漏掉任意一个 master，恢复后就会丢数据——不是“部分丢失”，而是“整个 slot 范围不可用”。常见错误是误以为备份某个节点就能代表全量，结果恢复时 CLUSTER NODES 显示大量 slot 无主。
如何协调多个 master 的 BGSAVE？
靠人工逐个登录执行 redis-cli -h <master-ip> -p <port> BGSAVE</port></master-ip> 不现实，容易超时、遗漏或顺序错乱。推荐用脚本统一触发：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 先用
redis-cli --cluster check获取当前 master 列表（过滤出master角色且connected状态的节点） - 对每个 master 并发调用
redis-cli -h $ip -p $port BGSAVE，但要加--raw和超时控制（如timeout 30s）防止卡死 - 用
redis-cli -h $ip -p $port INFO persistence | grep rdb_bgsave_in_progress轮询确认全部完成，最长等待时间建议设为2 * max_rdb_save_time（参考latest_fork_usec历史值）
备份文件命名与归档要注意什么？
多个 master 的 dump.rdb 如果都叫同一名字，直接 rsync 到同一目录会覆盖。必须带上下文标识：
- 文件名格式建议：
dump-<master-ip>-<port>-<unix-timestamp>.rdb</unix-timestamp></port></master-ip> - 不要用
date +%Y%m%d%H%M—— 多节点触发时间差可能达秒级，导致同名；用$(date +%s)更稳妥 - 归档前务必运行
redis-check-rdb验证每个文件，返回非 0 就跳过上传，避免存入损坏快照 - 本地磁盘只保留最近 2 次备份，其余立即推到对象存储（如
aws s3 cp dump-10.0.1.10-7001-1720837680.rdb s3://backup-redis-cluster/20260713/）
恢复时最容易被忽略的检查点
集群恢复不是把 RDB 文件拷过去再启动就行。必须确认三件事：
- 所有 master 节点的
dir配置指向同一路径，且该路径下存在对应节点的 RDB 文件（名字要严格匹配dbfilename） - 启动前清空
nodes.conf和appendonly.aof（如果启用了 AOF），否则 Redis 可能拒绝加载 RDB - 集群重建后，用
redis-cli --cluster check验证 slot 分配是否完整，再用CLUSTER KEYSLOT "testkey"手动查几个 key 确认路由正常
真正麻烦的从来不是备份动作本身，而是 master 节点间状态不同步导致的 slot 缺失——这个坑往往在恢复后几小时才暴露，因为客户端请求刚好落到缺失 slot 的区间。
