Redis 备份、恢复与升级

本页说明如何把 RDB、AOF 和副本能力转化为可执行的备份、恢复和升级流程。内容以 Redis 7.4.11 为基准；Redis 7.0 起 AOF 使用多文件目录结构，备份时必须按整个目录处理。

开启持久化只能帮助实例重启后恢复本地数据，不能覆盖磁盘损坏、实例误删、错误执行 FLUSHALL 或整个区域故障。权威来源见Redis 持久化与备份说明。

1. 定义 RPO 与 RTO

先由业务确定两个指标：

• RPO（Recovery Point Objective，恢复点目标）：故障时最多可以丢失多长时间的数据。
• RTO（Recovery Time Objective，恢复时间目标）：从故障发生到服务恢复，最多允许多久。

业务数据	需要回答的问题	影响
可重建缓存	能否接受清空并回源？	可能不需要长期备份
会话与任务状态	最多丢多少条或多少秒？	决定 AOF、副本和恢复窗口
主数据	是否是唯一副本？能否人工重造？	决定异地备份、恢复演练和审批流程

主从复制不等于备份：副本可能复制同一逻辑错误，也可能与主节点位于相同故障域。RDB、AOF、副本和异地归档分别解决不同问题，不能互相替代。

2. 选择备份内容

方式	适合的恢复目标	主要代价与风险
RDB 快照	定期全量备份、快速恢复、异地归档	快照之间可能丢失写入；生成时有 fork/COW 开销
AOF	降低实例重启后的写入丢失	恢复可能更慢；多文件目录和重写窗口增加备份复杂度
RDB + AOF	同时需要快速恢复与较新的写入日志	需要验证组合加载和磁盘空间
副本快照	减少对主节点的备份负载	存在复制延迟，不能自动保证 RPO

一个实例的策略可以组合使用，但必须能回答“拿哪一份文件恢复、恢复后允许丢到哪个时间点、多久能提供服务”。

3. 创建 RDB 备份

RDB 文件生成完成后是独立快照，可以在服务运行时复制。生产环境优先使用后台快照，避免 SAVE 阻塞主线程。

3.1 生成并确认快照

redis-cli BGSAVE
redis-cli INFO persistence

检查 rdb_last_bgsave_status 为 ok，并记录 rdb_last_save_time、文件路径和实例身份。配置中的 dir 决定工作目录，dbfilename 决定文件名。

3.2 复制并建立清单

timestamp=$(date -u +%Y%m%dT%H%M%SZ)
cp /var/lib/redis/dump.rdb "/backup/redis/${timestamp}-dump.rdb"
sha256sum "/backup/redis/${timestamp}-dump.rdb" > "/backup/redis/${timestamp}-dump.rdb.sha256"

清单至少记录：

• 实例名、环境和角色。
• 快照时间、Redis 版本和 lastsave 时间。
• 文件大小与 SHA-256。
• 预期 RPO、保留周期和存储位置。
• 是否包含敏感数据，以及加密和访问权限要求。

备份文件必须异步复制到独立主机或对象存储，并设置告警。只保存在 Redis 同一块磁盘上的文件不构成异地备份。文件大小和摘要只能证明传输完整，不能证明业务数据正确。

4. 备份 AOF 目录

Redis 7.0 起，AOF 由 appenddirname 指定目录中的基础文件、增量文件和 manifest 共同组成。不能只复制其中一个文件。默认 manifest 名为 appendonly.aof.manifest，实际名称由 appendfilename 加 .manifest 得到。

备份窗口应满足：

1. 确认没有正在进行的 AOF 重写。
2. 暂时关闭自动重写，避免复制期间发生文件替换。
3. 复制整个 appenddirname 目录。
4. 恢复原来的自动重写配置。
5. 校验目录中所有文件和 manifest 的摘要。

检查重写状态：

redis-cli INFO persistence | grep aof_rewrite_in_progress
redis-cli INFO persistence | grep aof_rewrite_scheduled
redis-cli CONFIG GET appenddirname
redis-cli CONFIG GET auto-aof-rewrite-percentage

aof_rewrite_in_progress 和 aof_rewrite_scheduled 都为 0 时，才能开始复制。如果系统支持可靠硬链接，可以先创建硬链接、恢复自动重写，再归档硬链接，缩短配置变更窗口；硬链接能力必须在目标文件系统上验证，不能凭默认假设使用。

不要为了减少复杂度而关闭 AOF 重写后忘记恢复。备份任务应保存原始参数，在异常退出时也能执行恢复，并对长期未恢复的配置变更告警。

