不能直接在主节点执行SAVE或BGSAVE备份：SAVE会阻塞请求，BGSAVE增加内存压力且无法保证集群状态一致性；应选同步完成、未迁移槽的从节点，停复制后BGSAVE，再恢复复制关系，并规范命名、记录元数据、校验RDB完整性。
为什么不能直接在主节点上执行 SAVE 或 BGSAVE 做全量备份
主节点执行 SAVE 会阻塞所有请求，BGSAVE 虽然用子进程避免阻塞，但会显著增加内存拷贝压力（尤其是写密集场景），还可能触发 swap 或 OOM。更关键的是：RDB 文件生成时刻与集群状态不一致——槽位迁移中、从节点同步延迟时，备份出来的数据无法反映真实分片逻辑。
如何利用从节点做无锁 RDB 备份
核心思路是把备份动作“卸载”到只读从节点，避开主节点负载和一致性风险。前提是该从节点已完全同步（redis-cli -h <em>slave_ip</em> -p <em>port</em> info replication | grep sync_state 返回 sync_state:ok），且未参与任何槽迁移。
- 先停掉该从节点的复制（
redis-cli -h <em>slave_ip</em> -p <em>port</em> replicaof no one），让它变成独立实例，避免备份过程中被主节点覆盖 RDB - 再执行
BGSAVE，此时它不再接收写入，RDB 快照严格对应最后一次完整同步状态 - 备份完成后，用
replicaof <em>master_ip</em> <em>master_port</em>恢复复制关系，Redis 会自动以 PSYNC 方式续传增量 - 注意：不要在多个从节点上并发执行此流程，否则主节点的复制缓冲区（
repl-backlog）可能被快速撑满，导致部分从节点被迫全量重同步
备份文件命名与元数据必须包含集群上下文
单纯保存 dump.rdb 没有意义——你无法知道它来自哪个节点、对应哪些槽、属于哪个集群配置纪元（cluster_epoch）。恢复时极易错配。
- 文件名建议格式：
redis-cluster-node-<em>{ip}</em>-<em>{port}</em>-<em>{epoch}</em>-<em>{timestamp}</em>.rdb - 用
redis-cli -h <em>slave_ip</em> -p <em>port</em> cluster nodes和info server输出重定向到同目录下的meta.json，记录节点 ID、槽范围、配置纪元、uptime、run_id - 若使用脚本批量备份，务必校验
cluster_state:ok和connected_slaves:0（确保它是孤立从节点，非中间转发节点）
备份后验证 RDB 完整性比压缩更重要
RDB 文件损坏往往在恢复时才暴露，但那时已错过修复窗口。别跳过校验步骤。
- 用 Redis 自带工具：
redis-check-rdb <em>backup_file.rdb</em>，输出Checksum OK才算通过 - 不要依赖文件大小判断——空实例或大量过期键会导致 RDB 极小；也不要依赖
file命令识别类型，RDB 是自定义二进制格式，file只能返回 “data” - 如果集群启用了 RDB 加密（
requirepass+rdb-key配置），校验时需加--key参数，否则报Invalid RDB magic number
真正麻烦的是跨版本兼容性：4.0 的 RDB 无法被 7.0 的 redis-check-rdb 解析，反过来也不行。备份前务必确认校验工具版本与目标恢复环境一致。
