不能手动清理 incr-*.aof 文件，因为 redis 启动严格依赖 manifest 文件中记录的完整文件清单；手动删除 incr 文件而未同步更新 manifest 会导致启动失败或静默丢数据，唯一安全方式是依赖 redis 自动异步清理已归档的 history 类文件。
不能手动清理 incr-*.aof 文件 —— Redis 7.0 不允许、也不支持人工删 incr 文件，否则极易导致启动失败或数据丢失。
为什么直接 rm incr-*.aof 会出事
Redis 启动时严格依赖 appendonly.aof.manifest 中的文件清单加载 AOF 链。一旦你手动删掉某个 incr-*.aof，但 manifest 里仍记录着它，Redis 就会尝试打开这个不存在的文件，报错 Failed to open incr file: No such file or directory，直接中止启动。
反过来，如果你删了 manifest 里的某行，却没删对应文件，Redis 就会跳过该增量，导致最近写入全部丢失 —— 这种“静默丢数据”比启动失败更危险。
manifest 文件不是静态快照，而是实时调度器：每次新生成 incr 或完成 base 重写，Redis 都会原子重写 manifest。手动干预等于绕过整个一致性保障机制。
真正安全的清理方式只有两种
Redis 本身会自动清理无引用的 incr 文件，前提是满足以下全部条件：
-
CONFIG GET aof-use-rdb-preamble返回no（确认启用纯 multi-part AOF） -
CONFIG GET appenddirname指向独立目录，且该目录下没有混入dump.rdb或其他非 AOF 文件 - 所有被标记为
history的 incr 文件，已在 manifest 中被正确降级（type 字段变为history），且无任何 active incr 引用该 base - 磁盘空间压力未触发静默降级（即
CONFIG GET aof-use-rdb-preamble仍为no，且ls $APPENDDIR/incr-*.aof能列出预期文件）
满足后，Redis 主进程会在后台异步删除已归档的 history 类文件。你唯一能做的，是等待并观察：redis-cli INFO persistence | grep aof_current_rewrite_time_sec 为 0，且 ls $APPENDDIR/ 中不再出现长期未更新的 incr-*.aof。
运维脚本最容易踩的坑
很多团队用通配符清理脚本，比如：
find /var/lib/redis/appendonlydir -name "*.aof" -mtime +7 -delete
这会误杀 manifest.aof 或正在写的 incr-*.aof，因为：
-
manifest.aof也是*.aof，且修改时间可能比某些 incr 更早 -
incr-*.aof文件名不带时间戳，-mtime判断完全失效 - 若
appenddirname配置错误（如和dir相同），该命令还会顺手干掉dump.rdb
正确做法是：只监控 appenddirname 目录剩余空间，不清理；备份时用 cp -r $APPENDDIR ./backup_$(date +%s) 整体拷贝，且校验 sha256sum $APPENDDIR/appendonly.aof.manifest。
如果已经误删了 incr 文件怎么办
立刻停止写入：redis-cli CONFIG SET appendonly no；然后检查 manifest 内容是否完整（每行格式必须是 type filename seq，seq 单调递增，无重复或跳号）；最后执行 redis-cli BGREWRITEAOF —— Redis 会重建 base 和全新 incr 链，并重写 manifest。注意：这会导致一次全量重写开销，且中间写入会暂存于内存（但不再走旧版 aof_rewrite_buf）。
最常被忽略的一点：manifest.aof 没有备份，就等于没有恢复能力。它体积小、更新频次低，但必须单独纳入备份策略，不能依赖“定期 rsync 整个目录”这种粗粒度操作。