5. 验证备份文件

复制完成后，在隔离位置检查文件，不能直接对生产原始文件执行修复：

redis-check-rdb /backup/redis/20261010T020000Z-dump.rdb
redis-check-aof /backup/redis/appendonlydir/appendonly.aof.manifest
sha256sum -c /backup/redis/20261010T020000Z-dump.rdb.sha256

工具返回成功只说明文件结构可读。备份验收还需要启动隔离实例，加载数据并执行业务抽样：

• DBSIZE、键空间数量和过期键数量是否在预期范围。
• 抽样业务 Key 的值、TTL、类型和关键字段是否正确。
• 恢复耗时是否满足 RTO。
• 备份中是否包含不应保留的测试、凭据或跨环境数据。

检查工具在发现问题时可能建议修复。--fix 等写入操作只能作用于备份副本，并保留修复前的原始文件。

6. 执行恢复演练

恢复演练必须在与生产隔离的实例上进行，避免误用同一 dir 覆盖正在运行的数据。

6.1 演练步骤

1. 隔离网络和存储，确认目标实例不会加入生产复制或 Cluster。
2. 校验备份摘要和结构。
3. 使用目标 Redis 版本启动空实例，加载选定备份。
4. 等待 INFO persistence 中的 loading 变为 0，并检查启动日志，确认持久化文件加载完成后再开放连接。
5. 执行业务抽样和只读接口验证。
6. 记录准备、传输、加载和验证各阶段耗时。
7. 清理隔离实例和临时凭据，更新演练日期与责任人。

6.2 确定恢复顺序

恢复时先判断故障类型：

• 单实例本地数据损坏：保留现场，使用独立实例验证备份后再决定切换。
• 主实例丢失：先阻止旧节点重新加入，避免错误副本覆盖正确数据。
• 错误写入或删除：普通快照只能恢复到某个时间点，不一定能恢复到错误发生前一秒。
• Sentinel 故障：不能假设恢复磁盘即可恢复服务，还要检查复制关系、sentinel 配置和客户端发现结果。
• Cluster 部分节点故障：逐槽核对数据，避免只恢复一个节点后错误地加入原集群。

恢复不是“把文件拷回去”。每一步都应有停止条件，尤其是覆盖生产数据、重新建立复制和让旧节点回归集群。

7. 迁移与升级数据

迁移前先记录数据规模、Key 数量、最大 Key、TTL 分布、模块类型、持久化配置和客户端拓扑。选择方案时明确停写窗口：

• 停写快照迁移：停写后复制快照，步骤较少，适合可接受写入暂停的数据；RPO 由停写时间决定。
• 复制或专用工具迁移：可以缩短停写窗口，但要验证增量同步、TTL、Lua/Functions 状态和故障切换。
• 双写迁移：只适用于应用能够保证一致性的场景；Redis 不会自动解决两个目标之间的冲突。

迁移完成后先做业务抽样和对账，再停止旧实例写入。旧实例应保留到观察期结束，不应在切换成功后立即删除。

升级前执行以下检查：

1. 阅读目标版本的发行说明、弃用项、配置默认值、许可证和模块兼容性。
2. 在隔离环境创建当前备份，验证能够被目标版本加载。
3. 核对客户端 RESP 支持、代理兼容性和 TLS 配置。
4. 逐节点或按拓扑执行升级，每一步都验证复制、持久化和客户端错误。
5. 保留升级前配置、二进制、模块和备份，直到观察期结束。

不要默认旧版本可以加载新版本生成的持久化文件。回滚方案必须在隔离环境实际验证；无法安全回滚时，应把升级视为单向操作并提高备份保留级别。

8. 定期演练恢复

备份只有在最近一次恢复成功时才算有效。建议记录以下结果：

演练项目	通过条件
文件校验	摘要一致，RDB/AOF 结构可读
数据加载	隔离实例成功启动并完成加载
数据正确性	键空间、TTL 和业务抽样符合预期
恢复时间	准备、传输、加载和验证总时间满足 RTO
切换流程	旧节点、复制关系和客户端恢复路径明确
升级回滚	目标版本组合已验证，或明确标记不可回滚

演练频率由数据变化速度和 RPO/RTO 决定。至少在备份策略、Redis 版本、拓扑或恢复工具发生变化后重新演练，并把结果加入上线检查清单。

9. 参考资料

• Redis 官方：Redis persistence
• Redis 7.4.11 发布说明：Redis 7.4.11