演练是备份唯一的证明
备份能不能用，只有在真正恢复一次之后才有定论。恢复演练的标准做法是：取一份走真实备份链路产出的文件，在隔离环境里拉起实例加载，核对加载耗时、键总数与几个业务抽样键，再把这份耗时写进灾难恢复的预期里。演练同时检验流程文档与人员操作，很多恢复慢的案例根因不在数据，而在流程没人走过。
基本信息
| 频率 | 按月或按重大变更后执行一次 |
|---|---|
| 环境 | 独立实例与独立端口，禁止影响生产 |
| 核对内容 | 键总数、抽样键、关键业务计数 |
| 记录内容 | 加载耗时、失败点、发现的问题 |
| 产出 | 更新后的恢复手册与改进项清单 |
典型使用场景
- 上线新的备份方案后验证它能真正恢复，而不是只看脚本退出码
- 跨版本升级前用新版本加载真实备份，确认可加载性
- 灾备演练中检验从备份到可用服务所需的完整时长
- 新同事接手运维工作时通过演练熟悉恢复流程
- 审计或合规要求提供恢复能力的实测证据
演练要点
演练要点
redis-server /etc/redis/drill.conf --port 6399 # 独立端口拉起演练实例
redis-cli -p 6399 INFO server | grep uptime # 确认实例已就绪
redis-cli -p 6399 DBSIZE # 键总数与备份记录比对
redis-cli -p 6399 GET order:20261012:1001:status # 抽样键取值核对
redis-cli -p 6399 INFO persistence | grep -E 'loading' # 加载相关状态与耗时演练核对项
| 核对项 | 判据 | 不合格时的处理 |
|---|---|---|
| 能否成功加载 | 启动日志无致命错误 | 换备份来源并排查文件完整性 |
| 键总数 | 与备份时记录一致或差异可解释 | 排查是否漏备份或目录结构变化 |
| 抽样键取值 | 与预期业务数据一致 | 确认备份时点与业务影响范围 |
| 加载耗时 | 在可接受的恢复窗口内 | 优化实例规格或调整恢复策略 |
| 流程可执行性 | 按文档操作无需临时摸索 | 修订文档并补上缺失步骤 |
演练用的必须是走真实备份链路产出的文件，随手拷一份旧文件来测等于没测，覆盖不到备份脚本与传输环节的问题。
演练结束后把临时实例停掉并确认端口释放，否则后续其他测试可能遇到端口冲突，误以为是程序问题。