从 RDB 恢复数据
RDB 恢复的本质是「用一份快照文件替换实例当前的数据来源」：停掉实例、把目标 dump.rdb 放到配置指向的目录并确认文件属主与权限、启动实例，Redis 在启动阶段把文件读进内存。整个流程的难点不在命令，而在几个容易忽略的前置条件：实例是否同时开启了 AOF、文件名与路径是否与配置一致、快照版本是否与当前 Redis 兼容。
基本信息
| 前置动作 | 停止实例，避免新旧文件混写或加载到写了一半的文件 |
|---|---|
| 目标位置 | CONFIG GET dir 与 dbfilename 指向的目录与文件名 |
| 权限要求 | 文件属主与运行用户一致，否则启动时因无法读取而失败 |
| 核对方式 | DBSIZE 看键总数，抽样 EXISTS 与 GET 验证关键键存在 |
| 加载优先级 | 开启 AOF 且文件存在时优先加载 AOF，RDB 会被忽略 |
典型使用场景
- 误删数据后的回滚：把最近一份快照恢复出来，再把差量通过业务侧补齐
- 发布事故回滚：新版本写坏了数据结构，用事故前的快照整体回退
- 环境搬迁：把生产快照脱敏后导入测试环境造数
- 灾难恢复演练：定期按真实流程在隔离环境验证快照可用，而不是只看文件是否存在
- 跨实例迁移：把快照拷到新实例目录，启动后核对键数量与抽样键
恢复步骤
恢复步骤
systemctl stop redis # 先停实例，防止文件被覆盖
cp /data/redis/dump.rdb /backup/dump.rdb.$(date +%F) # 备份当前文件再动手
cp /backup/redis/dump-2026-10-10.rdb /data/redis/dump.rdb
chown redis:redis /data/redis/dump.rdb # 属主必须与运行用户一致
chmod 640 /data/redis/dump.rdb
systemctl start redis
redis-cli DBSIZE # 键总数是否符合预期
redis-cli EXISTS key:spot:check # 抽样验证关键键恢复失败的常见表现
| 现象 | 可能原因 | 检查点 |
|---|---|---|
| 启动后数据是旧的 | 实例开启了 AOF，实际加载的是 AOF | CONFIG GET appendonly 与 appendonlydir 内容 |
| 启动直接失败 | 文件属主或权限不对，或路径与配置不符 | dir 与 dbfilename 的值 |
| 报格式错误 | 快照由更高版本生成，当前版本无法解析 | 两侧 Redis 版本号 |
| 键数量明显偏少 | 覆盖的文件不完整，或恢复的是旧快照 | 文件大小与时间戳，备份清单 |
开启 AOF 的实例会跳过 RDB：即使把新的 dump.rdb 放进目录，启动时仍然优先加载 AOF，现象是「恢复了但数据没变」。正确做法是临时关闭 appendonly 或一并把 AOF 文件处理掉，恢复并核对无误后再重新开启。
用快照恢复意味着放弃快照之后的所有写入：恢复时间点越早，需要人工补的数据越多。执行前必须确认是否有更近的可恢复来源（例如 AOF、从库、binlog），并明确这段时间内产生的新数据如何回补，否则旧数据覆盖新数据会造成二次事故。