很多站点出事，不是因為被攻击，而是因為一次手滑：清理缓存时删错目錄、迁移时覆盖了資料库、插件升級把表结构改坏。备份這件事人人都在做，但真正能救命的备份，是那種被驗證過、确實能恢复的备份。
為什么“有备份”不等于“能恢复”
不少站点的备份狀態是這样的：脚本每天跑，压缩包确實生成，但從来没人打開看過。等到真出問题，才發現压缩包是 0 字节、資料库只導出了结构没有資料、或者恢复时字符集對不上，中文全變問号。备份的價值不在于文件數量，而在于恢复时的可用性。
常见的三個誤区
- 只备份資料库，不管上传目錄：文章丢了能补，图片和附件丢了几年的积累很难重新上传。
- 备份和站点放在同一台机器：服務器磁盘损坏或整机故障时，备份和源資料一起消失。
- 备份频率看心情：更新最频繁的栏目反而没有当天备份，出了問题只能回退到一周前。
一次完整备份應该覆盖什么
把下面這些列成清單，逐項確認，能避免“以為备了其實没备”的情况：
- 資料库完整導出，包含表结构和資料，注意字符集與排序規則。
- 上传目錄、图片、附件、用戶生成内容。
- 主题模板、插件、自定义代碼，尤其是被直接改過的文件。
- 站点配置文件、伪静態規則、SSL 證书與私钥。
- 定时任務列表、邮件配置、第三方接口密钥的存放位置說明。
除了文件本身，建议同时留一份“恢复說明”：這套站跑在什么环境、什么版本、恢复时先做哪一步。半年後回来看，你會庆幸当时寫了這几行字。
恢复演练：把备份真正跑一遍
演练不需要在生产环境做，找一台測試机或本地环境即可。流程大致如下：
- 從备份包里取出最新一份，按恢复說明逐步還原。
- 检查首頁、栏目頁、詳情頁能否正常打開，图片是否顯示。
- 随机抽查几篇較早的文章，確認正文完整、没有乱碼。
- 检查後台能否登入，發布一篇測試文章再刪除。
- 记錄整個恢复耗时，评估這個時間是否可接受。
建议把演练安排在版本升級、服務器迁移這類高風險操作之前做一次，效果最明顯。
演练中容易暴露的問题
- 备份包里缺少某個目錄，恢复後頁面样式错乱。
- 資料库版本不一致，導入时报语法错誤。
- 域名或路径寫死在配置里，換环境後無法訪問。
- 恢复脚本依赖某個已经不存在的帳號權限。
备份文件的存放與訪問控制
一個经常被忽略的细节是：备份文件被随手放在網站根目錄下，文件名又比較好猜，很容易被掃描器掃到，也可能被搜尋蜘蛛抓到並留下记錄。压缩包一旦可公開下载，等于把整個站点的資料挂在公網上。
更稳妥的做法是把备份放在 Web 根目錄之外，或者放到獨立的存储空間；如果确實要放在站点目錄内，至少通過服務器規則限制訪問，並给文件名加上随机串。同时定期清理過期备份，避免磁盘被寫满，反而拖停站点。
日常检查清單
- 备份任務最近一次执行時間是否正常，文件大小是否合理。
- 是否至少有一份异地或异机备份。
- 备份文件是否可被外部直接訪問。
- 最近三個月内是否做過一次恢复演练。
- 升級、迁移、批量改資料之前，是否手動做過一次快照。
备份不是一項装完就不用管的功能，而是一套需要定期驗證的流程。花半小时做一次演练，可能省下的是几個月的返工。