备份这件事，顺利的时候没人提起，出问题的时候才发现它决定了站点要停多久。误删一个栏目、升级插件失败、数据库表损坏、服务器到期被回收，任何一种都足以让几个月的内容积累瞬间归零。这篇整理的是实操层面的自查思路，不是买什么产品的问题。
一、先盘点：到底要备份哪些东西
很多人对备份的理解停留在“导出数据库”，这远远不够。至少应覆盖以下几类：
- 程序与模板文件：主题、插件、二次开发的自定义代码，尤其是直接改过核心文件的情况。
- 数据库：文章、用户、评论、设置项，注意导出时要包含建表语句和字符集信息。
- 上传目录与附件：图片、视频、下载文件，这通常是体积最大、也最容易被漏掉的部分。
- 服务器配置：Web 服务器规则、伪静态、PHP 版本与扩展、计划任务、防火墙策略。
- 证书与 DNS 记录：SSL 证书文件与到期时间、域名解析记录截图或导出文件。
- 对接信息：第三方接口密钥、邮件服务、对象存储的访问凭据。
二、频率与保留：按更新节奏来定，而不是照抄模板
每天更新的站点，数据库适合每日备份；以静态页为主、更新较慢的站点，每周一次也可以接受。关键在于保留多个版本，因为数据损坏往往不是当天发现的：
- 日备保留 7 到 14 天，用于应对误操作。
- 周备保留 1 到 2 个月，用于应对延迟发现的故障。
- 月备保留半年以上，用于应对改版回退和合规需求。
保留策略要写进配置里自动清理，否则磁盘迟早被旧备份塞满，而后面的备份任务会静默失败。
三、存放位置：别把备份和站点放在同一个篮子
常见的错误是把备份文件直接写在站点同目录、同一块磁盘，甚至同一个云账号下。磁盘故障、误删目录、账号被封，都会让数据和备份一起消失。可以参考 3-2-1 的思路：至少三份副本，存放在两种不同介质上，其中一份在异地。至少保证备份不依赖站点所在的那台机器和那个账号。
四、恢复演练：备份能不能用，只有试过才知道
备份存在不等于可恢复。建议按下面的顺序定期演练一次：
- 准备一台干净的测试机器或临时环境，不要在生产环境上直接试。
- 拉取最近一份备份，先验证压缩包是否完整、校验值是否一致。
- 按文档恢复数据库与文件，记录实际耗时和每一步卡住的地方。
- 检查前台首页、栏目页、详情页、后台登录、表单提交、图片加载是否正常。
- 更新恢复文档，写清备份版本、操作人和发现的问题。
演练频率建议每季度一次，最低不要低于半年一次。换了服务器、换了存储方案、改了数据库版本之后，应当额外补做一次。
五、几个容易踩的坑
- 备份任务静默失败：磁盘写满、目录权限不足、密钥过期，都可能导致连续多天没有新备份。
- 只备数据库，漏掉上传目录，恢复后正文在、图片全丢。
- 压缩包加了密，密码只存在某个人的聊天记录里，人一离职就打不开。
- 备份里混入了测试环境的脏数据，恢复后线上出现一堆测试页面。
- 恢复时忘记同步更新域名、证书路径、对象存储地址，页面能开但资源 404。
- 没有记录数据库版本和字符集，导入时报错却查不出原因。
六、把停机时间压到最短
恢复速度本身就是运营指标。长时间的 5xx 响应会让访客直接离开，也会让搜索引擎降低对这个站点的抓取意愿。条件允许的话，提前准备一个静态维护页，在维护期间返回 503 状态并带上 Retry-After 头，比直接返回空白页或超时要友好得多。同时，域名到期时间、证书到期时间这类“可预测的故障”，用日历提醒就能避免。
七、自查清单
- 数据库、程序文件、上传目录是否都在备份范围内。
- 备份是否存放在与站点不同的机器或账号下。
- 最近一次成功备份是什么时候，能否在后台看到状态。
- 备份失败是否有告警，还是只写进日志没人看。
- 恢复流程是否写成文档，其他人照着能否操作。
- 最近一次恢复演练距今多久，当时暴露了哪些问题。
把这几项过一遍，通常能发现一两处平时没注意的缺口。备份不产生流量，也不直接带来收益，但它决定了前面所有运营工作有没有一个底线。