备份這件事，顺利的时候没人提起，出問题的时候才發現它决定了站点要停多久。誤删一個栏目、升級插件失敗、資料库表损坏、服務器到期被回收，任何一種都足以让几個月的内容积累瞬間归零。這篇整理的是實操层面的自查思路，不是買什么产品的問题。
一、先盘点：到底要备份哪些東西
很多人對备份的理解停留在“導出資料库”，這遠遠不够。至少應覆盖以下几類：
- 程序與模板文件：主题、插件、二次開發的自定义代碼，尤其是直接改過核心文件的情况。
- 資料库：文章、用戶、评论、設定項，注意導出时要包含建表语句和字符集信息。
- 上传目錄與附件：图片、视频、下载文件，這通常是体积最大、也最容易被漏掉的部分。
- 服務器配置：Web 服務器規則、伪静態、PHP 版本與扩展、計划任務、防火墙策略。
- 證书與 DNS 记錄：SSL 證书文件與到期時間、域名解析记錄截图或導出文件。
- 對接信息：第三方接口密钥、邮件服務、對象存储的訪問凭據。
二、频率與保留：按更新节奏来定，而不是照抄模板
每天更新的站点，資料库适合每日备份；以静態頁為主、更新較慢的站点，每周一次也可以接受。關键在于保留多個版本，因為資料损坏往往不是当天發現的：
- 日备保留 7 到 14 天，用于應對誤操作。
- 周备保留 1 到 2 個月，用于應對延迟發現的故障。
- 月备保留半年以上，用于應對改版回退和合規需求。
保留策略要寫進配置里自動清理，否則磁盘迟早被舊备份塞满，而後面的备份任務會静默失敗。
三、存放位置：別把备份和站点放在同一個篮子
常见的错誤是把备份文件直接寫在站点同目錄、同一块磁盘，甚至同一個云帳號下。磁盘故障、誤删目錄、帳號被封，都會让資料和备份一起消失。可以參考 3-2-1 的思路：至少三份副本，存放在两種不同介质上，其中一份在异地。至少保證备份不依赖站点所在的那台机器和那個帳號。
四、恢复演练：备份能不能用，只有试過才知道
备份存在不等于可恢复。建议按下面的顺序定期演练一次：
- 准备一台干净的測試机器或临时环境，不要在生产环境上直接试。
- 拉取最近一份备份，先驗證压缩包是否完整、校驗值是否一致。
- 按文档恢复資料库與文件，记錄實际耗时和每一步卡住的地方。
- 检查前台首頁、栏目頁、詳情頁、後台登入、表單提交、图片加载是否正常。
- 更新恢复文档，寫清备份版本、操作人和發現的問题。
演练频率建议每季度一次，最低不要低于半年一次。換了服務器、換了存储方案、改了資料库版本之後，應当額外补做一次。
五、几個容易踩的坑
- 备份任務静默失敗：磁盘寫满、目錄權限不足、密钥過期，都可能導致连續多天没有新备份。
- 只备資料库，漏掉上传目錄，恢复後正文在、图片全丢。
- 压缩包加了密，密碼只存在某個人的聊天记錄里，人一离职就打不開。
- 备份里混入了測試环境的脏資料，恢复後线上出現一堆測試頁面。
- 恢复时忘记同步更新域名、證书路径、對象存储地址，頁面能開但资源 404。
- 没有记錄資料库版本和字符集，導入时报错却查不出原因。
六、把停机時間压到最短
恢复速度本身就是运营指标。長時間的 5xx 响應會让訪客直接离開，也會让搜尋引擎降低對這個站点的抓取意愿。條件允许的话，提前准备一個静態维護頁，在维護期間返回 503 狀態並带上 Retry-After 头，比直接返回空白頁或超时要友好得多。同时，域名到期時間、證书到期時間這類“可预测的故障”，用日歷提醒就能避免。
七、自查清單
- 資料库、程序文件、上传目錄是否都在备份范围内。
- 备份是否存放在與站点不同的机器或帳號下。
- 最近一次成功备份是什么时候，能否在後台看到狀態。
- 备份失敗是否有告警，還是只寫進日誌没人看。
- 恢复流程是否寫成文档，其他人照着能否操作。
- 最近一次恢复演练距今多久，当时暴露了哪些問题。
把這几項過一遍，通常能發現一两處平时没注意的缺口。备份不产生流量，也不直接带来收益，但它决定了前面所有运营工作有没有一個底线。