Redis RDB 和 AOF 如何按恢复目标选择

选择 Redis 持久化，我会先问两个问题：这份数据还能从其他系统重建吗？发生故障后，业务能接受丢多少数据、停多久？RDB 与 AOF 的差别，只有放进这些恢复目标里才有意义。本文围绕 Redis Open Source 的机制解释选择方法，配置与命令仅供阅读，没有执行生产测试，也不承诺固定恢复时间。

先确定资产：缓存和唯一业务状态不是同一种风险

商品展示缓存能够从数据库重建，丢失通常意味着回源压力和重新预热；若 Redis 保存的是尚未落到其他可靠系统的业务状态，丢失就可能意味着无法补回的记录。我会把允许丢失的数据量或时间窗口称为 RPO，把恢复服务所能接受的时间称为 RTO，但不会用这两个缩写替代业务说明。

例如，“允许丢失最近几分钟的展示缓存”与“不能丢失已确认的任务状态”需要不同设计。还要分开评估进程崩溃、主机断电、本地磁盘损坏和误删。能从同一块磁盘重新启动，并不能证明磁盘损坏后仍可恢复；更不能证明误删前的数据还在。

RDB 与 AOF 各自覆盖什么，又遗漏什么

RDB 是某个时间点的数据快照。快照紧凑，便于保存多个历史版本和转移到独立位置，大数据集加载通常有优势，但实际耗时仍取决于数据规模、存储和启动条件。异常退出时，最后一个可用快照之后的变化可能无法找回。

RDB 的自动保存条件包含时间和修改量，并不是精确的固定周期备份。快照任务是否成功、完成耗时和调度延迟都影响真正的恢复点。因此不能看到五分钟配置，就对业务承诺最多丢五分钟。

AOF 记录改变数据的操作，重启时据此恢复状态。appendfsync everysec 通常在性能与耐久性之间折中，灾难场景可能丢失约一秒的写入，但这不是对任意磁盘故障、系统阻塞或异常配置都成立的无条件上限。always 会在新命令追加后同步，支持批量提交；不能理解为每条命令必定单独调用一次同步。no 把刷新时机交给操作系统，不适合据此承诺小窗口。

AOF 重写会生成重建当前状态所需的较小表示，不是永久保存所有历史操作。误删如果已进入当前状态，并经历重写，就不能假设原始内容还能靠删掉日志末尾某条命令找回。不要在生产原件上随意修改 AOF。

按威胁选择组合，而不是只比较文件大小

对可重建缓存，我会优先评估回源承载和预热时间，再决定 RDB 是否足够，甚至是否需要本地持久化。关闭持久化只适用于确实允许全部重建的资产，不能因为“Redis 是缓存”就套用到所有实例。

对需要缩小异常退出丢失窗口的数据，AOF 往往是重要选项；同时保留周期性 RDB 历史备份，可以补上另一种恢复资产。若业务要求已确认写入绝不丢失，我不会仅凭开启 AOF 就宣布达标，还需要确认客户端成功语义、复制确认、存储保障、故障范围和上游持久记录。

对误删和磁盘损坏，隔离且有历史版本的备份更关键。复制可能同步误删，本机上的 RDB 和 AOF 也可能一起随磁盘故障消失。两个文件不等于两个独立故障域。

下面是配置文件的讨论示例，不是在线切换指令。已有数据的实例启用 AOF，应遵循对应版本的正式操作流程，等待初始生成完成并保存配置，不能只改文件后盲目重启。

# 配置示例：满足时间与修改数量条件后尝试生成 RDB，并非精确五分钟调度
save 300 100
# 启用 AOF；已有实例须按版本文档安全切换，不能直接套用重启
appendonly yes
# 每秒同步的折中策略，不代表跨故障域零丢失
appendfsync everysec

配置已开启，还要确认运行状态和备份边界

我会先读取实际配置和持久化状态，关注最近快照、AOF 写入或重写是否失败、磁盘空间是否足够。读取权限不足时，应由有权限的维护人员提供信息，不应临时放宽访问控制。下面只列只读命令，没有真实输出：

# 在已配置安全连接与认证的 redis-cli 会话中读取状态
INFO persistence
# 分别读取实际持久化选项，不修改配置
CONFIG GET save
CONFIG GET appendonly
CONFIG GET appendfsync

Redis 7.0 起使用多部分 AOF：基础文件可能是 RDB 或 AOF 格式，另有增量文件，manifest 管理它们。备份必须保证相关文件集合一致，不能沿用“复制一个 appendonly.aof 就完成”的旧假设。正在重写的目录可能变化，备份方法要遵循对应版本文档，确保 manifest 与它引用的文件匹配。

隔离备份也要有可执行的保留策略：保存多少历史版本、谁有删除权限、备份目的地是否与运行磁盘共用故障域、恢复需要哪些配置和凭据。快照生成成功不代表已复制到独立位置；备份任务成功也不代表数据范围正确。

最后用隔离恢复记录决定，而不是凭感觉选

在独立环境恢复一份指定时间点的备份，记录文件版本、数据范围、准备耗时、加载耗时以及服务就绪耗时。RTO 应包含获取备份、启动、检查业务数据和恢复流量所需时间，不只是 Redis 加载文件的时间。

同时记录实际能恢复到哪个时间点，用业务记录确认缺失范围。对于误删场景，应选择误删之前的历史备份，并评估其后合法变化如何补回。不能把最新 AOF 或最新快照默认当成正确数据。

我的结论是：RDB 适合快照型恢复资产，AOF 适合缩小部分异常退出下的丢失窗口，二者组合仍需要隔离历史备份。选择结果应写成“针对哪些故障、允许丢失什么、恢复需要多久”，而不是只写“已开启持久化”。

常见疑问

同时开启是否自动拥有误删保护？不会。两者都可能保存误删后的状态，要靠隔离历史版本和补数据方案覆盖这个风险。

AOF everysec 是否意味着一定最多丢一秒？它描述常用同步策略，不能脱离存储、系统异常和实际选项作无条件业务保证。

RDB 恢复一定更快吗？不能直接保证。数据规模、文件格式、存储、CPU、启动准备与预热都影响结果，应在自己的隔离环境记录。

机制参考：Redis 官方持久化文档 https://redis.io/docs/latest/operate/oss_and_stack/management/persistence/。上线与备份操作应核对实际 Redis 版本。