Redis 7.2 不支持原生 AOF 多文件增量结构，仅维护单个 appendonly.aof 文件；启用 aof-use-rdb-preamble 后为 RDB 头+命令尾的混合单文件格式，多文件会破坏加载、校验与复制一致性。
Redis 7.2 中不存在真正意义上的“AOF 增量文件”管理——你配置的多个 appendonly.aof 类文件不会被自动创建或轮转，实际运行中只会生成并维护单个 AOF 文件（默认为 appendonly.aof），除非你禁用 aof-use-rdb-preamble 并自行实现切片逻辑（不推荐且不可靠）。
为什么 Redis 7.2 不支持原生 AOF 多文件增量结构
所谓“AOF 增量文件”是旧版文档或误读导致的常见误解。Redis 7.0+ 启用 aof-use-rdb-preamble yes（7.2 默认开启）后，AOF 重写输出的是一个混合格式文件：RDB 快照头 + 尾部纯文本命令，它仍是单个线性文件。该设计放弃旧版多文件（base + incr + manifest）架构，原因包括：
- 启动时
redis-server只加载appendfilename指定的单个文件，不识别任何编号后缀（如appendonly.001.aof） -
redis-check-aof工具无法跨文件校验完整性，也无法修复断裂的“增量链” - 主从复制依赖全局
REPLCONF ACK偏移量，多文件会破坏偏移连续性，导致同步错乱 - 即使强行修改配置或脚本生成多个 AOF 片段，
BGREWRITEAOF仍会覆盖为单一文件
真正可控的 AOF “增量”行为：靠文件截断 + 外部脚本
如果你需要类增量备份效果（例如每小时备份新增日志），必须绕过 Redis 内部机制，用外部脚本按字节偏移提取新增内容。关键点：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 记录上一次备份结束位置（
last_position.txt），用stat -c %s appendonly.aof获取当前大小 - 当
CURRENT_SIZE ，大概率发生了 <code>BGREWRITEAOF—— 此时需重置偏移为 0，并等待重写完成（加sleep或轮询redis-cli info persistence | grep aof_rewrite_in_progress） - 用
dd if=appendonly.aof of=incremental.aof bs=1 skip=$LAST_POS count=$((CURRENT_SIZE-LAST_POS))提取增量段 - 注意：若 AOF 正在重写，
appendonly.aof可能被临时替换为appendonly.aof.tmp，脚本需兼容此状态
避免踩坑：重写触发与文件轮转的真相
很多人以为 auto-aof-rewrite-percentage 触发后会“生成新文件、保留旧文件”，实际并非如此：
- 重写完成后，Redis 直接原子性地将临时文件重命名为
appendonly.aof，**旧文件被直接 unlink（删除）**，不会保留 -
CONFIG SET appendonly no && CONFIG SET appendonly yes确实能强制轮转（关闭再开启 AOF），但会导致短暂丢失写入（因 AOF 缓冲区未落盘），生产环境慎用 - 磁盘空间不会“分摊”，反而可能因重写期间双倍写入（原文件 + 新文件）造成瞬时 IO 峰值
- 若想减小重写压力，应调大
aof-rewrite-incremental-fsync（默认 4MB），降低 fsync 频次，而非幻想文件拆分
最易被忽略的一点：AOF 文件体积增长 ≠ 数据量增长。大量过期 key、被覆盖的 key、无效命令都会让 AOF 膨胀，但重写会清理它们——所以监控 aof_current_size 和 aof_base_size 的比值比单纯看文件大小更有意义。
