很多站点在出事之前都觉得自己“有备份”：主机商说每天备份，插件说自动备份，自己偶尔也下载一份数据库。真到误删、被入侵或者服务器挂掉的那天，才发现备份要么缺了一半，要么根本恢复不回来。备份的价值不在文件躺在哪里，而在需要的时候能不能在可接受的时间内，把站点还原成一个能用的状态。
先分清：备份、冗余和快照不是一回事
冗余解决的是硬件故障，比如磁盘做 RAID，但误删和勒索软件会照样同步过去。快照适合短时间回滚，通常和原服务器在同一套存储里，机房整体出问题时一起消失。备份要求的是独立存储、可校验、可恢复。三者可以同时存在，但不能互相替代。
一份能用的备份应该覆盖什么
- 数据库：文章、用户、评论、配置项，通常是恢复时最关键的部分；
- 上传目录与媒体附件：图片、视频、下载文件，往往体积最大也最容易被漏掉；
- 主题、插件与自定义代码：尤其是直接改过服务器上文件的情况；
- 配置文件：Web 服务器规则、伪静态、环境变量、定时任务脚本；
- 证书与密钥：续期文件和私钥丢了，恢复后还要重新申请；
- 数据库账号、队列与缓存组件的配置说明，方便在新机器上快速搭起来。
频率与分层：别用一套策略应付所有内容
- 高频层：数据库增量或每日全量，覆盖当天新增内容；
- 中频层：整站文件加数据库，每周一次，保留若干份历史版本；
- 低频层：每月或每季度归档一份到异地，用于应对长期未被发现的篡改。
保留策略要写清楚：保留多久、只留最新还是保留多份、谁有权删除。只往一个目录里堆备份文件，最后往往是磁盘被写满，新备份悄悄失败。
恢复演练：把“应该能恢复”变成“确实恢复过”
- 找一台与生产环境隔离的机器或临时环境；
- 从备份取最新一份，按文档走完整流程，不跳步骤；
- 检查站点能否打开、后台能否登录、附件能否显示、伪静态是否正常；
- 记录耗时：从开始到站点可用一共花了多少分钟；
- 把遇到的问题补进恢复文档，比如某个插件需要单独配置，某条规则没被备份进去。
演练不需要每次都很正式，但最好固定周期，比如一个季度一次。流程没跑过，就等于没有流程。
常见误区
- 备份文件和站点在同一块盘、同一台机器上；
- 只备份数据库，恢复后发现图片和附件全丢；
- 备份文件没有校验，解压时才发现损坏；
- 备份里带着旧域名和旧路径，恢复后忘了替换；
- 没有记录备份时间和版本，恢复时不知道该用哪一份；
- 备份文件权限过宽，或者放在可被公网访问的目录里。
判断备份是否可靠，最简单的问题是：如果现在服务器全部丢失，你能在多长时间内让站点重新可访问？答不上来，就说明该做一次演练了。
让备份也进入日常监控
把备份任务的成功与失败接入告警，失败时能收到通知，而不是等几个月后翻目录，才发现最近的文件日期停在很久以前。同时定期抽查备份文件能否解压、体积是否异常，必要时对关键目录做一次哈希核对。备份日志与恢复记录也建议保留，谁在什么时候恢复过、恢复的是哪一份，日后排查内容差异时会用得上。
备份这件事没有一劳永逸的做法，站点内容在变、依赖在变、经手的人也在变，策略要跟着调整。把它当成常规运营的一部分，比出事之后临时找文件要从容得多。