Redis集群无法全局执行bgsave，需逐个主节点操作；定时持久化须单独配置各节点save规则；备份命名须含主机名与精确时间戳以防覆盖；恢复前需用同版本从节点验证RDB兼容性。
Redis集群不能直接对整个集群执行bgsave
因为Redis集群（Cluster）本质是多个独立的Redis实例分片运行，没有全局主节点或统一控制面。所谓“集群备份”，其实是对每个主节点（master）单独操作。你登录任意一个节点执行bgsave，只会影响该节点的数据，其他主节点完全不受影响——这点常被误以为“集群会同步触发备份”。
实操建议：
- 先用
redis-cli -c -h {host} -p {port} cluster nodes查出所有主节点的IP和端口，注意过滤掉带master标记且无fail或handshake状态的行 - 逐个连接主节点，执行
bgsave；不要在从节点上执行，它默认不开启save配置，且bgsave可能失败并报错Background save already in progress - 检查每个节点的
dir和dbfilename配置是否一致，否则生成的.rdb文件路径不同，后续集中归档容易漏
定时持久化必须在每个主节点单独配置save规则
Redis的RDB定时触发依赖save配置项（如save 900 1），但这个配置只作用于当前实例。集群中10个主节点，就得在10份redis.conf里分别写好、重启生效——不存在“集群级配置下发”机制。
常见错误现象：
- 只改了其中一个节点的
save，结果只有那个节点定期生成.rdb，其余节点靠appendonly yes撑着，AOF重写又没开auto-aof-rewrite-percentage，磁盘悄悄涨满 - 用Ansible批量改配置时，忘了
redis-server进程未重启，配置实际未加载，CONFIG GET save看到的还是旧值 - 某些云托管Redis服务（如阿里云Tair、腾讯云CKV）根本不开放
save配置修改权限，此时只能靠外部脚本+bgsave+scp拉取
备份文件命名与时间戳必须人工对齐，否则恢复时极易混淆
每个主节点的bgsave是异步执行，完成时间有毫秒级差异；若用默认dump.rdb名，多个节点备份到同一目录下会相互覆盖。更麻烦的是：恢复时若拿错节点的RDB去加载，轻则数据错乱，重则集群CLUSTER DOWN。
实操建议：
- 执行
bgsave前，先用CONFIG SET dbfilename "dump_$(hostname -s)_$(date +%Y%m%d_%H%M%S).rdb"动态改名（需确保rename-command CONFIG ""没禁用） - 或者用脚本封装：
redis-cli -h $ip -p $port bgsave && sleep 1 && scp $ip:/var/lib/redis/dump.rdb ./backup/dump_${ip}_${port}_$(date +%s).rdb - 避免用
date +%Y%m%d这种日粒度时间戳——同一天多次备份会冲突；必须精确到秒或毫秒
从节点不参与备份，但它是验证备份有效性的关键环节
很多人只备份主节点，却忽略：RDB文件能否被正确加载，得看目标实例的Redis版本、架构（ARM/x86）、以及是否启用了模块（如RedisJSON）。而最省事的验证方式，就是把刚备份的RDB复制到一个同版本的从节点，停掉它的复制，用redis-server --dbfilename xxx.rdb /path/to/redis.conf启动，再redis-cli INFO keyspace核对key数量。
容易踩的坑：
- 用Redis 7.0备份的RDB，在Redis 6.2上直接启动会报错
Wrong RDB version，且无法降级兼容 - 集群模式下，RDB里存的是slot映射关系，如果恢复到非集群实例（
cluster-enabled no），会启动失败并提示Invalid argument - 备份时节点正在做
CLUSTER SETSLOT ... MIGRATING，RDB可能包含不完整迁移状态，恢复后CLUSTER NODES显示异常
备份不是点一下就完的事，真正难的是让每个主节点的RDB在时间、命名、版本、上下文上保持可追溯、可验证、可替换。少一步校验，上线那天就多一分心跳停顿。
