在 Redis 7.0 的 Multi-part AOF 持久化机制中，base 文件绝非可选的备份文件，而是整个数据恢复链的基石。缺少 base 文件，所有 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 开始生效，并覆盖哪些写操作的时间窗口。
- 举例：
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引用该 base，再结合CONFIG SET aof-rewrite-incremental-fsync yes等参数观察清理行为。
最容易被忽视的一点是：manifest 文件本身不存储数据，但一旦损坏或被篡改，整个 AOF 恢复逻辑将失去坐标系。它比任何一个 base 或 incr 都更为关键，却常被运维脚本忽略备份或权限控制。这一点值得每位 Redis 运维人员牢记。
