服務器磁盘故障、誤删目錄、插件升級冲突、站点被挂马，這些事發生之前通常没有任何预告。备份属于那種平时毫無存在感、出事时决定生死的工作。但很多站点的真實情况是：备份任務设了半年没人看，唯一一次打開备份文件是在事故当天。
先想清楚：丢什么最疼
备份范围不是越全越好，而是先列出「丢了會直接停摆」的東西，再按重要性排序。
- 資料库：文章、用戶、评论、設定項。這是绝大多數站長最先想到的，也常常是唯一被备份的。
- 上传目錄：图片、附件、视频。資料库里只有路径，文件本身没了，文章就是一堆红叉。
- 代碼與主题：自己改過的模板、函數文件、子主题。官方主题可以重下，改動過的那几行往往找不回来。
- 配置文件：資料库连接信息、密钥、伪静態規則、定时任務列表。這些文件体积很小，漏掉却會让恢复卡住。
- 證书與私钥：如果申請和管理是自己做的，最好單獨留存一份。
把這份清單寫下来，标出每一項的更新频率，後面的备份策略才有依據。
频率、保留份數與存放位置
频率跟着更新节奏走。内容日更的站点，資料库建议每天一次；更新不频繁的展示型站点，每周一次也够。附件目錄變化少，可以降低频率，但不要完全不备。
- 保留结构可以简單一些：日备留 7 份，周备留 4 份，月备留 6 到 12 份，形成由近及遠的覆盖面。
- 至少有一份不放在同一台服務器上。同一台机器上的备份，遇上磁盘故障或整机重装基本等于没有。
- 备份文件要么加密，要么放在有訪問控制的目錄里，不要让它能被匿名下载。
- 每次备份完成後记錄体积。体积突然暴涨或暴跌，通常意味着备份過程出了問题，值得查一下。
三個常被忽略的细节
备份文件別放在網站根目錄
有些一键脚本預設把压缩包丢在站点目錄下，文件名又很好猜。一旦被掃到，資料库里的用戶信息、後台帳號就都暴露了。备份目錄應当放在 web 根目錄之外，或者用服務器层面禁止直接訪問。
只备資料库不备附件
恢复之後文章都在，配图全丢，這種情况比想象中常见。附件目錄要么一起打包，要么單獨做同步。
恢复了才發現少了定时任務和伪静態
資料库和文件都還原了，结果缓存清理、订阅推送、备份自身的任務全没了；伪静態規則没恢复，内頁直接 404。這類問题不影响登入，但會让站点功能残缺，排查起来很費時間。
恢复演练：按步骤走一遍
备份能不能用，只有恢复過才知道。建议每隔一段時間做一次演练，在本地或測試环境完整走一遍流程。
- 准备一個干净的測試环境，不要拿生产站当實驗對象。
- 導入資料库，確認表前缀與备份时一致。
- 還原上传目錄，检查文件和目錄權限。
- 覆盖配置文件，按測試环境修改域名與路径。
- 依次打開首頁、栏目頁、詳情頁、後台、站内搜尋。
- 检查图片是否正常顯示，表單能否提交，伪静態是否生效。
- 记錄整個恢复花了多少時間，以及中途遇到的所有問题。
演练的價值不在于證明备份完美，而在于把「到时候再说」變成一份寫好的操作清單。真出事的时候，人往往是慌的，有清單和没清單差別很大。
备份任務本身也要照顾站点
導出大表、压缩大量附件都會占用磁盘和 CPU。如果服務器配置一般，可以把备份時間安排在訪問低谷，避開蜘蛛抓取較集中的时段，避免因為响應變慢影响正常訪問。备份失敗的告警也要有人收，任務静默失敗几個月，和没设任務区別不大。
备份的意义不在于硬盘上多了一個文件，而在于需要它的那天，你能在可接受的時間内把站点恢复起来。
建议把「检查备份是否成功」和「做一次恢复演练」寫進日常维護清單，各自定一個周期。它們是那種做的时候看不出收益、不做的时候代價很高的活。