很多站长对备份的态度是：脚本配好了，每天定时跑，硬盘里躺着一堆压缩包，心里就踏实了。但备份的价值从来不是“产生文件”，而是“能还原出可用的站点”。如果从没验证过恢复流程，那些文件只能算心理安慰。
一份完整的站点备份该包含什么
只备份数据库是常见的偷懒做法。程序文件、模板、配置、证书私钥这些东西丢了，数据库再完整也拼不回原来的站点。
- 数据库全量导出：注意导出时的字符集和版本，跨版本导入经常出问题。
- 站点程序与上传目录：用户上传的图片、附件往往体积最大，也最容易被忽略。
- 服务器配置：Nginx 或 Apache 的站点配置、robots.txt、重定向规则、伪静态规则。
- 证书与密钥：SSL 证书、私钥、必要的环境变量文件。
- 定时任务与脚本：crontab 列表、备份脚本本身、部署脚本。
三个最常见的备份盲区
备份文件和站点在同一台机器上
硬盘故障、系统重装、误删目录，这三件事会同时带走站点和备份。至少留一份异地或对象存储的副本，成本不高，但能救命。
备份任务失败没人知道
磁盘写满、数据库账号变更、密钥过期，都会让定时任务静默失败。建议让备份脚本在结束时输出一个明确的结果，失败时通过邮件或短信告警，而不是只在日志里留一行字。
没人测过恢复
备份文件能打开、能解压，不等于能恢复到可运行状态。压缩包损坏、分卷缺失、导出中断只写了一半，这些问题只有真正导一次才会暴露。
恢复演练怎么做
- 准备一台测试机或本地环境，不要在生产服务器上做演练。
- 按正常流程安装程序，导入数据库，覆盖上传目录，恢复配置文件。
- 检查首页、栏目页、详情页是否正常打开，后台能否登录。
- 抽查若干条内容，确认图片、附件、发布时间等数据完整。
- 检查 robots.txt、重定向规则、SSL 配置是否随备份一起恢复。
- 记录整个恢复过程耗时，作为故障时的预期参考。
频率和保留策略
没有统一标准，取决于更新频率和能承受丢失多少数据。
- 内容更新频繁的站点，数据库可以每天一次，程序文件每周一次。
- 低频更新的站点可以缩短到每周，但配置类文件建议每次修改后单独存一份。
- 保留“近期多个版本 + 每月一个长期版本”，避免某个被感染的备份把干净版本覆盖掉。
- 定期清理过期备份，防止磁盘被塞满导致备份任务失败。
判断备份是否可靠，标准只有一个：能不能在另一台机器上，把站点完整跑起来。
把演练写进日常
可以把恢复演练排进季度或半年一次的运维清单，顺手更新记录：备份存放位置、恢复步骤、所需账号权限、大概耗时。人员变动时，这份记录能让接手的人少走很多弯路。
备份这件事平时看不出收益，出事那天却是唯一的退路。花半天做一次演练，比事后补救便宜得多。