备份这件事，最容易被“存在就算安全”误导
不少站点的后台里挂着一个定时任务，每天凌晨导出一份数据库，文件往服务器某个目录一丢，任务日志显示成功，大家就默认数据是安全的。问题在于：任务成功只代表文件写出来了，不代表这个文件能还原成一个可访问的站点。真正出事的时候——误删栏目、批量改错内容、服务器磁盘故障、程序升级把数据库结构改坏——你会发现考验的不是有没有备份，而是多久能把站点恢复到可用状态。
所以这件事的检查重点，应该从“备份任务是否在跑”转向“恢复流程是否验证过”。
先盘清楚：站点到底有哪些东西需要备份
只备份数据库是很多站点的常见缺口。下面这些建议逐项确认：
- 数据库：文章、用户、评论、配置项、栏目结构，通常是最关键的一份。
- 程序与模板文件：包含你改过的主题文件、插件、自定义代码，很多改动只存在于服务器上，本地并没有留底。
- 上传的媒体资源：图片、附件、视频。这类文件体积大，容易被排除在备份之外，但丢起来最难补。
- 服务器配置：Web 服务器配置、伪静态规则、PHP 或运行环境参数、计划任务脚本。
- 证书与密钥：HTTPS 证书文件、私钥、第三方接口的密钥配置。
- 域名与解析记录：DNS 记录的当前值、CDN 配置、邮箱解析，建议单独截图或导出文本留档。
把这份清单列出来对照一遍，通常能发现两三个“以为有、其实没有”的缺口。
频率和保留策略：跟着更新节奏走
备份频率没有统一标准，取决于你的更新强度。内容每天更新多次的站点，数据库可以做到每天一次甚至更高频率；以静态页面为主、偶尔改动的站点，每周一次也够用。关键是让备份频率和“你能接受丢多少数据”对得上。
保留策略上，建议至少保留三到四个时间点的版本，而不是只留最新一份。原因很直接：如果一份数据被错误覆盖，而你在几天后才发现，只有最新备份的话，错误版本已经把旧版本挤掉了。采用“近几次密集、较早期稀疏”的组合，能在容量和可回溯性之间取得平衡。
恢复演练怎么做才有效
演练不等于“打开压缩包看看里面的文件在不在”。比较有效的做法是找一份真实备份，在另一个目录或临时环境里完整走一遍：
- 准备一个与线上环境尽量接近的临时空间，比如同版本的运行环境、一个空数据库。
- 导入数据库，留意字符集、排序规则、表前缀这些细节是否一致。
- 解压程序与媒体文件，检查目录权限是否正确。
- 改好临时环境的访问配置，把站点跑起来，逐项点开：首页、栏目页、内容页、后台登录、图片是否显示、伪静态是否正常。
- 记录整个流程走了多久、卡在哪一步、需要哪些额外信息。
演练的核心产出有两条：一是确认备份可用，二是得到一份真实的恢复耗时。如果一次完整恢复要花六个小时以上，你就该考虑优化流程，而不是等到故障当天才发现。
演练时遇到最多的问题往往不是数据本身，而是“不知道当初的配置放在哪”“某个密钥只有某个人手里有”。这类问题越早暴露越好。
备份文件本身的几个坑
- 和站点放在同一台机器：机器挂了，备份跟着一起没了。至少放一份到独立位置，本地、对象存储、异地各留一处更稳妥。
- 备份目录可以被公网访问：这是相当严重的隐患。数据库导出文件如果落在网站根目录下，等于把整站数据公开挂在网上。建议把备份放在 Web 根目录之外，并确认访问不到。
- 没有失败告警：任务失败往往悄无声息。建议让脚本在异常时发通知，哪怕只是一封邮件，也比默认“应该是成功的”要好。
- 备份文件无限堆积：磁盘被自己的备份塞满，会连带影响站点运行。定期轮转清理，别只增不减。
把恢复步骤写成文档
恢复这件事最好不要依赖某个人的记忆。把命令、路径、账号的存放位置、联系谁拿权限，写成一份简短的步骤说明，放在团队都能找到的地方。文档不需要多正式，能让人在紧张状态下照着做下来就行。随着服务器环境变化，记得同步更新。
一份可以照着做的自查清单
- 数据库、程序文件、媒体资源、服务器配置是否都在备份范围内？
- 备份频率是否与更新强度匹配，能否接受最坏情况下的数据丢失量？
- 是否保留了多个时间点的版本，而不是只有最新一份？
- 备份是否存放在独立位置，且无法被公网直接访问？
- 最近一次恢复演练是什么时候，实际耗时多久？
- 备份任务失败时，有没有人会被通知到？
- 恢复步骤是否成文，且不依赖单个成员的记忆？
这些问题不需要一次全部解决，先找出风险最高的那一两项动手处理，比反复确认“备份任务昨天跑成功了”要有意义得多。