redis 7.0 multi-part aof中base文件是恢复起点且不可缺失，本质为rdb格式快照，体积小、加载快；需用redis-check-rdb校验，删除则启动报错；manifest文件调度所有base与incr依赖关系，损坏将导致恢复失败。
Redis 7.0 的 Multi-part AOF 中，base 文件不是“可选备份”，而是整个 AOF 恢复链的起点——没有它，所有 incr 文件都不可用。
base 文件本质是 RDB 快照，不是 AOF 文本日志
它默认以 RDB 格式序列化当前全量数据（如 appendonly.aof.1.base.rdb），体积小、加载快。这点和旧版 AOF rewrite 生成的纯文本大文件完全不同。
- 不能用
redis-check-aof检查或修复base文件——得用redis-check-rdb - 它不记录命令，只记录状态；所以无法从中提取某次
SET的时间点，但能秒级加载出完整数据集 - 若你手动删掉
base文件，Redis 启动时会报错：Failed to open base file: No such file or directory，直接拒绝恢复
incr 文件依赖 base 文件的生效范围，不是简单按时间顺序拼接
manifest 文件（appendonly.aof.manifest）才是关键调度器：它明确声明每个 incr 文件从哪个 base 开始生效、覆盖哪些写操作时间窗口。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 比如
appendonly.aof.1.base.rdb对应时间戳T1，而incr-00000001.aof标记为from_base=1, start_offset=12345，说明它只承接该 base 之后的增量 - 删除中间某个
incr文件，Redis 不会崩溃，而是跳过它，用前一个incr的末尾状态 + 下一个incr的开头继续恢复 - 但若删掉的是最后一个
incr，Redis 会认为“最新状态缺失”，可能回退到上一个完整组合（即上一个base+ 其全部有效incr），导致丢失部分写入
base 文件只允许存在一个，且不会自动轮转
Multi-part AOF 设计上限制同一时刻仅有一个活跃 base 文件——它代表当前数据基线，其余都是围绕它的增量补丁。
- 重写触发后，新
base生成（如.2.base.rdb），旧base并不立即删除，而是等所有依赖它的incr都被合并或归档后，由 Redis 异步清理 - 你不能手动把
.1.base.rdb改名为.2.base.rdb来“欺骗”系统——manifest 文件校验失败会导致启动失败 - 如果磁盘空间紧张，不要直接
rm旧base；应先确认 manifest 中已无任何incr引用它，再配合CONFIG SET aof-rewrite-incremental-fsync yes等参数观察清理行为
真正容易被忽略的点在于：manifest 文件本身不存数据，但一旦损坏或被篡改，整个 AOF 恢复逻辑就失去坐标系——它比任何一个 base 或 incr 都更关键，却最常被运维脚本忽略备份或权限控制。
