五月前的 WordPress 備份總檢查，先確認還原真的可用

真正讓網站停擺的，常不是駭客，而是你以為早就備好了。WordPress 備份檔存在，不代表能還原；排程有開，也不代表昨晚真的跑完。

五月前通常是活動上線、內容更新與人力排班交錯的時段。這時先把備份流程補強，你才不會在網站出錯後，才發現手上的只是無法使用的壓縮檔。

先查目前備份設定，別只看 “已啟用”

很多站長只確認外掛還在，卻沒看最後一次成功時間。真正要查的，是昨天有沒有完成、檔案有沒有完整、通知有沒有送達。若你也在做假期前維護，可以順手對照這份 WordPress 安全檢查清單，把更新、權限與備份一起處理。

先看四件事。第一，確認最後一次成功備份的時間，而不是只看排程頻率。第二，確認備份範圍，至少要含資料庫、上傳檔、外掛、佈景主題，以及關鍵設定檔。第三，確認保留天數與份數，建議至少留 30 天，避免壞檔覆蓋好檔。第四，確認通知機制，失敗時要寄到管理信箱，最好再寄給第二位同事或共用信箱。

接著看日誌內容。若出現 skipped files、timeout、disk full 或 remote upload failed，這次就不能算成功。很多人看到外掛顯示綠燈就放心，但實際上遠端上傳可能已經中斷。你也要順手比對備份檔大小。今天的檔案若突然小很多，通常不是網站變瘦，而是某些資料沒被打包進去。

2026 年仍適用的做法很直接。內容常更新的網站，資料庫至少每日備份；檔案每週完整備份，平日再做增量備份。若你是電商、會員站或常收表單的企業官網，資料變動更快，資料庫頻率要再拉高。

備份不等於安全，還原測試才是驗收

備份檔能成功還原，才算真正完成一次備份。

不少人做到 “下載成功” 就停了，但真正的風險在還原那一刻才會浮出來。資料庫版本不合、壓縮檔損壞、外掛相依出錯，都會讓你在最需要恢復時卡住。若你想把流程固定下來，可以參考這份 WordPress 備份 SOP，把交接成本一起降下來。

還原測試不用每次都做很大，但每月至少要抽測一次。先在測試站或 staging 環境還原，不要直接碰正式站。接著登入後台，確認管理員可登入、文章或商品資料完整、首頁與主要頁面正常。然後測一次表單寄信、會員登入或結帳流程。最後打開錯誤日誌，確認沒有 PHP 錯誤、權限異常或媒體路徑失效。

判斷標準要寫清楚。若缺近期訂單、圖片載不出來、固定網址錯亂，這次還原就算失敗。首頁正常不代表網站可用，因為出問題的常是你最在意的資料區塊。

工具怎麼選，重點不是名氣，而是還原是否順手、遠端儲存是否穩、日誌是否清楚。像 UpdraftPlus 適合需要排程與雲端備份的大多數網站；XCloner 比較適合要接 SFTP 或多個異地目標的情境。選哪一套都可以，但一定要真的跑過一次還原。

五月前的最後檢查表

異地存放是最後一道保命線。若備份和網站都放同一台主機，主機故障、帳號被入侵或硬碟損毀時，兩邊會一起出事。所以至少照 3-2-1 原則做，保留 3 份副本、放在 2 種位置，其中 1 份在站外。

排程檢查也不能省。低流量企業站常只靠 WP-Cron，結果因為沒人造訪而延後執行。若你的備份常錯過時間，改用主機 cron 會穩很多。再來，通知別只開失敗通知，成功通知也要開。因為收不到成功信時，你就能提早發現寄信、授權或遠端同步出了問題。若你用 Google Drive 或 S3，還要檢查授權是否過期、空間是否足夠。

2026 年還有一個老問題沒消失，就是主機環境太舊。仍停在 PHP 7.4 的網站，常在大型備份時逾時或白屏。五月前如果要做總檢查，這一項別跳過。

最後檢查表

先用這張表做收尾，5 分鐘就能看出大部分風險。

只要有一格不合格，這套備份流程就還沒過關。

常見錯誤

最常見的錯誤，是只備資料庫，不備上傳檔。結果文章還在，圖片全失。另一種情況也很多，所有備份都留在主機內，出事時一份都拿不到。還有人以為外掛顯示成功就沒事，卻從來不看通知，連續失敗一週也不知道。

另外，別把還原測試拖到事故發生那天。那時你會同時面對客訴、訂單、主管追問，判斷會失準。先在平常把流程跑通，出事時才救得回來。

結語

五月前把備份流程補齊，價值不在多裝一個外掛，而在少一次停機。還原測試、異地存放、排程檢查、通知機制，少一項都可能讓備份失去作用。

把這篇當成每月例行表就夠了。下次更新外掛、改版頁面或開活動前，先檢查一遍，你的網站會穩很多。