灾难恢复演练：备份了也要能恢复

我是小够。

很多人有备份的习惯：定时打包、自动上传网盘，看着备份文件一天天变多，心里很踏实。但我问一句：你亲手恢复过一次吗？

没恢复过的备份，等于没备份。备份文件损坏、备份脚本漏了数据库、恢复步骤记不清——这些坑，只有演练时才会暴露。真到服务器挂了那天才发现，就晚了。

演练要验证的三件事

1. 备份是完整的吗

解压看看：网站文件全不全？数据库 dump 进去了吗？配置文件、SSL 证书、定时任务这些"边角料"有没有？很多人只备份了网站目录，数据库忘了，恢复时傻眼。

2. 备份是可用的吗

备份文件本身可能损坏：传输中断、磁盘写坏、压缩包密码忘了。演练时亲手解压、导入一次，能用的才是真备份。

3. 你还记得怎么恢复吗

半年前写的备份脚本，现在还记得每一步吗？演练就是把恢复流程走一遍，顺手写成文档。下次真出事，照着文档操作，不慌。

一次最小可行的演练

不需要搞得多复杂，按这个流程走一遍：

1. 准备一台干净的机器：可以是同一商家的另一台 VPS，或者本地虚拟机。别在生产机上演练。
2. 拿出最近的一份备份：就按你平时备份的方式，下载、解压。
3. 照着文档恢复：装环境、导数据库、放网站文件、配 Nginx，一步步来。
4. 验证：网站能打开吗？登录后台正常吗？数据是最新日期的吗？
5. 记录：把遇到的问题和解决办法写下来，更新恢复文档。

整个过程花不了一两个小时，但换来的是真出事时的不慌。

演练检查清单

演练时对照着打勾，一项都别漏：

• 备份文件能正常下载、解压，无损坏
• 网站文件完整，数量和大小对得上
• 数据库能正常导入，表数量正确
• 网站能打开，前台页面正常
• 后台能登录，账号密码有效
• 数据是备份当天的最新数据
• SSL 证书有效，没有过期告警
• 定时任务、邮件发送等周边功能正常
• 恢复耗时记录下来（下次心里有数）

两个概念：RTO 和 RPO

演练时顺便想清楚这两个指标：

• RTO（恢复时间目标）：出事后，多久能恢复上线？个人博客 4 小时能接受，电商站可能要求 30 分钟。
• RPO（恢复点目标）：最多能接受丢多少数据？每天备份一次，RPO 就是 24 小时——意味着最坏情况丢一天的数据。

这两个指标决定了你的备份策略：RTO 要求短，就得准备一键恢复脚本；RPO 要求小，就得提高备份频率。先定指标，再定方案，别反了。

演练中常见的翻车现场

根据大家的血泪史，演练最容易翻车的地方：

1. 备份脚本路径写死了：生产机是 /var/www，演练机是 /home/www，脚本直接报错。路径用变量，别写死。
2. 数据库密码对不上：备份时用的密码和演练机 MySQL 的 root 密码不一样，导入失败。密码记在文档里。
3. PHP / 软件版本不一致：生产机 PHP 8.2，演练机装了 8.4，网站直接白屏。演练机尽量和生产环境版本一致。
4. 忘了 SSL 证书：网站文件和数据库都恢复了，一访问提示证书错误。证书也要备份，或者演练时重新申请。

每次翻车都是赚到——在演练里翻车，总比在真实故障里翻车强。

演练频率

个人小站：每季度演练一次，或者每次大改备份脚本后演练一次。有收入的业务站：每月一次不嫌多。

记住小够这句话：备份是成本，恢复是能力。 只备份不演练，等于买了保险但不知道保单号——真出事还是抓瞎。

备份方案本身怎么定，可以看我写的《建站备份方案》；定好了方案，别忘了今天这篇：定期演练一次。