很多站点出问题，不是因为没做运营，而是因为一个很小的事故——误删、磁盘损坏、改错配置——之后就再也没有回头路。备份这件事听起来老生常谈，但在实际排查里，它往往是最后一道、也是最容易被跳过的一道防线。这篇自查不是催你立刻去买设备，而是帮你把“备份”这两个字拆成可以执行的动作。
一、先确认：究竟要备份什么
不少人理解的备份，是把网站根目录打个压缩包。真正需要覆盖的内容，通常比这多：
- 程序文件：主题、插件、自研代码，以及被改动过的默认文件。
- 数据库：文章、用户、评论、配置项，多数站点真正的资产都在这里。
- 配置文件：数据库连接、伪静态规则、环境变量、证书路径。
- 上传资源：图片、附件、视频，这类文件往往体积最大。
- 服务器侧配置：Web 服务、定时任务、防火墙规则等。
其中配置文件最容易被忽略。程序文件可以重装，数据库可以导入，但很少有人记得住三个月前那条重写规则是怎么写的。
二、备份频率与保留策略
频率不需要一味求高，而是和内容更新节奏匹配。每天更新内容的站点，数据库一天一次比较合理；更新不多的展示型站点可以适当放宽。关键是保留多份、分成不同时间点的版本，而不是只留最新一份——因为数据被误删、或被有问题的程序写坏之后，最新那一份往往也是坏的。
存放位置要分开
把备份文件放回同一台服务器、同一个目录，是常见但不合格的方案。服务器本身出问题时，备份会跟着一起消失。比较稳妥的做法是至少留两份，其中一份放在另一台机器或对象存储上。
三、恢复演练：备份的价值只在恢复时体现
备份不等于能恢复。压缩包损坏、导出的数据库不完整、目录权限不对、版本不匹配，这些问题只有在真正尝试恢复时才会暴露。建议在测试环境里定期做一次完整恢复，确认几件事：文件能正常解压、数据库能顺利导入、站点能打开、上传资源能访问。
一份没有验证过的备份，只是一份心理安慰。
四、几个常被忽略的细节
- 备份任务本身有没有在执行：定时任务可能因为权限或路径变化悄悄失败，需要有结果通知。
- 备份文件是否加密或限制访问权限：数据库导出文件里通常含有用户信息。
- 是否写下了恢复步骤：把命令和顺序记录下来，紧急时不用现查现找。
- 域名、证书、第三方账号信息是否另行留存。
五、可以直接照着做的检查清单
- 列出程序文件、数据库、上传资源、配置文件四类内容，确认都在备份范围内。
- 为数据库和文件分别设定备份频率，并写进定时任务。
- 确认备份文件至少有一份存放在服务器之外的位置。
- 保留最近若干份不同时间点的版本，避免只留最新一份。
- 每季度做一次恢复演练，记录耗时和遇到的问题。
- 给备份任务加上失败通知，不要靠人主动去看。
备份不会直接带来流量，也不会让抓取变多，但它决定了站点遇到意外时能多快回到正常状态。把上面这几件事固定成习惯，比出事之后再到处找压缩包踏实得多。