Redis RDB 与 AOF 恢复目标的参数取舍

Redis 的 RDB 与 AOF 应按恢复目标选择：先写清允许丢失多少已确认业务数据，再确定服务多久必须恢复。RDB 提供数据集快照，AOF 按写入日志恢复状态；启用两者仍需要独立备份与恢复演练。配置名称不能替代实际恢复结果，everysec 也不是对所有故障的零丢失保证。

官方地址：https://redis.io/docs/latest/operate/oss_and_stack/management/persistence/

本文是自建 Redis 的参数取舍手册，示例未连接服务器执行。托管服务需使用其提供的持久化与备份入口，不应假定能直接编辑 Redis 配置文件。

触发信号：先写出需要恢复的业务状态

当发现持久化文件长期没有成功更新、磁盘空间不足，或业务要求变更时，先确认实例角色和数据用途。可重建缓存与无法重建的业务状态不能套用同一套恢复承诺。

RPO 是可接受的数据损失范围，RTO 是可接受的恢复耗时。运维记录应明确故障类型、数据来源、恢复文件位置、负责人和验收方式。单机进程退出、整机掉电、磁盘损坏和误删除是不同情形，不能只用“重启能起来”覆盖全部目标。

参数先服务恢复目标

# 仅为独立测试实例的配置示例，不是通用生产推荐。
# 满足时间与变更数条件时触发快照，不是无条件定时备份。
save 240 80
# 启用AOF，并选择每秒同步策略作为待评估起点。
appendonly yes
appendfsync everysec

save 240 80 把时间与变更数结合起来，不能解释成“每240秒一定生成一份成功备份”。失败、资源压力与执行耗时都需要另行观察。AOF 的同步策略决定日志落盘节奏，并不负责备份历史保留。

不要仅凭“RDB加载通常较快”就给出恢复分钟数，也不要把 always 描述成磁盘失效后仍绝不丢数据。数据规模、文件状态、存储设备、版本和业务重新接流都会影响恢复。

恢复资产要保留完整集合

Redis 7起的多部分AOF包含 base 文件、增量文件和记录这些文件的 manifest，位于 AOF 目录。只拷一个看起来最大的文件，可能无法构成可用恢复集合。独立 RDB 备份则应按业务保留历史恢复点。

备份计划应把“文件已经存在”和“这份备份能独立恢复”作为不同记录。多部分AOF备份还要遵循对应版本的重写协调要求，避免跨重写切换拼接文件。恢复操作使用备份副本，原始故障资产先保留，避免在唯一副本上试错。

变更与回滚路径先写清楚

变更前保存已知配置、启动方式和备份位置；先在隔离环境验证目标配置与恢复资产。运行中启用AOF与为新实例编写配置不是相同操作，不能把上面的片段直接套进已有实例并立即重启。

如果变更后出现明显写延迟或持久化失败，先判断是磁盘、权限、容量、后台任务还是配置问题。回滚参数只恢复配置行为，不会自动找回已经丢失的数据。尤其不能为回到RDB模式而直接删除AOF目录，或把“关掉AOF”当作通用故障修复。

已经发生异常停机时，恢复负责人应先决定采用哪份资产及其业务恢复点，再在隔离实例加载。确认业务所需的数据与过期语义后，才进入接流安排。这里给出操作规划，不提供未经现场判断的覆盖文件命令。

告警与复盘记录围绕恢复能力

监控至少覆盖最近持久化成功状态、后台任务失败、磁盘剩余空间与延迟变化。告警阈值应来自业务目标和实例基线，不能复制一个固定时间值就宣称满足RPO。

恢复演练记录应包含资产版本、数据时间范围、加载耗时、业务启动耗时、丢失范围判断和最终负责人确认。若没有实际演练结果，文档应标注目标仍待证明，不能填入推测的秒数。

相关问题

同时开启RDB和AOF，重启一定优先使用RDB吗？

官方文档说明同时启用时重启会使用AOF恢复，因为它通常包含更完整的变化。具体恢复前仍需确认实例版本、配置和资产状态。

AOF重写等于保留完整审计历史吗？

不等于。重写服务于重建当前数据状态，不能当作业务操作审计归档；审计需要单独的保留策略。

有副本就不需要备份了吗？

副本解决的是另一类可用性需求。误操作也可能影响副本；独立历史恢复点及其恢复演练仍有价值。