服务器磁盘故障、误删目录、插件升级冲突、站点被挂马，这些事发生之前通常没有任何预告。备份属于那种平时毫无存在感、出事时决定生死的工作。但很多站点的真实情况是：备份任务设了半年没人看，唯一一次打开备份文件是在事故当天。
先想清楚：丢什么最疼
备份范围不是越全越好，而是先列出「丢了会直接停摆」的东西，再按重要性排序。
- 数据库：文章、用户、评论、设置项。这是绝大多数站长最先想到的，也常常是唯一被备份的。
- 上传目录：图片、附件、视频。数据库里只有路径，文件本身没了，文章就是一堆红叉。
- 代码与主题：自己改过的模板、函数文件、子主题。官方主题可以重下，改动过的那几行往往找不回来。
- 配置文件：数据库连接信息、密钥、伪静态规则、定时任务列表。这些文件体积很小，漏掉却会让恢复卡住。
- 证书与私钥：如果申请和管理是自己做的，最好单独留存一份。
把这份清单写下来，标出每一项的更新频率，后面的备份策略才有依据。
频率、保留份数与存放位置
频率跟着更新节奏走。内容日更的站点，数据库建议每天一次；更新不频繁的展示型站点，每周一次也够。附件目录变化少，可以降低频率，但不要完全不备。
- 保留结构可以简单一些：日备留 7 份，周备留 4 份，月备留 6 到 12 份，形成由近及远的覆盖面。
- 至少有一份不放在同一台服务器上。同一台机器上的备份，遇上磁盘故障或整机重装基本等于没有。
- 备份文件要么加密，要么放在有访问控制的目录里，不要让它能被匿名下载。
- 每次备份完成后记录体积。体积突然暴涨或暴跌，通常意味着备份过程出了问题，值得查一下。
三个常被忽略的细节
备份文件别放在网站根目录
有些一键脚本默认把压缩包丢在站点目录下，文件名又很好猜。一旦被扫到，数据库里的用户信息、后台账号就都暴露了。备份目录应当放在 web 根目录之外，或者用服务器层面禁止直接访问。
只备数据库不备附件
恢复之后文章都在，配图全丢，这种情况比想象中常见。附件目录要么一起打包，要么单独做同步。
恢复了才发现少了定时任务和伪静态
数据库和文件都还原了，结果缓存清理、订阅推送、备份自身的任务全没了；伪静态规则没恢复，内页直接 404。这类问题不影响登录，但会让站点功能残缺，排查起来很费时间。
恢复演练：按步骤走一遍
备份能不能用，只有恢复过才知道。建议每隔一段时间做一次演练，在本地或测试环境完整走一遍流程。
- 准备一个干净的测试环境，不要拿生产站当实验对象。
- 导入数据库，确认表前缀与备份时一致。
- 还原上传目录，检查文件和目录权限。
- 覆盖配置文件，按测试环境修改域名与路径。
- 依次打开首页、栏目页、详情页、后台、站内搜索。
- 检查图片是否正常显示，表单能否提交，伪静态是否生效。
- 记录整个恢复花了多少时间，以及中途遇到的所有问题。
演练的价值不在于证明备份完美，而在于把「到时候再说」变成一份写好的操作清单。真出事的时候，人往往是慌的，有清单和没清单差别很大。
备份任务本身也要照顾站点
导出大表、压缩大量附件都会占用磁盘和 CPU。如果服务器配置一般，可以把备份时间安排在访问低谷，避开蜘蛛抓取较集中的时段，避免因为响应变慢影响正常访问。备份失败的告警也要有人收，任务静默失败几个月，和没设任务区别不大。
备份的意义不在于硬盘上多了一个文件，而在于需要它的那天，你能在可接受的时间内把站点恢复起来。
建议把「检查备份是否成功」和「做一次恢复演练」写进日常维护清单，各自定一个周期。它们是那种做的时候看不出收益、不做的时候代价很高的活。