多數 WordPress 站長其實只有一份備份，而且就放在跟網站同一台主機上。這不是備份策略，是多了幾個步驟的單點故障。主機被勒索軟體加密、主機商帳號被停權、機房失火，那份「備份」會跟正式站一起消失。WordPress 異地備份策略要解決的，正是這個盲點：把資料的命脈，留在你正式站碰不到的地方。

這篇文章會把業界行之有年的 3-2-1 備份原則，拆成台灣站長真的做得到的三份具體配置——雲端、本地、離線——並一路講到還原演練、不可竄改的離線份，以及 WooCommerce 訂單這類高變動資料該怎麼抓備份頻率。讀完你會知道每一份備份各自擋哪種災難，而不是憑感覺裝個外掛就以為安全了。

為什麼同主機的備份不算真備份

備份的價值，取決於它跟正式站「不共命運」的程度。同主機備份最大的問題，是它跟你的網站共用同一組風險：同一塊硬碟、同一個主機帳號、同一間機房。任何一個出事，正式站與備份會一起出事。

WordPress 站常見的幾種災難，剛好都能一次端掉同主機備份：

• 勒索軟體：攻擊者拿到後台或 FTP 權限後，現在的手法會主動搜尋並加密 wp-content 與備份目錄，連同主機上的備份檔一起鎖死。
• 主機帳號被停權或主機商收攤：欠費、違規誤判、或主機商結束營業，整個帳號連同裡面的備份一夕消失，你連登入下載的機會都沒有。
• 硬碟損壞與機房事故：實體硬碟會壞，機房也會遇到停電、淹水、火災。備份跟正式站在同一塊磁碟上，等於沒有備份。
• 人為誤刪：管理者手滑刪錯資料夾、外掛更新把資料庫寫壞，這類錯誤同步影響站上所有檔案。

主機商提供的每日快照（snapshot）有用，但它不是異地備份。快照通常存在同一個主機環境、受同一個帳號控制，主機商那端出事或你的帳號被鎖，快照一樣拿不到。把快照當成快速回滾的工具沒問題，把它當成唯一的保命份就太冒險。

3-2-1 備份原則到底在講什麼

3-2-1 原則是一句話就能記住的資料保護框架：保留三份資料、存在兩種不同的儲存媒介、其中至少一份放在異地。它由資料管理專家 Peter Krogh 提出並推廣，幾乎是所有備份方案的共同底層邏輯。

拆開來看，每個數字各自擋掉一類風險：

• 3 份資料：正式站本身算一份，再加上兩份獨立備份。一份壞了還有另一份，避免「唯一備份剛好也損毀」的窘境。
• 2 種媒介：不要把兩份備份都放同一種儲存方式。本地硬碟與雲端物件儲存是最常見的搭配，一種媒介整批失效時，另一種還在。
• 1 份異地：至少一份要離開你的主機環境，放到地理上、帳號上都獨立的位置，專門對付機房等級的實體災難與主機商風險。

近兩年業界把這條規則升級成 3-2-1-1-0，多補兩個要求：多一份「不可竄改」的備份（即使攻擊者拿到你的完整管理權限也刪不掉），以及還原驗證時要「零錯誤」。這兩項是針對勒索軟體普及與「備份從沒測過」這兩個現實痛點而生的，後面會分別展開。

雲端、本地、離線：三份備份各自的角色

把抽象的 3-2-1 落到 WordPress 上，最實用的配置就是三份性質不同的備份，正好對應標題講的雲端、本地、離線。它們不是同一件事做三次，而是各擋一種災難。

雲端份是擋主機商風險的核心

雲端備份是異地份最容易落地的選擇，它把資料送到跟你主機完全不同的基礎設施上。常見的目的地包括 Google Drive、Dropbox、OneDrive，以及物件儲存等級的 Amazon S3、Backblaze B2、Cloudflare R2。

對台灣站長而言，Google Drive 帳號最沒有門檻，個人或小型部落格用免費或低價方案就夠。流量大、檔案多的站，物件儲存（S3、B2）在成本與版本管理上更划算，而且天生就是異地、耐久度高。雲端份的重點在於：它存活於你的主機帳號之外，主機商停權或收攤都動不到它。

本地份是換取還原速度的快取

本地份指的是放在雲端以外、你自己掌握的儲存裝置，例如辦公室的外接硬碟、家用 NAS（Synology、QNAP 在台灣很普及），或下載到自己電腦的備份檔。它的價值不是異地性，而是還原速度與媒介多樣性。

雲端要還原時得整包下載，檔案大、頻寬有限時會拖很久；本地份在手邊，遇到小規模事故能快速回滾。NAS 還能設定排程自動收備份，比手動下載可靠。本地份滿足的是 3-2-1 裡「第二種媒介」這個位置。

離線不可竄改份是對抗勒索軟體的最後底線

離線份是 3-2-1-1-0 多出來的那一份，目的是擋住「連備份一起被加密或刪除」的勒索攻擊。它有兩種做法：

• 真離線（air-gap）：把備份寫進一顆外接硬碟後，實體拔掉、收進抽屜或保險箱，網路碰不到它，自然也加密不到它。
• 不可竄改雲端（WORM）：用支援「寫入後不可修改」的物件儲存，最具代表性的是 Amazon S3 的 Object Lock。在設定的保留期內，連帳號擁有者本人都無法刪除或覆寫那個檔案，攻擊者就算拿到你的完整 AWS 金鑰也刪不掉。

這份的精神是「write once, read many」——寫一次、讀很多次、誰都改不了。一般網站不一定每天都需要它，但只要站上有不能重建的資料（顧客個資、訂單、長年累積的內容），多這一份就是面對勒索軟體時的保命符。

不同類型的網站該多久備份一次

