很多人以为备份就是定期导出一份数据库，真出问题时才发现少了图片、少了配置，或者导出的文件本身打不开。判断备份够不够，标准只有一条：能不能在另一台机器上恢复出可用的站点。
一、三种常见方案
| 方案 | 做法 | 能覆盖的风险 | 仍然存在的缺口 |
|---|---|---|---|
| 手动导出 | 想起来时导一次数据库和附件 | 误删文章、误改配置 | 依赖人记得，间隔不稳定 |
| 定时全量快照 | 每天打包站点目录与数据库 | 程序升级失败、目录被误删 | 同机存放时，机器故障会一起丢 |
| 分离同步 | 数据库定时导出，文件增量同步到异地 | 磁盘故障、机房问题 | 恢复步骤较多，需要演练 |
二、至少要覆盖的三层
- 数据层：数据库定期导出，保留最近若干份，避免只留一份被覆盖；
- 文件层：上传的图片、附件单独同步，不要只备份代码；
- 配置层：站点配置、伪静态规则、证书清单一并留存，恢复时最容易被忽略。
三、备份频率怎么定
按内容更新节奏来。每天更新内容，数据库至少每天一次；图片和附件按周增量同步即可。保留周期按「发现问题的平均时间」来估：如果一次误操作常常几天后才发现，就至少保留两周的份数。
四、真正决定成败的是演练
备份文件存在不等于能恢复。每隔一段时间做一次恢复演练：在一台临时环境里解包、导入数据库、改配置、打开首页与文章页，确认没有报错。演练过一遍，才会发现缺了证书、缺了某个目录权限、或者导出文件被截断。
演练清单
- 解包站点目录，确认文件数量与线上接近；
- 导入数据库，检查文章总数与最新一篇是否在；
- 打开首页、分类页、文章页，确认状态码 200；
- 抽查附件与图片能否正常显示；
- 记录本次演练耗时，下次按同一流程再走一遍。
五、给个人站长的建议
预算有限时，优先做到「定时 + 异地 + 可恢复」这三件事，而不是追求备份工具多高级。把备份脚本挂在定时任务里，把结果写进日志，每周扫一眼日志，比临时想起来导一次更可靠。
更多建站与运维类整理，可以按分类继续看：科技与建站分类。