很多站点在服務器上挂了一條定时任務，把資料库和目錄打包传到對象存储，就觉得备份這件事已经做完了。真正出問题的时候才發現：压缩包是空的，資料库密碼想不起来，恢复要折腾大半天，恢复出来的站点還少了上传目錄。备份的價值不在于存了多少份，而在于需要的时候能不能在可接受的時間内把站点恢复成可用狀態。
先把备份清單列清楚
备份范围最好寫在文档里，而不是靠记忆。逐項核對，能避免漏掉那些看起来不起眼、丢了却很麻烦的部分。
- 資料库：文章、用戶、配置、评论、表單记錄。留意字符集與存储引擎，導入报错大多出在這里。
- 站点程序目錄：主题、插件、模板，以及被手動改過的核心文件。
- 用戶上传内容：图片、附件、媒体文件。這類文件体积最大，也最容易被排除在备份策略之外。
- 配置與凭據：Web 服務器配置、證书文件、环境變量、第三方接口密钥。
- 服務器层面的設定：計划任務、防火墙規則、反向代理規則、部署脚本。
备份文件本身也需要驗證
压缩包能不能正常解開
定期随机抽一個备份包，在临时目錄里解压，確認目錄结构完整、關键文件存在、資料库導出文件能被導入。只看到文件大小不為零，並不代表内容可用。曾经出現過的情况包括：备份脚本在没有權限的目錄下执行，生成了一個几乎空的包，而监控只检查了“文件是否存在”。
备份是否在按预期更新
查看最近的备份時間戳，和計划任務的時間對得上。如果连續几天没有新文件，而任務日誌顯示执行成功，通常說明脚本中途失敗了但没有把错誤传递出来。给备份任務加上失敗告警，比事後翻日誌更省事。
恢复演练可以按這個顺序走
- 准备一台與生产环境尽量接近的临时服務器，或者一台本地虚拟机。
- 只恢复資料库和程序目錄，先让站点能打開首頁和後台。
- 检查上传目錄是否完整，随机点開几篇文章的配图。
- 检查伪静態規則、跳轉規則和 HTTPS 配置，確認 URL 结构和线上一致。
- 记錄整個流程的耗时和卡住的步骤，把操作步骤补進文档。
- 演练結束後清理环境，避免临时站点被外部訪問或被抓取。
和抓取、运营的關系
备份策略看起来和蜘蛛、收錄没有直接關系，但故障恢复時間會直接体現在站点可用性上。長時間無法訪問，蜘蛛會降低抓取频率，恢复後也需要一段時間重新建立信任。恢复出来的临时环境如果暴露在公網，還可能被当成重复站点抓走一批内容。
恢复演练的目的不是證明备份完美，而是提前發現流程里那些只會在凌晨三点暴露的問题。
几個容易忽略的细节
- 备份文件放在對象存储时，確認訪問權限是私有的，不要把資料库導出挂在公開連結下。
- 資料库和文件目錄的备份時間要尽量接近，否則恢复後可能出現文章存在、配图缺失的情况。
- 保留至少一份异地或离线副本，防止誤删、勒索软件或帳號被盗时被一起清掉。
- 备份保留周期和磁盘空間要一起考虑，別让备份把服務器磁盘占满。
- 換人维護时，恢复文档和密钥的交接方式要寫清楚，避免只有一個人知道怎么做。
备份和恢复属于那種平时看不出收益、出事时决定损失大小的基础工作。把范围列清楚，把驗證和演练做成固定動作，站点在遇到故障时才有回旋余地。