症状：Redis 报告 AOF 重写失败，磁盘告警持续出现，或你不确定重启后能否恢复。
判断：适合想先保护现有数据、再定位故障的 Redis 运维人员；不适合把删除 AOF 或直接重启当成排障第一步的操作方式。先查 INFO persistence、文件系统空间与 AOF 文件集，再在隔离环境验证恢复；不要因为重写失败就删除文件或在生产机上盲目重启。Redis 8.0 的支持截止日也应纳入维护计划，但升级不能替代备份和恢复演练。
负责 Redis 8.0 持久化的 DBA：需要判断重写异常是否影响恢复。
负责应用与平台运维的工程师：需要排查磁盘告警、进程停滞和重启风险。
负责服务器规划的技术负责人：需要把数据盘、机外备份和版本维护放进部署方案。
最后更新于 2026 年 11 月 4 日；版本状态与操作边界核对自 Redis 官方版本管理、持久化、INFO 和 AOF 检查工具文档。
先区分磁盘告警与重写状态
Redis AOF 记录写入操作；后台重写则生成新的基础文件，并在完成后切换文件集。Redis 7.0 起，AOF 采用多文件机制，由基础文件、增量文件和清单共同描述当前文件集。重写期间旧内容不会因为“新文件正在生成”就自动变得可随意删除，复制文件时只拿其中一个文件也可能无法代表完整数据。可对照 Redis 持久化文档中的多文件 AOF 与重写说明。
先从 Redis 自身状态入手：
redis-cli INFO persistence
重点看这些字段：
aof_enabled:1
aof_rewrite_in_progress:0
aof_last_bgrewrite_status:err
aof_last_write_status:ok
这段输出仅是字段示例，不代表任何本站实测或你的实际状态。aof_rewrite_in_progress 表示当前是否有重写进行，aof_last_bgrewrite_status 和 aof_last_write_status 分别反映最近一次重写与 AOF 写入状态。INFO persistence 返回持久化相关统计字段，具体解释见 Redis INFO 命令文档；手工触发重写前，还要确认没有另一个重写正在运行，可查阅 BGREWRITEAOF 命令说明。
| 观察结果 | 可能指向 | 下一步 |
|---|---|---|
aof_last_write_status 异常，且文件系统空间紧张 |
写入或同步遇到问题，空间是待核实因素 | 先查挂载点、可用空间、inode 与 Redis 日志 |
| 没有重写进行，但最近一次重写失败 | 故障可能已经结束，失败原因仍需查日志 | 保留日志与文件集，避免重复触发重写 |
| 重写仍在进行，进度或耗时看起来异常 | 可能仍在工作，也可能有 I/O 阻塞或资源争用 | 结合进程状态、I/O 和日志观察，不凭单一字段定性 |
| 文件可读但启动恢复报错 | 可能涉及文件损坏、文件缺失或清单不匹配 | 先复制完整文件集，再在副本上检测 |
不要把任一行结果直接当成根因。例如，空间充足并不能排除存储写入错误；状态字段显示重写仍在进行，也不能单独证明它已经卡死。
磁盘看似够用时，再核对文件系统
先确认 Redis 数据目录实际落在哪个挂载点。对目录执行 df，检查的是该目录所在文件系统的容量；GNU Coreutils 文档也说明，df 可针对指定路径报告其所在文件系统的空间信息。参考 GNU Coreutils 的 df 说明。
# 将路径替换为 redis.conf 中的实际数据目录
df -hP /实际/数据目录
df -iP /实际/数据目录
findmnt -T /实际/数据目录
容量检查不应只盯着 AOF 目录的单个文件大小：重写期间旧文件、新生成文件和持续写入的数据可能同时占用存储。Redis 文档说明，重写在后台生成新 AOF，并在准备完成后切换；因此现场需要按文件集状态、数据增长和写入情况核算可用余量，而不是套一个没有依据的固定倍数。Redis 持久化说明还指出，AOF 与 RDB 可组合使用，AOF 文件通常比同一数据集的 RDB 文件更大。
空间够不代表文件系统状态正常。还要检查 inode 是否耗尽、目录是否落在预期挂载点、文件系统是否只读，以及系统日志中是否出现 I/O 错误。若 Redis 与其他服务共用文件系统，清理前先辨别文件归属；不要删除正在使用的 AOF、清单、基础文件或增量文件来“试着腾空间”。
诊断条件决定下一步，不要直接动生产文件
下面的分支用于确定排查方向，不是无条件执行的修复脚本：
- 若可用空间或 inode 明显不足，先确认哪些非 Redis 临时文件可以安全清理，或评估扩容；否则，先保留现场并检查挂载与文件系统错误，再安排存储处理。
- 若空间充足但 AOF 写入状态异常，优先核查 Redis 日志、系统日志、块设备 I/O 和文件系统状态；没有证据时，不要把问题归咎于“盘太小”。
- 若重写仍在进行且磁盘 I/O 持续变化，先继续收集状态与日志；若长期没有可解释的进展，再结合进程状态和系统资源调查，不要连续发送重写命令。
- 若重写已结束、AOF 文件集完整且无明显写入错误，再评估备份与隔离恢复；否则，先复制并保护现有文件集，避免对唯一副本做修复。
- 若恢复验证未通过，保留原始文件和验证记录，回到备份时点、文件集一致性与业务不变量逐项排查；不要覆盖生产数据或宣称恢复完整。
这比“失败就重启”多了一个重要判断：AOF 重写失败和 Redis 服务无法启动不是同一件事。若实例仍在服务，盲目重启会把排查重点从运行状态转到启动恢复，并可能增加现场变化。
AOF 文件集损坏时，先复制，再检测与修复
Redis 7 及以上的多文件 AOF 由清单、基础文件和增量文件组成。备份时若只复制一个增量文件，或恰好在重写切换期间复制目录，备份可能不完整。Redis 官方提供了备份流程：备份期间暂停自动重写，确认 INFO persistence 中 aof_rewrite_in_progress 为 0，再复制 appenddirname 对应的整个目录；完成后恢复此前的重写配置。具体步骤见 Redis 官方多文件 AOF 备份说明。
先读取配置，确认实际目录和原值：
redis-cli CONFIG GET dir
redis-cli CONFIG GET appenddirname
redis-cli CONFIG GET auto-aof-rewrite-percentage
Redis 文档说明 CONFIG SET 可在运行中重设受支持的配置项；操作前记录原值，结束后按原值恢复，不要把示例中的占位符直接当作配置值。可查阅 CONFIG SET 命令说明。
| 阶段 | 操作重点 | 不要做什么 |
|---|---|---|
| 保护原件 | 对整个 AOF 文件集做一致副本，并保留日志、版本和配置记录 | 不要只拷贝“最新”文件 |
| 检查副本 | 使用与 Redis 版本相匹配的检查工具，先只检查不修复 | 不要对唯一生产副本执行修复 |
| 评估修复 | 若确需修复，确认工具针对的文件或清单及可能丢弃的范围 | 不要把工具成功退出等同于数据完整 |
| 隔离加载 | 在不接入生产流量的实例加载副本并核对业务数据 | 不要先覆盖生产文件 |
redis-check-aof 先用于检查；若启用修复，损坏位置之后的内容可能被丢弃。Redis 文档明确建议先备份，并先在不带 --fix 的情况下运行检查，再评估错误位置；修复可能造成数据损失。可查看 Redis 官方文档对 AOF 检查与修复边界的说明。不同版本和文件布局的工具用法可能不同，请先核对该版本随附的工具说明，不要照搬单文件 AOF 的操作方式去改多文件清单。
隔离恢复要验证业务数据，不只看进程启动
恢复成功启动，只能说明 Redis 能加载这份数据，不足以证明业务所需的数据完整。用一份独立副本启动隔离实例，确保它不会连接生产客户端、触发真实任务或产生外部副作用。验证结果要和备份时点对齐，尤其注意备份之后的新写入本来就不会出现在该副本中。
| 验证项 | 检查方式 | 通过依据 |
|---|---|---|
| 关键键与数据类型 | 用业务清单抽查关键键，并核对其类型与必要字段 | 值、类型及字段符合已知业务约束 |
| 过期行为 | 核对有 TTL 的样本及其预期过期策略 | 恢复后的状态符合业务对过期数据的处理方式 |
| Stream 等结构 | 核查关键 ID、待处理状态或应用约定的消费位置 | 应用不会因缺失或重复处理而违反业务约束 |
| 恢复来源 | 分别记录 AOF 与 RDB 副本、文件集和备份时间 | 结果能对应到明确的备份时点 |
| 应用验收 | 在隔离环境运行只读或受控的业务检查 | 应用侧关键流程通过，且未触发生产副作用 |
AOF 与 RDB 的恢复路径不同；一种能启动，不能替另一种路径的备份质量背书。Redis 官方持久化文档建议保留 RDB 快照作为备份与恢复的另一条路径，并强调应把快照转移到运行 Redis 的机器之外。若你的自建方案仍缺少机外备份与恢复演练，可先阅读本站的磁盘与内存规划说明，把文件布局与恢复副本存放位置一起纳入设计。
常见故障的判断与恢复问题
AOF 重写失败后，第一批检查项是什么？
先保存日志和现有 AOF 文件集，再查 INFO persistence 中的重写进度、最近一次重写结果与写入状态。然后核对数据目录所在文件系统的可用空间、inode、挂载和系统 I/O 日志。没有明确根因前，不删文件、不在唯一副本上修复，也不通过盲目重启来替代诊断。
重写过程中空间不足，怎样避免误删数据？
先确认 Redis 数据目录与 AOF 子目录实际使用的挂载点，检查空间和 inode，再辨认可安全清理的非 Redis 临时文件。重写可能同时涉及原文件、新生成文件和写入期间的数据，因此要基于现场文件集核算，不套固定空间倍数。若没有安全余量，暂停新增的重写操作并评估扩容；不要删除 Redis 正在使用的文件。
多文件 AOF 备份怎样保证清单与数据对应？
Redis 7 及以上要把清单及其引用的基础文件、增量文件作为一个整体。按官方流程暂停自动重写，确认当前没有重写，再复制整个 appenddirname 目录；完成后恢复原配置并记录备份时点。若无法确认重写状态，先不要把当次目录副本当成可恢复备份。
修复工具通过后，还需怎样验收恢复？
在隔离环境中加载原件副本或修复后的副本，检查关键键、数据类型、TTL 和 Stream 等业务数据，并对照备份时点判断哪些新写入本来就不应存在。保留原始文件和检查记录；只有应用侧验证也通过，才进入受控的生产恢复决策。工具检测通过不是完整性证明。
版本维护、磁盘布局与备份要一起规划
截至 2026 年 11 月 4 日，Redis 官方版本管理页面列明，Redis 8.0 的支持截止日为 2026 年 12 月 1 日；官方也说明不同版本系列的维护规则有所区别。你应据此核对实际运行的小版本、构建来源和升级路径，把版本复核与恢复演练排进维护计划，而不是只因为截止日临近就仓促升级。具体状态可复查 Redis Open Source 版本管理页面。
自建 Redis 时，服务器独享不等于数据自动冗余，也不等于自动备份。没有硬件 RAID 时，你需要自行规划软 RAID 或复制，并把备份存放在机器之外；磁盘布局应根据持久化文件、备份副本和恢复流程决定。若正在比较数据盘与日志盘的安排，可以先确认实际可选存储，再参考本站的服务能力与配置边界。具体存储选项和价格应以本站产品表为准；不应把更换硬件说成修复 AOF 或保证数据安全的办法。
如果你当前使用共享云主机，CPU 资源可能与其他租户竞争，云盘 IOPS 与吞吐也可能按档位计费，盘布局和系统权限还受产品规格限制；这类限制并不会因为迁移到物理机就自动消失。对需要长期稳定运行、希望自行安排直连磁盘布局的 Redis 部署，OSFP Cloud 的独享 AMD 物理机可以作为方案之一。下决定前先核对本站实际存储选项，并先把机外备份与隔离恢复演练做通；机器升级、版本升级和备份分别解决不同问题。
常见问题
AOF 重写失败后，排查顺序怎么安排？
先保留 Redis 日志和现有 AOF 文件集，查询 INFO persistence 中的重写进度、最近一次重写结果和写入状态，再检查数据目录所在文件系统的空间、inode 与挂载情况。确认问题属于资源不足、写入错误还是进程停滞后，再选择修复或恢复路径；不要先删文件或盲目重启。
AOF 重写时文件系统空间告急，能不能删旧文件腾空间？
不要删除正在使用的 AOF 文件、增量文件或清单。重写期间，旧文件集、新生成的基础文件以及持续写入的数据可能同时占用空间；应先确认目录和文件系统对应关系，清理确认无关的临时文件或扩容，并根据现场文件大小和写入情况核算余量，不能套用固定倍数。
Redis 7 及以上做多文件 AOF 备份，怎样避免漏文件？
把清单、基础文件和增量文件作为同一组处理，不能只拷贝看起来最新的单个文件。Redis 官方流程要求在备份期间暂停自动重写，确认 INFO persistence 显示没有重写进行后再复制整个 AOF 目录；完成后恢复原来的自动重写设置，并记录备份时采用的配置。
redis-check-aof 检查通过，就能确认数据完整吗？
不能。检查工具用于发现或处理 AOF 文件格式问题；启用修复可能截去损坏位置之后的数据，因此成功退出不等于业务数据完整。应在原文件集的副本上操作，并在隔离实例加载修复结果，核对关键键、数据类型、过期行为及 Stream 等业务约束，再决定是否进入生产恢复流程。