很多站点出事的时候，才發現自己的备份從来没被真正打開過。备份文件躺在那里，大小看着正常，真到要恢复时却解压失敗、缺表、少文件，或者根本没有對應的程序版本。备份的價值不在于「有」，而在于「能還原到一個可用的狀態」。
先把两個數字说清楚：RPO 與 RTO
在讨论备份策略前，先给自己定两個目标值，後面所有决策都围绕它們展開：
- RPO（可接受的資料丢失量）：最坏情况下你能接受丢掉多長時間的資料？如果按天备份，就意味最多丢一天的内容。
- RTO（可接受的恢复耗时）：從確認出事到站点重新可用，你能接受多久？這個數字决定了你需要的是「下载备份再慢慢传」，還是「有現成镜像能直接切」。
這两個值不需要很漂亮，但要真實。寫清楚之後，再去看現有备份方案能不能满足，缺口通常一眼就能看出来。
备份到底要覆盖哪些東西
只备資料库是最常见的疏漏。一個能跑起来的站点，至少包含下面几類内容：
- 資料库：内容、用戶、配置項大多在這里。
- 上传目錄與静態资源：图片、附件、用戶上传的文件，通常体积最大，也最容易漏。
- 程序代碼與主题插件：记錄清楚版本号，最好保留一份未改動的原始包。
- 配置文件：資料库连接、密钥、伪静態規則、环境變量，這些往往不在版本库里。
- 服務器层面的東西：Nginx / Apache 配置、定时任務、證书文件、防火墙規則。
如果站点用了對象存储或第三方服務存资源，也要確認這些服務本身有没有版本控制或回收站，別預設它們一定安全。
三個高频誤区
备份和站点在同一台服務器上
這是最危險的一種。服務器被重装、磁盘损坏、被入侵加密，备份會跟着一起没。至少要做到异地或异盘存放，哪怕只是定期拉一份到本地或另一家對象存储。
备份文件能被公網直接訪問
备份目錄放在網站根目錄下，等于把整站資料和配置對外公開。记得检查目錄權限、禁止目錄列表，並把备份放在 Web 根目錄之外。
只驗證了文件大小，没驗證内容
备份任務返回成功，不代表文件完整。压缩包截断、資料库導出中途报错、定时任務其實半年前就停了，這些都不會主動通知你。建议至少每月做一次自動校驗：尝试解压、尝试導入到一個临时資料库、检查關键表行數是否合理。
恢复演练怎么做
演练的目标不是「證明备份能用」，而是「發現流程里缺了什么」。在临时环境里按下面的顺序走一遍：
- 准备一台干净的临时服務器或容器，尽量不要复用生产环境。
- 從备份源拉取最新一份完整备份，记錄下载耗时和文件大小。
- 搭建與生产一致的程序版本和執行环境，包括 PHP、資料库、扩展版本。
- 導入資料库，观察是否有报错、字符集問题、表缺失。
- 恢复上传目錄和静態资源，检查文件數量與總大小是否對得上。
- 還原配置文件、伪静態規則、定时任務。
- 把域名临时指向測試环境，检查首頁、栏目頁、詳情頁、搜尋、表單提交是否正常。
- 检查後台能否登入，图片能否顯示，頁面是否报 404 或 500。
- 记錄整個流程的耗时，對比事先定下的 RTO。
如果站点依赖 HTTPS 證书，演练时也要把證书一並還原，避免只驗證了 HTTP 层就以為通過。
演练之後要留下什么
- 一份可执行的步骤清單，谁照着做都能走完。
- 實际恢复耗时，以及卡在哪一步。
- 發現的缺口，比如某個目錄没人备份、某項配置只存在某個人电脑里。
- 备份任務的负责人和下次演练時間。
备份是流程，不是文件。文件只說明你曾经备份過，流程才說明你能恢复。
演练频率不必太高，但要有节奏：内容更新频繁的站点可以每季度一次，更新較少的半年一次也够。重要的是每次都走完整流程，而不是只在脑子里過一遍。等到真的需要恢复的那天，你會發現省下的這几十分钟，價值遠超预期。