Redis RDB 与 AOF 持久化组合的恢复取舍

Redis 的 RDB 与 AOF 不是“二选一才安全”。如果数据可以接受几分钟丢失，RDB 的紧凑快照和较快重启更合适；如果写入不能只靠定时快照保护，则应把 AOF 作为更细粒度的恢复来源，同时保留 RDB 作为备份和灾备文件。对大多数重要数据，组合模式的核心不是把两个开关都打开，而是明确恢复窗口、重写压力和备份边界。

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

建议把 RDB 看作可搬运、可归档的时间点快照，把 AOF 看作更接近实时写入的恢复日志。两者同时启用时，Redis 重启会优先使用 AOF 重建数据集；RDB 则承担快速恢复、异地备份和灾难回滚的职责。

先按数据丢失窗口选择持久化组合

RDB 在指定条件满足后生成单个二进制快照，文件紧凑、适合复制到异地存储，也通常比 AOF 更快完成大数据集的启动加载。代价是两次快照之间的写入可能丢失，且生成快照需要后台 fork；数据集很大时，fork 和写时复制会带来额外的内存与延迟压力。

AOF 记录改变数据集的写操作，重启时通过重放日志恢复状态。appendfsync everysec 是常见折中，通常最多承担约一秒的写入损失；always 更偏向耐久性，no 则把刷盘交给操作系统。AOF 更接近实时，但文件通常更大，也需要周期性重写。

组合模式的恢复来源和文件边界

同时开启两种持久化时，RDB 和 AOF 并不是两份完全相同的副本。RDB 是某个时间点的完整表示，适合保留多个小时或多个天的版本；AOF 则保留写入语义。Redis 官方文档说明，组合模式重启时会使用 AOF，因为它通常包含更完整的最新状态。

Redis 7.0 之后，AOF 使用多文件格式：最多一个基础文件、一个或多个增量文件，以及描述文件集合的 manifest。这个变化意味着备份 AOF 时要把同一目录内与 manifest 对应的文件集视为整体，不能只随手复制一个旧的单文件路径。若备份时正好发生重写，还要先确认重写状态，避免拿到不完整的文件组。

重写、刷盘和磁盘空间要分开管理

RDB 快照和 AOF 重写都可能 fork 子进程；两者同时争用磁盘和写时复制内存，会把持久化风险放大。因此不要只盯着“开关是否为 yes”，还要把后台任务和磁盘余量纳入运行手册。

# 先查看刷盘策略、重写状态和最近一次重写结果
redis-cli CONFIG GET appendonly appendfsync auto-aof-rewrite-percentage
redis-cli INFO persistence

# 读取输出时重点关注重写进行中、是否排队，以及最近一次状态
# aof_rewrite_in_progress=1 表示不要在此时复制 AOF 文件组
# aof_last_bgrewrite_status=ok 才能作为最近一次重写成功的依据

appendfsync 决定 AOF 的耐久性与写入成本，AOF 重写决定日志如何收敛为更短的文件集；它们解决的是不同问题。不要为了减少文件大小而盲目把刷盘改成 no，也不要在磁盘接近上限时手工触发多项后台任务。

从 RDB 切到组合模式时保留恢复退路

如果实例原来只有 RDB，直接改配置后重启并不能自动证明切换安全。先复制并保留最近的 dump.rdb，再在仍在线的实例上开启 AOF，让 Redis 从当前数据集建立 AOF，最后把配置持久化，避免下一次重启又回到旧配置。

# 切换前先保留 RDB；这里的路径只是示例，按实际 dir 调整
cp /var/lib/redis/dump.rdb /backup/redis-dump-before-aof.rdb

# 在线打开 AOF，避免仅改文件后重启造成状态落差
redis-cli CONFIG SET appendonly yes
redis-cli CONFIG REWRITE

# 等待重写完成后再安排重启；不要把示例输出当成线上证据
redis-cli INFO persistence

安排恢复窗口前，至少确认：RDB 备份已经离机保存；AOF 重写没有进行中；磁盘有足够空间承受临时文件和写时复制；CONFIG REWRITE 后的配置与预期一致。重启后再核对键数量、关键业务抽样和持久化状态，确认的是“恢复计划可执行”，不是只确认进程重新监听端口。

把恢复取舍写成一张运行清单

• 缓存且允许丢失：可以关闭持久化，或只保留轻量 RDB，不要把缓存误当成唯一数据源。
• 重要业务数据：优先组合 RDB + AOF，明确 appendfsync 的可接受损失窗口。
• 备份 RDB：利用其文件完成后原子替换的特点，定时复制并保留异地版本。
• 备份 AOF：Redis 7.0+ 按 manifest 对应的完整文件组处理，并避开 AOF rewrite 进行时的复制窗口。
• 发生磁盘告警：先暂停不必要的重写和备份复制，保留现有恢复文件，再处理容量，不要直接删除最新持久化文件。

最后可以用三个问题做决策：最多能接受丢多少写入？重启时更看重加载速度还是更小的恢复窗口？是否需要把某个历史时间点带到异地？答案分别指向 RDB、AOF 的刷盘策略，以及组合模式下的备份保留周期。

相关问题

RDB 和 AOF 同时开启会不会重复保存数据？

会产生两套不同形态的持久化文件，但用途不同：AOF偏向当前恢复，RDB偏向快照、异地复制和较快启动。是否值得承担额外资源，要看数据价值和恢复目标。

只开启 AOF 是否就不需要备份？

不建议这样理解。AOF 记录写入历史，但误操作可能同样被记录；独立保留 RDB 或完整 AOF 文件组，才能提供可回滚的恢复点。

复制 AOF 文件前最容易漏掉什么？

最容易漏掉的是 Redis 7.0+ 的基础文件、增量文件和 manifest 的整体关系，以及复制时正在发生的重写状态。