很多站点出事不是因为没有备份，而是因为备份“看起来存在”。文件躺在服务器同一块磁盘上，压缩包设了密码却没人记得，数据库导出到一半被中断——真到需要恢复的时候才发现用不上。这篇自查清单不聊工具选型，只聊怎么确认手里的备份在关键时刻能派上用场。
一、先列清楚：哪些东西必须进备份
只备份数据库是常见误区。数据库里是内容，但让站点跑起来的不只是内容。
- 数据库：文章、用户、评论、配置项，通常是恢复时最关键的一份。
- 上传目录：图片、附件、音视频。这部分往往体积最大，也最容易在迁移时被漏掉。
- 程序与模板文件：主题改动、插件、自定义模板片段。如果改过代码却没进版本控制，它就是孤本。
- 配置文件：数据库连接信息、伪静态规则、环境变量。
- 证书与密钥：HTTPS 证书私钥、第三方接口密钥，丢了要重新申请和配置。
- 定时任务与脚本：备份、清理、同步这些 crontab 任务，很多人在迁移后才发现少了几个。
二、频率和保留策略：别只留最近一份
备份频率应该跟着“你能承受丢多少数据”走，而不是跟着习惯走。
- 数据库：访问量正常的站点可以每天一次全量；更新频繁的站点考虑每天多次增量或开启二进制日志。
- 文件：上传目录按周全量即可，程序文件在每次改动后单独留一份。
- 保留：常见做法是保留最近 7 天的日备、最近 4 周的周备、最近 3 个月的月备。只留最近一份，等于被误删的内容也会被一起覆盖掉。
- 把“动手前先备份”写进流程，尤其是批量删文章、清评论、调整栏目结构之前。
三、恢复演练：能打开压缩包不等于能恢复
建议每季度至少做一次完整演练，找一台测试机，不要在生产环境上试。
- 准备独立环境，域名可以用临时域名或本地 hosts 指向。
- 导入数据库备份，注意字符集和版本差异，导入报错要记录下来。
- 恢复文件目录，核对权限与属主，别用 777 图省事。
- 改回测试环境的连接配置，检查首页、栏目页、详情页、后台登录是否正常。
- 抽查图片和附件能否打开，确认上传目录完整。
- 记录整个恢复耗时。如果明显超出预期，说明备份结构需要调整，比如把大文件拆开单独存放。
四、几个容易被忽略的细节
- 备份文件放在哪里：和站点同一台服务器、同一块磁盘，服务器一挂就一起没了。至少同步一份到对象存储或另一台机器。
- 备份文件能否被公网访问：放在网站根目录下的 backup 文件夹，等于把数据库公开下载。放到 web 目录之外，或加上访问限制。
- 脚本里的密码：备份脚本中写死的数据库密码、云存储密钥，文件权限要收紧，也别提交到公开仓库。
- 任务是否真的在跑：备份失败往往是静默的。加一条失败告警，或让脚本成功后发一封邮件，长时间收不到就说明有问题。
- 备份对站点的影响：大表导出可能锁表并占用磁盘 IO，尽量安排在访问低谷，导出后检查磁盘剩余空间。
- 清理旧备份：只增不删的策略迟早把磁盘写满，删除规则也要写进脚本。
五、月度自查清单
- 确认最近一次数据库备份和文件备份的时间、大小正常。
- 确认备份文件已同步到异地或对象存储。
- 随机下载一个备份包，试解压，确认没有损坏。
- 确认备份目录不在公网可访问路径下。
- 检查备份任务的失败告警是否有效。
- 检查磁盘剩余空间，确认旧备份清理按计划执行。
- 如果本季度还没做恢复演练，安排一次。
备份的价值不在于文件有多少个，而在于你需要它的那一天，它能不能被打开、被导入、被访问。把恢复演练当成例行工作，比多买一块硬盘更有用。