備份頻率沒有萬用答案，原則只有一條：頻率要對齊你的內容變動速度，並反映你能承受多少資料遺失。這裡會用到兩個復原規劃常用的指標。

RPO（Recovery Point Objective，復原點目標）指的是「你最多能接受丟掉多久的資料」。如果每天備份一次，最糟情況就是丟掉接近一整天的異動，RPO 約等於 24 小時。RTO（Recovery Time Objective，復原時間目標）則是「從災難發生到網站恢復，能容忍多久」。電商站常見的合理基準是 RPO 不超過 24 小時、RTO 控制在 4 小時內。

依站型對齊頻率，可以參考下面的節奏：

WooCommerce 這類有金流與訂單的站要特別注意：訂單資料是事後幾乎無法重建的，客人下了單、付了款，資料若遺失你連對帳都做不到。所以電商站的 RPO 應該抓得比內容站更嚴，最好對資料庫做更高頻率的備份，並把 WooCommerce 的訂單表納入備份範圍確認清單。內容更新少但訂單多的站，可以把「全站檔案」與「資料庫」拆成兩種頻率：檔案每週，資料庫每日。

保留份數（retention）也要一起規劃。高變動站建議保留近 14 到 30 份每日備份，再把較舊的版本稀釋成每週、每月份；低變動站留少一點即可。重點是要留得夠回滾到「問題發生之前」——很多災難（例如外掛被植入後門）是過幾天才被發現的，只留最新一份根本回不去乾淨的狀態。

一份完整的 WordPress 備份要包含什麼

備份不完整，還原時才發現缺東西，是最常見也最痛的坑。一份能真正重建網站的完整備份，必須同時涵蓋檔案、資料庫與設定三大塊：

• 網站檔案：wp-content 底下的佈景主題、外掛、以及 uploads 裡所有上傳的圖片與媒體。
• 資料庫：MySQL 資料庫裡的文章、頁面、使用者、留言，電商站還包含訂單與商品資料。
• 設定檔：wp-config.php 與 .htaccess 這類核心設定，決定網站連得上資料庫、跑得起來。

要特別澄清一個常見誤會：WordPress 後台「工具」裡的「匯出」功能，只會輸出一份 XML 內容檔，裡面只有文章與頁面，不含佈景主題、外掛、上傳的媒體與設定。拿這份 XML 當唯一備份，真要還原時會發現整個版型與功能都不見了。它適合搬內容，不能當備份策略的主力。

反過來，備份時可以排除快取資料夾、暫存檔與錯誤紀錄檔，這些東西重建後會自動產生，納進備份只是讓檔案變大、拖慢備份速度。另外建議單獨留一份「設定檔加資料庫」的精簡備份，事故發生時能拿它先做快速急救分流。

沒測過的備份，跟沒有備份一樣

這是整套策略裡最容易被跳過、卻最關鍵的一環，也就是 3-2-1-1-0 裡那個「0」：還原驗證要零錯誤。一份從沒成功還原過的備份，你不能信任它——備份檔可能在傳輸中損毀、可能漏了某張資料表、可能跟現在的 PHP 版本不相容，這些問題只有真的還原一次才會現形。

正確做法是把還原當成消防演練，定期、排程、反覆練習，而不是等真的失火才第一次操作。具體流程如下：

• 在測試環境還原，不要動正式站：用主機商提供的 staging 環境，或把備份檔匯入本機（Local、DevKinsta 之類的本機開發環境），開一個跟正式站隔離的副本來測。
• 逐項檢查還原結果：首頁與重要落地頁能不能正常開啟、後台登得進去、表單與結帳流程能不能跑、文章與媒體有沒有缺。電商站務必確認訂單、商品、使用者帳號都在。
• 比對檔案與資料筆數：把 uploads 與佈景主題資料夾的檔案數量跟正式站對一遍，確認媒體沒有掉；資料庫則抽查最新幾篇文章與使用者數。
• 記錄還原花了多久：這個時間就是你真實的 RTO。知道還原一次要兩小時，你才排得出合理的維護窗口，而不是災難當下才在抓瞎。

演練頻率建議跟著變動走：每次重大更新後測一次，平時至少每月或每季排一次定期演練。練得夠多，真正出事時還原會變成肌肉記憶，而不是邊查文件邊冒冷汗。

把三份備份串成一套你真的會維護的流程

異地備份策略要發揮作用，靠的不是一次性的設定，而是能長期跑下去的自動化加監控。多數備份外掛都支援排程，把它設定成在離峰時段自動執行，並同時送往多個儲存目的地，就能把 3-2-1 的三份在背景自動補齊。記得錯開外掛排程與主機快照的時間，避免它們同時搶伺服器資源導致備份失敗。

光自動跑還不夠，你得知道它有沒有跑成功。打開備份失敗通知與每日（或每週）摘要信，一旦某次備份連不上雲端、或檔案過大逾時，你能第一時間發現並處理。定期翻一下備份紀錄，留意被跳過的資料表、權限錯誤或上傳失敗，這些訊號往往是還原失敗的前兆。

成本與安全也要一起顧。雲端儲存會隨份數累積費用，靠 retention 政策把舊版本稀釋掉就能控制；連接雲端的金鑰與權限要採最小權限原則，別給備份帳號超出所需的存取範圍。資料若涉及顧客個資，台灣站還要把個資保護的責任放進考量，靜態儲存的備份盡量選有加密的服務。

回到最初那個盲點：很多人以為裝了備份外掛就安全了，但真正能在災難當下救你的，是那份你碰不到的雲端份、那份還原很快的本地份、那份誰都刪不掉的離線份，再加上一次次練到順手的還原演練。今天就把這三份配置補齊、排好自動排程，並挑一天做第一次還原演練——別等到網站真的倒下，才發現手上那份備份打不開。