很多站点出事不是因為没有备份，而是因為备份“看起来存在”。文件躺在服務器同一块磁盘上，压缩包设了密碼却没人记得，資料库導出到一半被中断——真到需要恢复的时候才發現用不上。這篇自查清單不聊工具選型，只聊怎么確認手里的备份在關键时刻能派上用场。
一、先列清楚：哪些東西必须進备份
只备份資料库是常见誤区。資料库里是内容，但让站点跑起来的不只是内容。
- 資料库：文章、用戶、评论、配置項，通常是恢复时最關键的一份。
- 上传目錄：图片、附件、音视频。這部分往往体积最大，也最容易在迁移时被漏掉。
- 程序與模板文件：主题改動、插件、自定义模板片段。如果改過代碼却没進版本控制，它就是孤本。
- 配置文件：資料库连接信息、伪静態規則、环境變量。
- 證书與密钥：HTTPS 證书私钥、第三方接口密钥，丢了要重新申請和配置。
- 定时任務與脚本：备份、清理、同步這些 crontab 任務，很多人在迁移後才發現少了几個。
二、频率和保留策略：別只留最近一份
备份频率應该跟着“你能承受丢多少資料”走，而不是跟着习惯走。
- 資料库：訪問量正常的站点可以每天一次全量；更新频繁的站点考虑每天多次增量或開啟二進制日誌。
- 文件：上传目錄按周全量即可，程序文件在每次改動後單獨留一份。
- 保留：常见做法是保留最近 7 天的日备、最近 4 周的周备、最近 3 個月的月备。只留最近一份，等于被誤删的内容也會被一起覆盖掉。
- 把“動手前先备份”寫進流程，尤其是批量删文章、清评论、調整栏目结构之前。
三、恢复演练：能打開压缩包不等于能恢复
建议每季度至少做一次完整演练，找一台測試机，不要在生产环境上试。
- 准备獨立环境，域名可以用临时域名或本地 hosts 指向。
- 導入資料库备份，注意字符集和版本差异，導入报错要记錄下来。
- 恢复文件目錄，核對權限與属主，別用 777 图省事。
- 改回測試环境的连接配置，检查首頁、栏目頁、詳情頁、後台登入是否正常。
- 抽查图片和附件能否打開，確認上传目錄完整。
- 记錄整個恢复耗时。如果明顯超出预期，說明备份结构需要調整，比如把大文件拆開單獨存放。
四、几個容易被忽略的细节
- 备份文件放在哪里：和站点同一台服務器、同一块磁盘，服務器一挂就一起没了。至少同步一份到對象存储或另一台机器。
- 备份文件能否被公網訪問：放在網站根目錄下的 backup 文件夹，等于把資料库公開下载。放到 web 目錄之外，或加上訪問限制。
- 脚本里的密碼：备份脚本中寫死的資料库密碼、云存储密钥，文件權限要收紧，也別提交到公開仓库。
- 任務是否真的在跑：备份失敗往往是静默的。加一條失敗告警，或让脚本成功後發一封邮件，長時間收不到就說明有問题。
- 备份對站点的影响：大表導出可能鎖表並占用磁盘 IO，尽量安排在訪問低谷，導出後检查磁盘剩余空間。
- 清理舊备份：只增不删的策略迟早把磁盘寫满，刪除規則也要寫進脚本。
五、月度自查清單
- 確認最近一次資料库备份和文件备份的時間、大小正常。
- 確認备份文件已同步到异地或對象存储。
- 随机下载一個备份包，试解压，確認没有损坏。
- 確認备份目錄不在公網可訪問路径下。
- 检查备份任務的失敗告警是否有效。
- 检查磁盘剩余空間，確認舊备份清理按計划执行。
- 如果本季度還没做恢复演练，安排一次。
备份的價值不在于文件有多少個，而在于你需要它的那一天，它能不能被打開、被導入、被訪問。把恢复演练当成例行工作，比多買一块硬盘更有用。