很多站点的备份状态是：文件夹里确实躺着几个压缩包，但没人知道里面是什么、什么时候的、能不能还原。等到误删数据、服务器故障或者被入侵时才打开，往往发现备份不完整、解压失败、数据库对不上。备份这件事，重点不在于“做过”，而在于“真的能恢复”。
一、先盘清楚要备份什么
不同类型的站点结构差别很大，但下面这几类内容基本绕不开。建议先列一张清单，逐项确认是否有覆盖：
- 数据库：文章、用户、评论、配置表。多数站点的核心数据都在这里。
- 程序与模板文件：包含你自己改过的主题、插件、配置文件。官方源码可以重下，改动过的部分重下就没了。
- 上传的附件与图片：通常体积最大，也最容易被漏掉。
- 服务器配置：Web 服务器配置、计划任务、SSL 证书、环境变量说明。
- 域名与解析信息：到期时间、解析记录、备案相关信息，方便出事时快速核对。
清单里每一项都要写清楚“存放在哪、多久备一次、用什么方式恢复”。只写“已备份”没有意义。
二、备份至少要放两个地方
把备份和站点放在同一台服务器上，是最常见的隐患。服务器一旦整体故障或者磁盘损坏，源站和备份会一起消失。比较稳妥的做法是分层存放：
- 本地副本：留在服务器上，恢复速度最快，用于应对误删这类小事故。
- 异地副本：放到另一台机器或对象存储，应对整机故障。
- 离线副本：定期下载到本地硬盘，应对账号被入侵、云存储被误删的情况。
三层不必都做得非常频繁，但至少要有异地这一层。另外，备份文件的访问权限要收紧，别让备份包能被公开下载——那相当于把整站数据挂在了外面。
三、恢复演练怎么做
只备份不演练，问题会在最糟糕的时候暴露。演练不需要每个月都做，但建议至少每季度走一遍，流程大致如下：
- 准备一台干净的测试环境，尽量贴近正式环境。
- 从备份中还原数据库，检查表数量、关键表行数与最近一条数据的时间。
- 还原程序文件与附件目录，确认主题、插件、图片都能正常读取。
- 打开前台首页、栏目页、详情页，测试登录后台、发布一篇文章。
- 记录整个还原过程用时，作为故障时的恢复时间参考。
演练之后要写下两个数字：备份包大小和恢复耗时。这两个数字会直接决定你面对故障时的心态。
四、容易踩的几个坑
- 只备份数据库，忘了附件。恢复后发现文章在、图片全裂。
- 备份脚本静默失败。磁盘写满或权限变更后任务继续跑，但产出的是空文件。
- 从不检查备份完整性。压缩包损坏要等到解压那一刻才发现。
- 保留策略混乱。要么只留最新一份，被污染后没有回退余地；要么无限堆积，把磁盘塞满反过来影响站点。
- 备份含敏感信息却未加密。传输和存放环节都可能泄露。
五、让备份结果有人看
备份任务最好能主动报告结果：成功或失败都要有通知，失败时能重试并告警。如果条件允许，给备份文件的生成时间设一个检查项，超过预期时间没有新备份，就当成异常处理。
判断备份是否可靠，不看任务是否在跑，而看上一次成功恢复是什么时候。
最后，把备份清单、存放位置、恢复步骤和演练记录整理成一份文档，放在团队都能找到的地方。真正出问题时，能照着文档一步步做，比临时找人回忆要有用得多。