aof是redis唯一原生支持增量备份的机制，因其以追加方式记录每条写命令，天然具备“只存变化”特性；rdb本质为全量快照，不支持增量，所谓“rdb+增量”仅为组合策略而非其自身能力。

AOF 是 Redis 唯一原生支持增量备份的持久化机制。RDB 本质是全量快照，不支持增量；所谓“RDB + 增量”只是组合策略，并非 RDB 自身能力。

为什么只有 AOF 算真正的增量备份

AOF 文件记录的是每一条写命令（如 SET、DEL、INCR），以追加方式持续写入，天然具备“只存变化”的特性。只要没触发重写，新增内容就直接 append 到文件末尾——这和传统数据库的 WAL 日志逻辑一致。

而 RDB 每次生成都是完整内存快照，即使只改了一个 key，也会 dump 全库。所谓“diff RDB”需要手动解析二进制结构，既不可靠也无官方支持，生产环境应避免。

• appendfsync everysec 是最常用配置：每秒刷盘一次，兼顾性能与数据丢失窗口
• appendfsync always 严格保证不丢命令，但吞吐明显下降，一般不用
• appendfsync no 依赖 OS 刷盘，风险高，仅测试可用

AOF 增量备份的实操要点

直接备份整个 appendonly.aof 文件不是好办法——它会不断增长，且重写后位置重置，导致上次备份点失效。

真正可行的增量切片方案依赖两个关键动作：

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• 用 stat -c %s 获取当前 AOF 文件大小，作为“已备份截止位置”
• 用 dd if=... skip=... count=... 提取新增字节段，而非复制全文件
• 每次备份后，把新文件大小写入 last_position.txt，供下次读取
• 若发现当前大小 ≤ 上次位置，说明发生了 BGREWRITEAOF，需重置为 0 并等待重写完成

别忽略 AOF 重写带来的坑

auto-aof-rewrite-percentage 和 auto-aof-rewrite-min-size 触发重写时，Redis 会 fork 子进程生成新 AOF 文件，然后原子替换旧文件。此时原文件被 unlink，但仍在被备份脚本持有句柄——dd 仍能读到旧内容，但位置偏移已失效。

所以必须检测重写发生：除了比对文件大小，更稳妥的是监听 INFO persistence 中的 aof_current_size 和 aof_base_size，或用 redis-cli CONFIG GET auto-aof-rewrite* 动态确认策略。

重写期间不能盲目 skip，否则增量段会漏掉重写前未落盘的命令。

真正落地时，AOF 增量不是开个开关就行，得配合位置追踪、重写感知、文件句柄管理——这些细节稍有疏忽，备份就变成“看起来在跑，其实早断了”。