备份这件事，很多站点都是“设了定时任务就当作做完了”。真正出问题时才会发现：备份文件是空的、只备份了数据库、恢复后旧链接全变成 404、备份压缩包还能被任何人直接下载。备份的价值不在“有”，而在需要时能不能恢复，恢复得对不对。
先确认备份范围是否完整
只备份数据库是常见的误判。一个能正常运转的站点，至少包含几类彼此依赖的数据。
- 数据库：内容、用户、评论、配置项、表单记录。注意字符集与排序规则，恢复时不一致容易出现乱码。
- 程序与模板文件：包含改动过的主题、插件、函数文件，升级出问题后回滚要靠它。
- 上传的媒体与附件：图片、视频、下载文件、用户上传目录，往往体积最大，也最容易被排除在备份任务之外。
- 服务器与站点配置：Nginx 或 Apache 配置、伪静态与重定向规则、.htaccess、计划任务脚本、环境变量文件。
- 证书与密钥：HTTPS 证书、私钥、CDN 回源鉴权信息。丢了要重新签发，恢复时间会被拉长。
- 外部配置记录：DNS 解析记录、CDN 缓存规则、对象存储权限策略。这些不常改，但恢复时最容易漏。
判断备份是否完整的简单办法：把这套备份恢复到一台干净的服务器上，站点能不能直接打开、链接能不能正常跳转。
频率、保留与存放方式
备份频率要跟着内容更新速度走。日更多次的资讯站，只保留每周一份，丢失的可能是整周内容；更新很慢的企业站，每小时做全量备份又是浪费。
- 采用全量加增量的组合：全量保证可独立恢复，增量控制备份窗口与存储成本。
- 设定保留代际，例如近 7 天每日一份、近 4 周每周一份、近 12 个月每月一份。只留最新一份，一旦最新备份也被污染就没有退路。
- 至少一份放在与生产环境不同的位置，机器故障、机房问题、误删权限不会同时波及。
- 备份文件不要放在网站可访问目录下，也不要用可猜测的文件名。历史备份被公开下载，等于把数据库结构和用户信息一起交出去。
- 定时脚本要有执行结果记录，失败要能发出告警，而不是安静地失败几个月。
恢复演练：重点看恢复后的站点是否“像原来一样”
演练不必每次全量重建，可以定期在测试环境恢复最近一份备份，然后按清单核对。这一步能暴露绝大多数问题。
- 站点能否正常打开，首页、栏目页、详情页各抽几个访问。
- URL 结构是否与线上一致，包括目录层级、大小写、末尾斜杠处理。
- 重定向规则是否生效：旧的地址、www 与非 www、HTTP 到 HTTPS 是否指向正确。
- robots.txt、站点地图、canonical 指向的域名是否还是原来的域名，避免恢复成测试域名后忘了改回。
- 静态资源域名与 CDN 配置是否对应，图片、样式、脚本能否正常加载。
- 附件目录是否完整，随机抽查几张较早的图片。
- 计划任务、缓存清理、队列进程是否重新启动。
- 表单提交、站内搜索、登录等依赖数据库的功能是否正常。
演练完成后记录耗时和踩到的坑。真正的故障恢复是按分钟计成本的，提前走过一遍流程，比临时翻文档要可靠得多。
容易被忽略的几个细节
- 恢复期间页面不要长时间返回正常的 200 首页。站点不可用时应返回明确的 503，并带上重试提示，避免蜘蛛把空白或占位页抓走。
- 恢复后注意时间戳与缓存：有些静态缓存、CDN 缓存仍指向旧版本，需要主动刷新。
- 数据库导出如果加锁方式不当，可能在大表上锁住写入，影响线上访问。建议放在低峰时段执行并检查耗时。
- 日志与备份分开管理：访问日志、错误日志在排查问题时很有用，但体积增长快，保留周期可以与数据备份不同。
- 恢复后确认重定向规则是否随配置一起恢复，否则老链接会直接变成 404，用户和搜索引擎同时受影响。
- 涉及用户数据的备份要考虑合规，导出、传输、存放都应限制访问权限。
把备份检查放进日常巡检
备份不是一次性的项目，而是需要定期确认的例行事项。可以固定每周或每月检查几件事：最近一次备份是否成功、备份文件大小是否异常、能否正常解压、异地副本是否同步、恢复演练是否按计划完成。把这些检查结果记录下来，出问题时才有判断依据。
站点恢复能力是运营的一部分，但很难在顺利的时候体现价值。它更像保险：平时占不了多少精力，需要的时候能决定站点是几小时恢复，还是几天回不来。
一句话自查：如果现在生产环境的数据全部丢失，你手上最近的一份备份，能恢复到什么程度？