很多站点出事的时候，才发现自己的备份从来没被真正打开过。备份文件躺在那里，大小看着正常，真到要恢复时却解压失败、缺表、少文件，或者根本没有对应的程序版本。备份的价值不在于「有」，而在于「能还原到一个可用的状态」。
先把两个数字说清楚：RPO 与 RTO
在讨论备份策略前，先给自己定两个目标值，后面所有决策都围绕它们展开：
- RPO（可接受的数据丢失量）：最坏情况下你能接受丢掉多长时间的数据？如果按天备份，就意味最多丢一天的内容。
- RTO（可接受的恢复耗时）：从确认出事到站点重新可用，你能接受多久？这个数字决定了你需要的是「下载备份再慢慢传」，还是「有现成镜像能直接切」。
这两个值不需要很漂亮，但要真实。写清楚之后，再去看现有备份方案能不能满足，缺口通常一眼就能看出来。
备份到底要覆盖哪些东西
只备数据库是最常见的疏漏。一个能跑起来的站点，至少包含下面几类内容：
- 数据库：内容、用户、配置项大多在这里。
- 上传目录与静态资源：图片、附件、用户上传的文件，通常体积最大，也最容易漏。
- 程序代码与主题插件：记录清楚版本号，最好保留一份未改动的原始包。
- 配置文件：数据库连接、密钥、伪静态规则、环境变量，这些往往不在版本库里。
- 服务器层面的东西：Nginx / Apache 配置、定时任务、证书文件、防火墙规则。
如果站点用了对象存储或第三方服务存资源，也要确认这些服务本身有没有版本控制或回收站，别默认它们一定安全。
三个高频误区
备份和站点在同一台服务器上
这是最危险的一种。服务器被重装、磁盘损坏、被入侵加密，备份会跟着一起没。至少要做到异地或异盘存放，哪怕只是定期拉一份到本地或另一家对象存储。
备份文件能被公网直接访问
备份目录放在网站根目录下，等于把整站数据和配置对外公开。记得检查目录权限、禁止目录列表，并把备份放在 Web 根目录之外。
只验证了文件大小，没验证内容
备份任务返回成功，不代表文件完整。压缩包截断、数据库导出中途报错、定时任务其实半年前就停了，这些都不会主动通知你。建议至少每月做一次自动校验：尝试解压、尝试导入到一个临时数据库、检查关键表行数是否合理。
恢复演练怎么做
演练的目标不是「证明备份能用」，而是「发现流程里缺了什么」。在临时环境里按下面的顺序走一遍：
- 准备一台干净的临时服务器或容器，尽量不要复用生产环境。
- 从备份源拉取最新一份完整备份，记录下载耗时和文件大小。
- 搭建与生产一致的程序版本和运行环境，包括 PHP、数据库、扩展版本。
- 导入数据库，观察是否有报错、字符集问题、表缺失。
- 恢复上传目录和静态资源，检查文件数量与总大小是否对得上。
- 还原配置文件、伪静态规则、定时任务。
- 把域名临时指向测试环境，检查首页、栏目页、详情页、搜索、表单提交是否正常。
- 检查后台能否登录，图片能否显示，页面是否报 404 或 500。
- 记录整个流程的耗时，对比事先定下的 RTO。
如果站点依赖 HTTPS 证书，演练时也要把证书一并还原，避免只验证了 HTTP 层就以为通过。
演练之后要留下什么
- 一份可执行的步骤清单，谁照着做都能走完。
- 实际恢复耗时，以及卡在哪一步。
- 发现的缺口，比如某个目录没人备份、某项配置只存在某个人电脑里。
- 备份任务的负责人和下次演练时间。
备份是流程，不是文件。文件只说明你曾经备份过，流程才说明你能恢复。
演练频率不必太高，但要有节奏：内容更新频繁的站点可以每季度一次，更新较少的半年一次也够。重要的是每次都走完整流程，而不是只在脑子里过一遍。等到真的需要恢复的那天，你会发现省下的这几十分钟，价值远超预期。