Redis启动提示Bad file format reading the append only file，AOF恢复操作指南

本文于 2026-09-15 08:20 更新，部分内容具有时效性，如有失效，请留言

Redis启用AOF持久化后，如果启动日志出现 Bad file format reading the append only file，表示加载器在AOF中遇到无法解析的内容。它可能来自磁盘写满、异常断电、底层存储问题或人工修改，处理重点是保住原始证据并确认可接受的数据丢失边界。

不要在唯一一份AOF上直接执行自动修复。 Redis官方说明，修复工具可能丢弃无效点到文件末尾的全部命令，损失可能远大于最后一条记录。

先确认AOF版本布局与实际路径

先从systemd或容器日志读取Redis给出的文件路径：

sudo journalctl -u redis-server -b -n 150 --no-pager
sudo systemctl status redis-server --no-pager -l

再核对配置中的持久化目录：

redis-server --version
grep -E '^[[:space:]]*(dir|appendonly|appendfilename|appenddirname)[[:space:]]' /etc/redis/redis.conf

Redis 7及更新版本使用多部分AOF：基础文件和增量文件位于专用目录，由manifest跟踪；旧版本通常是单个AOF文件。备份时必须按当前版本复制完整AOF目录或完整单文件，不能只拿走最近的增量片段。

若Redis仍在反复启动或有其他进程写入，先停止对应实例：

sudo systemctl stop redis-server
sudo systemctl is-active redis-server

确认停止后，保留权限、时间戳和全部文件。以下路径仅为示例，应替换为日志和配置确认的实际位置：

sudo cp -a /var/lib/redis/appendonlydir \
  /var/lib/redis/appendonlydir.backup-$(date +%Y%m%d-%H%M%S)
sudo sync

同时检查磁盘与内核日志，避免修复后再次损坏：

df -h /var/lib/redis
df -i /var/lib/redis
sudo journalctl -k -b --no-pager | tail -n 100

如果存在I/O错误或文件系统只读，先处理存储故障；在不可靠磁盘上继续修复和重写会扩大损失。

先针对日志指明的AOF或manifest运行检查，不加 --fix：

sudo -u redis redis-check-aof /var/lib/redis/appendonlydir/appendonly.aof.manifest

旧版单文件布局则传入实际AOF文件：

sudo -u redis redis-check-aof /var/lib/redis/appendonly.aof

工具输出会帮助定位最后有效位置和损坏范围。还应将文件大小、校验结果与最近备份、复制节点或业务审计日志对照。中间位置出现无效字节，与断电造成的末尾截断不是同一种风险。 前者可能导致自动修复丢弃其后的大量有效命令。

数据价值较高时，优先从经过验证的备份、健康副本或复制节点恢复，再按业务时间点补齐。只有明确接受截断范围，并已保留原始副本时，才对工作副本执行：

sudo -u redis redis-check-aof --fix /var/lib/redis/appendonlydir/appendonly.aof.manifest

不同Redis版本和布局的输入文件可能不同，应以当前程序输出和日志为准。修复后再次运行不带 --fix 的检查，确认格式完整，然后才启动实例。

可在 萤光云 的隔离盘上复制损坏样本演练，也可用 LightNode 搭建临时验证节点。样本中若含生产数据，应先加密并限制访问。

启动服务并检查日志与持久化状态：

sudo systemctl start redis-server
sudo journalctl -u redis-server -b -n 100 --no-pager
redis-cli INFO persistence
redis-cli DBSIZE

重点关注AOF是否启用、最近重写状态，以及是否仍有重写进行中或排队。再用业务侧的关键键、抽样计数和时间范围验证完整性；DBSIZE 只能反映键数量，不能证明值和过期时间都正确。

验收标准是AOF能被完整加载、持久化状态正常、关键业务数据与恢复点一致、磁盘无新增错误，并且原始损坏副本仍被保留以便追溯。

打开aof-load-truncated就能解决所有损坏吗？

不能。它主要处理AOF末尾不完整命令；文件中间存在无效字节时，Redis仍可能拒绝启动。

可以删除AOF让Redis从RDB启动吗？

只有确认RDB恢复点满足业务要求并已备份AOF时才可评估。启用AOF的实例通常会优先使用AOF，直接删除可能造成不可逆的数据回退。

修复后DBSIZE一致就算恢复成功吗？

不算。还需核对关键值、TTL、最近写入窗口、应用读写和AOF后续落盘状态。

AOF恢复本质上是数据取舍。先停写、完整备份、只读检测和评估恢复点，再决定从副本恢复还是截断；不要把服务能启动当作数据完整。