备份這件事，很多站点都是“设了定时任務就当作做完了”。真正出問题时才會發現：备份文件是空的、只备份了資料库、恢复後舊連結全變成 404、备份压缩包還能被任何人直接下载。备份的價值不在“有”，而在需要时能不能恢复，恢复得對不對。
先確認备份范围是否完整
只备份資料库是常见的誤判。一個能正常运轉的站点，至少包含几類彼此依赖的資料。
- 資料库：内容、用戶、评论、配置項、表單记錄。注意字符集與排序規則，恢复时不一致容易出現乱碼。
- 程序與模板文件：包含改動過的主题、插件、函數文件，升級出問题後回滚要靠它。
- 上传的媒体與附件：图片、视频、下载文件、用戶上传目錄，往往体积最大，也最容易被排除在备份任務之外。
- 服務器與站点配置：Nginx 或 Apache 配置、伪静態與重定向規則、.htaccess、計划任務脚本、环境變量文件。
- 證书與密钥：HTTPS 證书、私钥、CDN 回源鉴權信息。丢了要重新簽發，恢复時間會被拉長。
- 外部配置记錄：DNS 解析记錄、CDN 缓存規則、對象存储權限策略。這些不常改，但恢复时最容易漏。
判断备份是否完整的简單办法：把這套备份恢复到一台干净的服務器上，站点能不能直接打開、連結能不能正常跳轉。
频率、保留與存放方式
备份频率要跟着内容更新速度走。日更多次的资讯站，只保留每周一份，丢失的可能是整周内容；更新很慢的企业站，每小时做全量备份又是浪費。
- 采用全量加增量的组合：全量保證可獨立恢复，增量控制备份窗口與存储成本。
- 设定保留代际，例如近 7 天每日一份、近 4 周每周一份、近 12 個月每月一份。只留最新一份，一旦最新备份也被污染就没有退路。
- 至少一份放在與生产环境不同的位置，机器故障、机房問题、誤删權限不會同时波及。
- 备份文件不要放在網站可訪問目錄下，也不要用可猜测的文件名。歷史备份被公開下载，等于把資料库结构和用戶信息一起交出去。
- 定时脚本要有执行结果记錄，失敗要能發出告警，而不是安静地失敗几個月。
恢复演练：重点看恢复後的站点是否“像原来一样”
演练不必每次全量重建，可以定期在測試环境恢复最近一份备份，然後按清單核對。這一步能暴露绝大多數問题。
- 站点能否正常打開，首頁、栏目頁、詳情頁各抽几個訪問。
- URL 结构是否與线上一致，包括目錄层級、大小寫、末尾斜杠處理。
- 重定向規則是否生效：舊的地址、www 與非 www、HTTP 到 HTTPS 是否指向正确。
- robots.txt、站点地图、canonical 指向的域名是否還是原来的域名，避免恢复成測試域名後忘了改回。
- 静態资源域名與 CDN 配置是否對應，图片、样式、脚本能否正常加载。
- 附件目錄是否完整，随机抽查几張較早的图片。
- 計划任務、缓存清理、队列進程是否重新啟動。
- 表單提交、站内搜尋、登入等依赖資料库的功能是否正常。
演练完成後记錄耗时和踩到的坑。真正的故障恢复是按分钟計成本的，提前走過一遍流程，比临时翻文档要可靠得多。
容易被忽略的几個细节
- 恢复期間頁面不要長時間返回正常的 200 首頁。站点不可用时應返回明确的 503，並带上重试提示，避免蜘蛛把空白或占位頁抓走。
- 恢复後注意時間戳與缓存：有些静態缓存、CDN 缓存仍指向舊版本，需要主動刷新。
- 資料库導出如果加鎖方式不当，可能在大表上鎖住寫入，影响线上訪問。建议放在低峰时段执行並检查耗时。
- 日誌與备份分開管理：訪問日誌、错誤日誌在排查問题时很有用，但体积增長快，保留周期可以與資料备份不同。
- 恢复後確認重定向規則是否随配置一起恢复，否則老連結會直接變成 404，用戶和搜尋引擎同时受影响。
- 涉及用戶資料的备份要考虑合規，導出、传輸、存放都應限制訪問權限。
把备份检查放進日常巡检
备份不是一次性的項目，而是需要定期確認的例行事項。可以固定每周或每月检查几件事：最近一次备份是否成功、备份文件大小是否異常、能否正常解压、异地副本是否同步、恢复演练是否按計划完成。把這些检查结果记錄下来，出問题时才有判断依據。
站点恢复能力是运营的一部分，但很难在顺利的时候体現價值。它更像保險：平时占不了多少精力，需要的时候能决定站点是几小时恢复，還是几天回不来。
一句话自查：如果現在生产环境的資料全部丢失，你手上最近的一份备份，能恢复到什么程度？