小團隊可執行的 WordPress 災難復原 Runbook 範本（可直接填空使用）

網站出事時，你最缺的不是技術，而是「下一步要做什麼」的清單。因為壓力一來，平常很熟的流程也會失手。對於 1 到 5 人小團隊來說，一份 disaster recovery plan 是確保 business continuity 的關鍵。

這份 WordPress disaster recovery runbook 是給 1 到 5 人小團隊用的。你可以把它存到雲端，也建議印一份放抽屜。內容以「能在現場照做」為主，包含填空表格、通報模板、常見災難處理步驟，以及事後加固。

一頁式快速啟動清單（先保命，再修復）

先把節奏穩住，像火場逃生一樣，先做到「可控」。下面這張清單針對 incident response 的初始階段，目標是 minimizing downtime，在 10 到 30 分鐘內完成第一輪應對。

先停寫入再恢復。別急著「修好」，先避免把壞狀態寫進備份。

先把資訊填好（沒有這些就會卡關）

災難復原常見的死因是「找不到人、進不去、找不到備份」。先把下面表格填完，這些表格構成了一個 inventory of critical components，才能在關鍵時刻省下 30 分鐘以上。

聯絡人清單（含分工與替補）

存取與憑證檢查表（不放密碼，只放位置）

系統盤點（你到底在跑什麼）

備份位置與保留（要能「拿得出來」）

想對照官方建議時，可看 WordPress 官方備份說明；若你需要外掛型備份，也能先熟悉 BackWPup 外掛頁面 的還原方式。為了確保備份可靠，務必採用 offsite storage 和 cloud storage 來管理 automated backups。

RTO/RPO 目標（決定你要多快、要丟多少資料）

事件紀錄與對外更新（讓團隊不亂）

很多事故會「修好又復發」，原因是沒記錄。在 incident response 期間，標準化的 communication protocols 對於保持利害關係人知情至關重要。你只要維持兩件事，時間線與決策理由。

事件紀錄表（Incident Log）

狀態更新模板（可貼到公告、Email、Slack）

共通決策與驗證流程（每次都照這條路走）

不管是主機掛了，還是被駭，流程先走同一條。這能降低誤判，也能讓新手跟得上。

1. 確認是否還在擴大：關閉自動部署、暫停排程、必要時啟用維護模式。可用 wp maintenance-mode activate，或先用主機層擋寫入。
2. 先留證據：進行手動備份目前狀態以確保資料完整性，抓錯誤頁截圖，保存 wp-content/debug.log，下載目前資料庫一份。用 WP-CLI 可先做 wp db export。
3. 做決策點：
   你要「修復現況」還是「回復到備份」？若影響資料一致性（訂單、會員），通常先回復。
4. 執行恢復：以「先資料庫，再檔案」為原則，避免版本不一致。
5. 驗證健康狀態：
   先看首頁，再看登入，再看結帳或表單。接著檢查 404、站內搜尋、寄信、後台是否能更新外掛。這些步驟是標準備份與還原工作流程的一部分，需要備份與還原觀念補強時，可參考 備份與還原入門文章 做一次演練。
6. 解除管制：確認無異常後再關維護模式，wp maintenance-mode deactivate。

常見災難情境處理程序（可直接照做）

主機中斷或大量 5xx（疑似主機故障）

1. 先用外部監控或手機網路重試，排除本地 DNS 快取。
2. 登入主機控制台，確認資源用量與事件公告。
3. 若是快取或 PHP 當機，先重啟服務（依主機提供功能）。
4. 若本地修復失敗且疑似 server failure，考慮啟動 failover process 到不同環境；仍無法恢復時，決定回復到最近快照或備份。
5. 恢復後清快取，並驗證關鍵頁面與登入流程。

誤刪文章、媒體或整個 wp-content

1. 先停止內容編輯，避免覆寫。
2. 若只是文章，優先檢查回收桶與修訂版。
3. 檔案遺失時，從備份取回 wp-content/uploads，不要整包覆蓋外掛與主題。
4. 若需要改網址或網域，修復後再做 wp search-replace '舊網域' '新網域' --skip-columns=guid。

更新失敗、白畫面、卡在維護模式

1. 先確認是否卡維護模式，移除 .maintenance 或直接跑 wp maintenance-mode deactivate。
2. 立刻停用所有 WordPress plugins 測試，wp plugin deactivate --all。
3. 若恢復，逐一啟用外掛找出兇手。
4. 需要切回預設主題時可用 wp theme activate twentytwentyfive。
5. 之後把更新搬到測試站跑一次，並規劃正式站同步流程，可參考 同步測試站與正式站指南 建立固定做法。

資料庫毀損或連線錯誤

1. 先確認 wp-config.php 的 MySQL database 設定是否被改動。
2. 匯出現況資料庫留存，wp db export。
3. 從最近可用備份匯入，wp db import 〔填寫：備份檔名.sql〕。
4. 跑 WordPress core 資料庫升級，wp core update-db。
5. 驗證登入、文章列表、外掛設定是否一致。

勒索軟體或被駭（跳轉、植入、異常管理員）

1. 立刻下線或維護模式，保護訪客與資料。
2. 先改所有入口密碼，強制重設管理員帳號與 2FA。
3. 檢查是否新增管理員，wp user list，必要時 wp user delete 〔填寫：ID〕 --reassign=〔填寫：ID〕。
4. 回復到「確認乾淨」的備份點，避免 data loss，不要用剛發生後的備份。
5. 更換所有金鑰與密碼（DB、SFTP、API），再做全站掃描與檔案比對。

如果你無法確定備份是否乾淨，先把站台隔離，別急著上線。

事後收尾與加固（把今天的痛變成制度）

復原完成不代表結束。你要把事故變成固定的 recovery protocol，下一次才會更快。

先做一次 30 分鐘回顧會，填三句就好：根因是什麼，為什麼沒提早發現，下次要改哪個控制點。接著把 runbook 更新，包含備份頻率、RTO/RPO、以及「誰有權限」。最後，安排每季演練一次，至少做一輪還原到測試站。這是對 backup strategy 和 security measures 的 regular testing，唯一確保計劃有效的方式。

如果你希望把監控、更新、備份驗證變成例行工作，可以把維運項目制度化，參考 WordPress 維護全攻略 的做法；追求 geographic redundancy 或 multi-region strategy 的團隊，則可考慮更進階工具，讓小團隊不用每天提心吊膽。

結語

災難不會先約時間，但你可以先把一份完善的 disaster recovery plan 寫好。把這份模板填完，並做一次演練，你的 WordPress disaster recovery 就不再靠運氣。下一次出事時，你只需要照表操課，穩穩把網站拉回來。想把備份驗證、監控與更新交給固定流程，將這些步驟融入你的日常例行，現在就把這份 runbook 存檔，並排進你本週的待辦。