redis集群备份需对每个主节点单独执行bgsave，确认rdb路径并同步nodes.conf；恢复时须停集群、关aof、逐节点替换rdb后按序启动。
直接用 BGSAVE 对集群每个节点单独备份就行
Redis 集群是去中心化架构，没有主从复制意义上的“主节点全量备份”概念。每个分片（shard）由一个主节点独立负责，BGSAVE 必须在每个主节点上分别执行。不能只连到任意一个节点就备份全部数据——集群模式下 redis-cli 的默认行为是自动重定向，但 BGSAVE 不支持跨槽位传播，它只作用于当前连接的节点内存。
常见错误现象：在集群任一节点执行 BGSAVE 后，以为整个集群已备份，结果恢复时发现只有该节点对应槽位的数据存在，其余槽位为空。
- 先用
redis-cli -c -h {host} -p {port} cluster nodes列出所有主节点（标记为master且无fail状态） - 对每个主节点 IP+端口组合，单独执行
redis-cli -h {ip} -p {port} -a {password} BGSAVE - 确认每个节点都返回
Background saving started，再通过INFO persistence | grep rdb_bgsave_in_progress轮询检查是否全部完成
dump.rdb 文件路径必须手动确认，不能依赖默认值
Redis 6.0 集群节点通常使用独立配置文件启动，dir 和 dbfilename 很可能被显式指定，且各节点路径不一致。比如节点 7001 的 dir 是 /data/redis7001，而 7002 是 /data/redis7002。直接假设所有节点都用 /var/lib/redis/dump.rdb 会导致备份遗漏。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 对每个主节点运行
CONFIG GET dir和CONFIG GET dbfilename获取真实路径 - 注意
dir值末尾是否带斜杠；若为/data/redis7001/，则完整 RDB 路径是/data/redis7001/dump.rdb；若为/data/redis7001，则需拼接成/data/redis7001/dump.rdb - 确保备份脚本有权限读取这些路径，尤其当 Redis 以
redis用户运行而备份脚本以root运行时，可能因 SELinux 或目录权限失败
恢复时必须停掉整个集群，逐节点替换再启动
集群恢复不是“重启单个节点”那么简单。RDB 恢复要求节点启动前，其 dump.rdb 已就位；如果先启动节点，它会加载空 RDB 或旧 RDB，再加入集群后同步其他节点数据，导致备份被覆盖。
- 用
redis-cli -c -h {any-node} -p {port} -a {pwd} CLUSTER NODES确认所有节点状态为connected，再逐个执行redis-cli -h {ip} -p {port} -a {pwd} shutdown save安全关闭 - 关闭后，将对应备份的
dump.rdb文件拷贝到每个节点的dir目录下，覆盖原文件（注意保留原文件权限和属主，如chown redis:redis dump.rdb） - 按拓扑顺序启动：先启所有主节点，等它们
CLUSTER NODES显示自身为master且connected，再启从节点；避免从节点启动过早、拉取到旧数据
别忽略 AOF 开关状态，否则 RDB 可能被跳过
Redis 启动时加载策略是：如果 appendonly yes 且 appendonly.aof 存在，则优先加载 AOF；RDB 被完全忽略。生产集群常开启 AOF 增量持久化，但做 RDB 全量恢复时，若不处理 AOF，备份就白做了。
- 恢复前检查每个节点配置：
CONFIG GET appendonly，若返回yes，必须临时关闭：CONFIG SET appendonly no，再CONFIG REWRITE写入配置文件 - 同时删掉或重命名该节点的
appendonly.aof文件（路径由CONFIG GET appendfilename确认），防止启动时被自动加载 - 恢复成功后，可重新开启 AOF，但首次重写建议用
BGREWRITEAOF，避免从 RDB 重建日志引发延迟
最易被忽略的一点：集群槽位映射信息（nodes.conf）不随 RDB 备份。如果恢复时节点 ID 发生变化（例如重装系统、容器重建），即使 RDB 数据完整，集群也无法识别槽位归属。务必同步备份每个节点的 nodes.conf 文件，并在恢复后校验 CLUSTER NODES 输出的 node ID 是否与备份时一致。
