很多站点第一次真正關心备份，是在資料丢了以後。备份這件事的麻烦之處在于：配置一次很容易，驗證它到底能不能用，却需要主動花時間。等到出事再發現备份是空的、解压失敗、或者資料库導不進去，代價就大了。這篇把备份和恢复演练拆成一份自查清單，按顺序過一遍即可。
一、先明确到底要备份什么
只备份資料库是常见的疏漏。一個能完整還原的备份，通常包含下面几類内容：
- 程序文件與模板：主题、插件、自定义的静態资源，出了問题时能直接覆盖回去。
- 上传目錄與媒体库：图片、附件、用戶上传文件，這部分体积往往最大，也最容易被忽略。
- 資料库：文章、用戶、评论、設定項，導出时记得带上建表语句。
- 配置文件：資料库连接、伪静態規則、定时任務、环境變量。
- 證书與密钥：SSL 證书、部分接口的密钥文件。
- 外部配置的记錄：DNS 解析、CDN 回源規則、防護策略。它們不在服務器上，但恢复时一定會用到。
二、备份频率與保留策略
频率跟着更新节奏走。内容每天更新的站点，資料库建议每天一次；文件變化不大，可以每周一次，或者在每次改版、装插件前手動做一次全量。保留策略上，至少留 7 份日常备份加 4 份周备份，再留几份月度归档，用来應對那種「很久以後才發現被改坏」的情况。
只有一份备份，等于没有备份。它和源資料同时损坏的概率，比想象中高。
三、存放位置：別和源站睡在一台机器上
备份文件和站点放在同一块硬盘、同一台服務器上，遇到整机故障、誤删目錄、勒索加密，基本是一起没。比較稳妥的做法是两份：一份放在本地或挂载盘，用于快速回滚；一份推到對象存储或异地服務器，用于兜底。放在 Web 可訪問目錄下的备份包，還要確認目錄没有被浏览、没有被搜尋引擎抓到。
四、恢复演练：把流程真的走一遍
先准备一個隔离环境
用測試域名、獨立的資料库實例，並且断開對外的邮件、短信、支付接口。演练的目的是驗證資料完整，不是让測試站点真的對外發通知。
演练步骤
- 解压备份包，核對文件數量與總体积，和上次备份對比是否有異常缩减。
- 導入資料库，检查表數量、關键表的行數是否與预期接近。
- 調整配置里的域名、資料库帳號等环境相關項。
- 依次訪問首頁、栏目頁、詳情頁、搜尋頁和表單提交，看是否正常渲染與响應。
- 抽查几個關键頁面，和线上内容做比對，確認不是舊版本。
- 记錄整個恢复耗时、卡住的环节和报错信息，补進恢复手册。
五、几個驗證备份可用性的小检查
- 备份文件大小是否和上次接近，突然變小要立刻查原因。
- 压缩包能否正常解压，是否設定了口令而口令没人记得。
- 資料库導出文件里是否包含完整的建表语句，而不只是資料。
- 恢复後图片、附件能否正常顯示，路径是否需要重寫。
- 定时备份任務是否真的有成功记錄，而不是静默失敗。
六、记錄與權限
把恢复流程寫成一份可执行的文档：备份放在哪、怎么下载、用什么命令導入、遇到报错找谁。备份文件本身建议加密，訪問權限收窄到必要的人。人一換、時間一久，没有文档的流程等于不存在。
七、常见的坑
- 只备份資料库，忘了上传目錄，恢复後满站图片丢失。
- 定时任務失敗没有告警，连續几個月没有新备份。
- 备份包放在可下载目錄，被掃描工具抓走。
- 演练时誤把測試站连到生产資料库，反而制造了事故。
备份的價值不在文件本身，而在恢复那一刻。建议把恢复演练排進固定的运营节奏，比如每季度一次，让流程保持可用，也让接手的人心里有底。