Redis集群备份需规避RDB全量耗时与AOF重写陷阱，优先采用PSYNC2复制流增量捕获，并注意AOF大小获取、权限一致及节点错峰备份三细节。
Redis集群备份文件过大，直接RDB全量备份不可行
集群环境下每个节点都生成独立的 RDB 文件，节点数一多、数据一涨，单次全量备份就可能达几十GB，不仅耗时长、IO压力大，还容易拖垮主从同步或触发超时。更关键的是：RDB 本身不带时间戳和变更标记，无法直接“diff”出增量——所谓“定时对比两个RDB取差异”，在生产中基本是伪命题，既不准又慢，还无法还原中间状态。
用AOF切片做增量备份，但必须绕过重写陷阱
集群中每个master节点开启 appendonly yes 后，appendonly.aof 天然是增量日志。但直接备份整个AOF不行：它会被 BGREWRITEAOF 清空重写，导致位置偏移错乱。所以必须配合位置记录+重写感知：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 每次备份前先用
redis-cli info persistence | grep aof_current_size拿当前AOF大小 - 读取上次保存的偏移量（如存于
/backup/last_pos.txt），若当前大小 ≤ 上次值，说明发生了重写，需重置为0并等待重写完成 - 用
dd if=appendonly.aof of=incremental_20260713.aof bs=1 skip=$LAST_POS count=$((CURR-CURR))提取新增字节 - 备份后立即更新
last_pos.txt为当前大小，而非文件末尾字节位置（避免重写后误跳）
监听复制流（replication stream）是更可靠的增量源
相比AOF，PSYNC2 协议下的复制流更稳定：它不依赖本地磁盘文件，不被重写干扰，且天然支持断点续传。工具如 redis-streamer 或自研 redis-cli --rdb - + 解析器可捕获命令流：
- 启动监听时指定
runid和offset，从上次中断处继续 - 每条命令以 RESP 格式到达，可过滤只保留
SET、HSET、DEL等写操作 - 输出为带时间戳的文本或二进制流，便于按小时切片归档
- 注意：需确保主节点
repl-backlog-size足够大（建议 ≥ 512mb），否则断连太久会丢失增量
备份脚本里最容易被忽略的三个细节
很多脚本跑着跑着就失效，不是逻辑错，而是栽在环境细节上：
-
stat -c %s在某些旧版busybox中不支持，应改用wc -c < file获取AOF大小 - 备份路径权限必须与
redis用户一致，否则BGREWRITEAOF后新AOF可能属主错误，导致下轮备份读不到 - 集群各节点备份时间不能完全同步——建议错开5~10分钟，避免所有master同时触发AOF重写，引发IO雪崩
