WordPress 備份怎麼做才真的救得回來？外掛、主機端與異地備份的三層策略

去年有位讀者寄信給我，說他的主機商帳號因為信用卡過期、扣款失敗兩次被暫停，後台進不去，網站顯示 403。他很鎮定，因為他「有備份」——備份就存在那台主機的 wp-content/backups 裡面。那一刻他才意識到，他的 WordPress 備份跟他要救的東西放在同一個地方，一起被鎖在門後面。

這不是特例。我接觸過的自架站站長裡，絕大多數都裝了備份外掛、看得到「上次備份成功」的綠色勾勾，卻從來沒有把那包檔案還原到任何地方過一次。備份是一種你不驗證就無法知道有沒有效的東西，而驗證的方法只有一個：真的還原一次。

先訂驗收標準：能不能還原到「別台主機」

談備份之前要先把成功條件寫下來，否則所有討論都會滑向「我裝了什麼外掛」。我用的標準只有一句：假設你現在的主機整台不可用——不是慢、不是 500 錯誤，而是你連後台和 FTP 都進不去——你能不能只靠手上現成的檔案，在另一個環境把站重新跑起來。

這個標準之所以嚴格，是因為它一次同時檢驗四件事：檔案的完整性、檔案的可攜性、你有沒有還原所需的憑證、以及你知不知道步驟。大多數「有備份卻救不回來」的案例，壞在後面三項，而不是第一項。

拿它去檢驗常見做法，結果會很清楚。主機商後台的「一鍵還原」在主機商本身正常時很好用，但它通常只能還原回同一家的同一台機器；你沒辦法把那個快照帶到別家去。能還原回原地，跟能還原到別處，是兩種完全不同等級的保障。

同樣的檢驗也適用於雲端硬碟裡那包 zip。檔案在，但你記不記得資料庫密碼設在哪、網域 DNS 在哪家管理、SSL 憑證怎麼重新簽發？還原是一個流程，不是一個檔案，缺任何一步都會卡在半路。

我自己維護站台的做法是把這個標準寫成一句話貼在備忘錄裡：能不能在兩小時內，用一台乾淨的電腦，把站還原到本機看得到首頁。把抽象的「安全感」換成一個可以計時的動作，是備份策略從空話變成工程的分界點。

如果你正在從零開始建站，這個標準應該在挑主機的階段就一併考慮，而不是上線之後才補。我在自架站新手的六個決策裡把主機與後續維護放在同一組決策，原因就是這兩件事在實務上分不開。選主機時要問的不只是速度和價格，而是「我能不能自由把資料拿走」。

一個 WordPress 站由哪幾塊組成，漏掉哪塊會怎樣

要判斷一包備份夠不夠，得先知道要備的東西有幾塊。WordPress 官方的備份文件把它拆成兩大部分：資料庫與檔案，並且特別註明一般情況下「下載網站目錄不等於備份了資料庫」，因為資料庫存在另一套系統（通常是 MySQL 或 MariaDB）裡（見 WordPress Advanced Administration：Backups）。這是新手最常誤解的一點：把整個 FTP 目錄抓下來，並沒有備份到你寫的任何一篇文章。

實務上我會再往下拆成四塊，因為這四塊的變動頻率、可取代性、遺失後果都不一樣。把它們當成一塊處理，會導致你在「每天備份一次幾 GB 的圖片」和「一週才備份一次會掉三十篇文章」之間做出錯誤妥協。

第一塊：資料庫

資料庫裝的是所有你寫過與設定過的東西：文章、頁面、留言、使用者帳號、分類與標籤、選單、外掛設定值、佈景主題的自訂選項。頁面編輯器產生的版面結構通常也存在文章內容或 postmeta 欄位裡，用 Elementor 之類的視覺編輯器做的頁面也不例外。資料庫遺失等於內容全滅，而且是唯一沒有任何辦法重新下載或重做的一塊。

備份資料庫的產物是一個匯出檔（.sql、.sql.gz 之類），官方文件也是這樣描述：那個匯出檔本身是一個檔案，可以跟檔案備份放在一起，但還原時必須匯入回資料庫系統（見 Backing Up Your Database）。「有 .sql 檔」跟「資料庫已還原」中間還隔著一個匯入步驟，而那一步是最常失敗的。

第二塊：wp-content/uploads 上傳檔

所有你上傳過的圖片、PDF、影音都存在這裡，而且 WordPress 會為每張圖產生多種尺寸的縮圖。資料庫裡存的只是路徑字串，不是圖片本身。只備份資料庫、不備份 uploads，還原後的結果是文章都在、每張圖都是破圖，這是我見過最多的半殘還原。

這一塊的特性是「只增不改」：舊圖幾乎不會變動，新圖持續累積。因此它適合用低頻率的完整備份加上高頻率的增量備份，不需要每天重打包一次全部歷史圖片。

第三塊：外掛與佈景主題目錄

WordPress 核心和公開外掛都能重新下載，所以這塊的可取代性比較高——但有三種東西下載不回來：付費主題與付費外掛的安裝檔與授權、子主題裡的自訂 CSS 與 functions.php、以及你手動改過的任何檔案。只要你動手改過一行程式碼，這一塊就變成不可取代。

官方的檔案備份說明把核心、外掛、主題、圖片與其他程式檔一起列為需要保存的範圍（見 Backing Up Your WordPress Files）。如果你用的是付費主題，記得把主題的原始安裝壓縮檔另外存一份，不要只依賴站上已解壓的版本。選主題時的長期維護成本，我在WordPress 佈景主題怎麼選裡有更完整的討論。

第四塊：wp-config.php 與 .htaccess

wp-config.php 裡有資料庫連線資訊、安全金鑰與鹽值、資料表前綴 $table_prefix，以及各種常數設定（見 Editing wp-config.php）。資料表前綴不一致，是還原後看到「安裝新網站」畫面的頭號原因，而很多人會在那一刻誤以為資料庫沒匯入成功。

.htaccess（Apache 環境）裝的是重寫規則，WordPress 靠它處理漂亮的固定連結；官方文件也直接提供標準內容供你在檔案損壞時還原（見 Apache HTTPD / .htaccess）。漏掉這個檔案的典型症狀是首頁正常、所有內頁 404，以及你自己設過的重導全部失效。

還有一些不在這四塊裡的東西

有些資產根本不在 WordPress 裡面，備份外掛再完整也帶不走：網域註冊商的登入、DNS 設定、CDN 或防火牆的規則、電子報名單。訂閱名單通常存在第三方平台，這其實是好事——它天然就是異地備份，但你要確定自己有辦法匯出。我在Email 行銷工具比較裡把「名單匯出是否自由」列為選工具的判準之一，理由就是這個。

三層備份策略：外掛層、主機商快照、異地保存

把上面那些組成拼起來之後，我採用的是三層結構。三層不是為了多，而是為了讓任何單一事件不會同時打掉全部。設計備份的關鍵詞是「故障域」：兩份備份如果會因為同一件事一起消失，那它們實質上只算一份。

第一層：站內外掛層自動備份

這一層跑在 WordPress 內部，好處是粒度細、可以自助操作、產出的檔案可攜。你可以只還原資料庫、只還原某個資料夾，也可以把檔案直接搬到別家主機。外掛層是三層裡唯一能讓你「換供應商」的一層，這也是它不能省的原因。

它的代價是：整個過程靠 PHP 執行，受主機的執行時間與記憶體限制，站越大越容易在打包途中被切斷。外掛層備份最危險的失敗模式不是「沒跑」，而是「跑一半留下一包看起來正常的殘檔」。

第二層：主機商快照或自動備份

這一層的優點是快、涵蓋整台機器、不吃 PHP 資源，而且通常包含資料庫。遇到「更新外掛把站弄壞」這種常見事故，主機商快照往往是最快的解法。當事故的原因在站內、而主機商一切正常時，快照是效率最高的一層。

問題在於它跟你的帳號共用同一個故障域。帳號因為付款失敗被停用、爭議中被限制、供應商本身結束服務或發生大規模事故時，快照跟站是一起消失的。主機商快照如果是你唯一的備份，那你其實是把全部風險押在「這家公司與這個帳號都不會出事」這一個假設上。

另一個較少被提到的限制是格式封閉：快照通常只能透過該供應商的介面還原回它自己的環境，你拿不到一包可以帶去別家的檔案。能不能匯出成標準檔案，是判斷這一層是否構成真備份的分界。WordPress 官方文件也提醒，多數主機會備份整台伺服器，但向主機商索取副本需要時間，而災難發生時速度很關鍵，所以你仍應學會自己備份與還原（見 官方備份說明）。

第三層：異地保存（不同供應商）

第三層是把備份檔放到跟主機無關的地方：物件儲存、雲端硬碟、或你自己的外接硬碟。美國 CISA 收錄的 US-CERT《Data Backup Options》把可提升復原機率的原則寫得很直白——保留原始檔與備份的多份副本、放在不同的媒體類型上以抵禦不同類型的災害、並且把一份存放在異地（例如家裡或營業場所之外）（見 CISA／US-CERT：Data Backup Options）。異地不是「另一個資料夾」，而是「另一個會不會一起出事的實體與帳號」。

WordPress 官方文件在建議保留份數時也採同樣邏輯：建議保留至少 3 到 5 份近期備份，並且把副本存在不同位置，例如一份在主機、一份在雲端儲存、一份下載到自己的電腦（見 官方備份說明）。這個「3 到 5 份、分散位置」是我唯一願意直接照抄的官方數字，因為它同時處理了份數與位置兩個變數。

我自己的實作是：外掛層每天把資料庫丟到外部儲存、每週丟一次完整檔案；主機商快照維持開啟不動；每個月手動下載一份到本機外接硬碟並且拔線離線保存。離線那一份的意義是抵禦加密勒贖與帳號被接管——連線的備份會被一起加密，拔掉線的不會。

這個思路跟我處理網路斷線的邏輯是一樣的：備援方案的價值不在於平常有多順，而在於主線完全失效時它是否獨立可用。我在遠距工作斷網備援方案裡拆過同一個結構。把「備援必須跨供應商」這件事想通一次，之後所有備援設計都能套用。

備份頻率怎麼定：用「能接受重做多少」反推

很多人問備份多久一次才夠，這個問題沒有通用答案，但有通用推導方式。災難復原領域用兩個指標描述目標：RTO 是從服務中斷到恢復之間可接受的最大延遲，RPO 是距離上一個可復原時間點的可接受最大時間量，也就是可接受的資料遺失範圍（定義見 AWS Well-Architected：Disaster recovery objectives）。用白話講，RPO 就是「站掛掉時，你願意重做多少內容」。

推導方式很簡單：先誠實回答「如果現在整站回到上一次備份，我要重做多少工」，那個數字如果讓你不能接受，備份間隔就太長了。不要問「每天備份會不會太頻繁」，要問「掉一天的內容我補不補得回來」。

WordPress 官方文件對頻率的建議也是這個邏輯：內容較少的小型網站建議每週備份一次，高活動、發文量大的網站建議每天備份，並且在升級前一定要備份（見 官方備份說明）。「升級前必備份」是頻率之外的第二條規則，因為升級是自己主動引入風險的時刻。

下面是我實際用的分類方式，表格裡的頻率都是我自己的取捨舉例，不是行業標準。請照你的內容產出速度調整。

會員與訂單這一類要特別提高頻率，理由不是資料比較重要，而是它「不是你產生的」。你自己寫的文章重做很痛但做得到；使用者送出的訂單與留言一旦遺失，你連內容都不知道。

頻率之外還有一個常被忽略的變數：保留期。如果你只保留最新一份，那麼被入侵、資料庫被緩慢破壞、或某個外掛悄悄寫壞資料的情況下，你發現問題時所有備份都已經是壞的版本。保留期必須長於你發現問題所需的時間，這是「只留一份」最致命的地方。

我的做法是保留階梯式的代數：最近七天每天一份、最近一到兩個月每週一份、再往前每月一份。這個階梯的用意是讓你在「昨天壞的」和「一個月前就壞的」兩種情境都有可用版本，而不會讓儲存空間無限膨脹。

還原演練：一次完整的實作步驟

這一節是全文最該花時間的部分。我建議的演練頻率是至少每季一次，另外在換主機、升 PHP 版本、換佈景主題或大幅改版之後補做一次。演練的目的不是證明備份是好的，而是提早發現它是壞的——所以你要用最不利的假設去做。

最不利的假設有兩條：第一，原主機完全不可用，你不能從它身上拿任何東西；第二，你只能用異地那份備份。如果演練過程中你伸手去原主機抓了任何檔案，這次演練就不算通過。

演練前的準備

找一個跟正式站無關的環境。本機工具（例如 Local）最乾淨，因為完全不涉及線上環境；如果你想順便驗證主機相容性，可以在另一家主機開最便宜的方案或用子網域。不要在正式站上演練，也不要用「還原到正式站看看」這種方式驗證，那是把演練變成事故。

如果你選擇線上環境演練，先確認它不會被搜尋引擎索引。子網域演練站被索引會產生重複內容，還可能在搜尋結果裡跟正式站互相稀釋，所以要先加上密碼保護或設為不索引。驗證索引狀態的方法，我在Google Search Console 新手完整教學裡寫過。

完整步驟

1. 只從異地備份取檔。登入你的雲端儲存或接上外接硬碟，把最新一份完整備份下載到本機。這一步就會抓出很多問題：找不到帳號、分享連結過期、檔案只有一半、或是你發現「最新一份」其實是三個月前的。
2. 先驗檔案完整性，再開始還原。把壓縮檔解開，確認裡面同時有資料庫匯出檔（.sql 或壓縮過的版本）以及 wp-content 目錄。用檔案數量與總容量跟正式站比對，不要只確認資料夾存在。uploads 只有幾十個檔案而正式站有幾千個，代表打包被切斷了。
3. 建立空的資料庫與資料庫使用者。記下資料庫名稱、使用者、密碼、主機位址四個值。演練時你會親身體會到，這四個值如果沒有事先保存，你根本無從開始。
4. 把檔案放到網站根目錄。確認 wp-config.php、.htaccess（若為 Apache）與 wp-content 都在正確位置。隱藏檔容易在解壓或 FTP 傳輸時被跳過，特別要確認 .htaccess 真的在。
5. 匯入資料庫。小型資料庫可以用 phpMyAdmin 的匯入功能（phpMyAdmin 匯入／匯出說明）；檔案偏大時改用命令列會穩定得多，WP-CLI 的 wp db import 就是為此設計的，對應的匯出指令是 wp db export。
6. 修正 wp-config.php 的連線資訊與資料表前綴。把 DB_NAME、DB_USER、DB_PASSWORD、DB_HOST 改成新環境的值，然後打開資料庫看實際的資料表名稱開頭，確認 $table_prefix 完全一致（wp-config.php 設定說明）。前綴不符時 WordPress 會以為這是全新安裝，直接顯示安裝畫面。
7. 處理網址。資料庫裡存的是舊網址，演練環境的網址不同。最快的做法是在 wp-config.php 暫時定義 WP_HOME 與 WP_SITEURL 指向演練網址；要真正替換內容中的網址則用 wp search-replace。官方已經把換網址的說明併入 Migrating WordPress 這份文件，裡面的「Changing The Site URL」一節把這幾種方法與注意事項列在一起（見 Migrating WordPress：Changing The Site URL、wp search-replace）。
8. 登入後台，重刷固定連結。進到「設定 → 固定連結」，什麼都不改直接按儲存，讓 WordPress 重新寫出重寫規則。如果內頁還是 404，就對照官方提供的標準 .htaccess 內容檢查（見 Apache HTTPD / .htaccess）。
9. 檢查圖片路徑。隨機打開五篇有圖的文章，看圖有沒有出來；再進媒體庫看縮圖有沒有正常。若文章圖破但媒體庫檔案在，通常是內容裡的絕對網址還指向舊網域，回到步驟七做網址替換。
10. 逐項驗收功能。首頁、分類頁、含表單的頁面、用視覺編輯器做的版面、站內搜尋、RSS、sitemap.xml、後台外掛清單是否全部啟用、有沒有出現預期外的錯誤訊息。把這張清單固定下來，每次演練照跑。
11. 計時並記錄。從開始下載到首頁正常顯示花了多久，這就是你真實的復原時間。如果它比你能接受的停機時間長，問題不在備份頻率，而在流程與熟練度。
12. 把過程寫成一頁還原手冊，跟異地備份放在一起。內容包括：備份放在哪、需要哪些帳號、wp-config.php 要填哪些值、DNS 在哪家管理、SSL 怎麼重新簽發、以及上面這串步驟。手冊要能讓「三個月後忘光的你」照著做完。
13. 收尾。演練站關掉或刪除；若保留，維持密碼保護。還原後如果是正式環境，記得回頭確認分析追蹤碼仍在運作（參考GA4 安裝與報表教學），因為換環境常會把追蹤碼一起換掉。

如果你要驗證的是「換主機」這件事本身，官方的 Moving WordPress 文件把搬站的完整流程寫得相當細，跟還原演練高度重疊，可以當成第二份對照清單（見 Moving WordPress）。學會搬站等於學會還原，這兩件事在技術上是同一件事。

另外提一個順序上的細節：官方文件建議備份時先備資料庫再備檔案，還原時反過來——先還原檔案，再匯入資料庫，若途中換過資料庫憑證就更新 wp-config.php（見 官方備份說明）。順序本身不會決定成敗，但照著做可以少掉幾次「匯入完才發現檔案還沒上去」的來回。

七個最常見的還原失敗原因與對策

下面這些不是理論上的風險，是實際會讓你在最需要的時候救不回來的具體原因。它們的共同點是：在平時完全不會表現出任何症狀，備份紀錄還會顯示成功。

一、備份跑到一半被 PHP 執行時間切斷

PHP 官方文件列出 max_execution_time 在網頁環境的預設值是 30 秒（同一份文件也註明從命令列執行 PHP 時，這個值預設為 0，也就是不限制執行時間），而且提醒網頁伺服器本身還有另一層逾時設定——Apache 的 Timeout 指令與 IIS 的 CGI 逾時預設都是 300 秒（見 PHP：php.ini 核心設定說明）。主機商通常會調高這個值，但只要你的站大到打包時間超過限制，備份就會在中途被砍斷。

對策有三個方向：把備份檔切成較小的分割檔（多數備份外掛有這個選項）、排除不必要的目錄（快取資料夾、除錯日誌、暫存檔），以及改走命令列或主機端排程而不是靠瀏覽器觸發。判斷有沒有中斷的最快方法是比對檔案大小：這週的備份檔比上週小很多，幾乎一定是出事了。

二、資料庫太大導致匯入失敗

匯入是還原時最脆弱的一步，因為它會同時撞到 PHP 端與資料庫端的多個上限。PHP 的 post_max_size 預設值是 8M，而且它必須大於 upload_max_filesize 才能上傳大檔（見 PHP 核心設定指令）；資料庫端則有 max_allowed_packet，它限制單一封包或中間字串的最大位元組數（見 MariaDB Server System Variables；MariaDB 與 MySQL 的預設值不同，實際上限請直接查你這台資料庫的設定值，不要沿用文章裡的數字）。phpMyAdmin 的文件也直接提到，匯出時把過長的 INSERT 拆開可以避免匯入大表時出現「封包大於 max_allowed_packet」的錯誤，並且另有一節專門處理大型 dump 檔上傳的記憶體與逾時問題（見 phpMyAdmin 匯入／匯出）。

對策是不要用瀏覽器匯入大型資料庫。用 wp db import 或主機提供的命令列環境，繞過 HTTP 上傳的所有限制。若真的只能用 phpMyAdmin，就在匯出階段開啟分割設定，把 dump 切小。

三、只備份了資料庫，沒備份上傳檔

這是最常見的半殘還原，成因通常是：一開始只設了資料庫備份，後來忘了補檔案；或者為了省空間把 uploads 排除在外。症狀是文章與版面都回來了，每一張圖都是破圖，而且沒有任何自動化方法可以把圖補回去。

對策是把「檔案備份是否包含 wp-content/uploads」列進稽核清單，每個月實際解開壓縮檔看一次。看設定畫面說有勾選是不夠的，要看解出來的資料夾裡真的有幾千個檔案。

四、備份存在同一台主機

把備份檔留在 wp-content 底下有三個獨立的問題：故障域重疊（主機掛掉一起掛）、佔用磁碟配額、以及下一次備份會把上一次的備份檔也打包進去，造成雪球般膨脹。備份檔放在網站目錄裡，還會直接製造資安風險，這點在後面一節會單獨談。

對策是把外部儲存設為必要條件而非選項：備份完成後自動上傳到站外，站內只留最近一兩份供快速回滾。「站內留一份、站外留數份」比「站內留很多份」安全得多。

五、排程看起來有設，實際沒在跑

WordPress 的排程機制 WP-Cron 不是系統層級的 cron：它在每次頁面載入時檢查有哪些任務該執行，只在有頁面載入時才被觸發，所以如果你排了下午兩點的任務而那個時間沒有人造訪網站，就可能發生排程誤差（見 WordPress Plugin Handbook：WP-Cron）。低流量站最容易踩這個坑：你以為每天備份，實際上是「有人來的那天才備份」。

對策是把備份排程改掛在主機端的系統排程上，或至少每週去看一次「上次成功備份時間」。備份策略裡一定要有一個「主動檢查最後成功時間」的動作，因為失敗通常不會有人通知你。

六、有檔案，但沒有還原用的憑證

這一項在演練時最常爆掉：資料庫密碼不知道、主機後台的兩階段驗證綁在已經停用的手機號碼、網域註冊商的登入信箱是前公司的、外部儲存的帳號密碼存在那台壞掉的電腦裡。檔案是還原的必要條件，憑證是還原的另一個必要條件，缺一個都動不了。

對策是把還原所需的全部憑證列成清單放進密碼管理器，並且確認密碼管理器本身有獨立的復原方式。如果你的密碼管理器的兩階段驗證裝在同一支手機、備份也只在那支手機上，那它跟你的網站共用同一個故障域。接案者常見的帳號與資產管理疏漏，我在自由接案第一年最常踩的坑裡也提過類似的結構性問題。

七、備份都在，但全部是壞的版本

如果站被植入後門或某個外掛長期寫壞資料，而你只保留最近幾天的備份，那你發現問題時所有可用版本都已經含有問題。這種情況下真正救你的不是備份頻率，而是保留期長度。

對策是前面提到的階梯式保留，再加上一個習慣：重大更動前手動做一份、標註用途、單獨保存。「這是我確定乾淨的版本」這種帶標籤的備份，價值遠高於一堆日期相近的自動備份。

備份外掛的選擇判準（不談價格）

這一節刻意不列價格與方案額度，原因很單純：這類資訊變動頻繁，我寫下的任何數字都會很快過期，而過期的價格比沒有價格更容易誤導人。費用與空間額度請一律以官方頁面公告為準，我在這裡只給判準。

我會用五個問題篩選備份外掛，順序就是重要性順序。這五題全部是「能不能」的是非題，回答不出來就代表你還沒真的了解手上這個工具。

1. 能不能分別排程資料庫與檔案，而且頻率可以不同？資料庫需要高頻、檔案需要低頻加增量。做不到分開排程的工具，會迫使你在「浪費資源」和「資料遺失窗過長」之間選一個。
2. 能不能自動把備份送到外部空間？物件儲存、雲端硬碟、或你自己的 SFTP 都可以，關鍵是「不需要你手動搬」。需要手動的步驟遲早會被忘記。
3. 能不能單獨還原資料庫，或單獨還原某一個資料夾？實際事故很少需要全站還原。「昨天誤刪一批文章」只需要還原資料庫，「主題檔案改壞」只需要還原主題目錄。粒度不夠的工具會讓小事故變成大工程。
4. 備份檔是不是開放格式？這一題最容易被忽略。理想狀況是：即使這個外掛壞了、不再維護、或你根本無法登入 WordPress，你也能手動解開壓縮檔、拿到 .sql 檔並用命令列匯入。只能靠原廠工具還原的專有格式，會在最糟的情況下變成第二個單點故障。
5. 大站有沒有分段或命令列機制？如果你的站已經到了會撞執行時間上限的規模，工具必須支援分割檔案、續傳，或提供 WP-CLI 指令。

另外要區分兩種工具的定位：一種是「備份型」，設計目的是持續排程與版本保留；另一種是「搬站型」，設計目的是把整站打包成一個可以在新環境展開的檔案。搬站型工具通常還原體驗更順，但版本管理與排程能力較弱，所以我把它當第三層的補充，不當主力。

常見選項的官方頁面列在這裡，功能與方案細節請直接看官方說明：UpdraftPlus、BackWPup、Duplicator、All-in-One WP Migration。想在正式站旁邊開一個測試環境做演練或試更新，WP Staging 這類工具也可以列入評估。我不推薦「唯一正確的外掛」，因為決定成敗的是你有沒有做外部儲存與還原演練，不是外掛的品牌。

如果你完全不想碰命令列，也可以只用外掛層加雲端硬碟起步。不完美但有在跑的方案，永遠勝過設想完整卻沒有實作的方案。至於這些選擇會怎麼影響整體維護成本，可以參考網站架設費用全解析裡的成本結構討論，本文不展開這部分。

備份檔本身就是資安風險

備份策略談到這裡還缺一塊：備份檔是你整個站最敏感的單一檔案。一份完整備份裡有資料庫，資料庫裡有所有使用者的 email、密碼雜湊、留言者的資料，以及 wp-config.php 裡的連線資訊與金鑰。

最典型的事故是把備份檔放在網站可公開存取的位置。example.com/backup.zip、example.com/wp-content/backups/ 這類路徑會被自動化掃描工具例行嘗試，如果目錄列表沒關，甚至不用猜檔名。備份檔被下載的後果比網站被改版嚴重得多，因為那是一次完整的資料外洩，而且你可能永遠不會發現。

對策依安全性排序：最好的做法是備份檔完全不留在 web 可存取的目錄，備份完成即上傳外部並刪除本地副本；次佳是放在 document root 之外的路徑；不得已留在站內時，要用伺服器層規則封鎖存取並關閉目錄列表（Apache 環境可以用 .htaccess 規則，語法與 WordPress 的用法見 官方 .htaccess 說明）。檔名加上隨機字串只能拖延掃描，不能取代真正的存取控制。

雲端儲存那一端同樣要檢查權限。很多人為了方便把備份資料夾的分享設定調成「知道連結的人都能檢視」，這在實務上等同公開。異地備份的存取權限應該只有你自己，並且開啟兩階段驗證。如果你經常在外面的網路環境操作，連線安全也要一起顧，我在咖啡廳與共享空間的公共 Wi-Fi 資安那篇整理過做法。

如果備份含有會員或客戶資料，保管義務就不只是技術問題。台灣《個人資料保護法》對持有個人資料檔案者有安全維護方面的要求，而該法近期經過修正、部分條文的施行日期另定，實際適用範圍請以全國法規資料庫的最新條文與主管機關公告為準。務實的結論是：把備份檔當成機密資料保管，而不是當成一個技術產物隨手亂放。

還有一種情境要特別處理：因為被入侵才進行還原。這時候單純還原不夠，因為攻擊者可能已經在較早的備份裡留下後門，或者建立了額外的管理員帳號。入侵後的還原必須包含更換所有密碼、重新產生 wp-config.php 裡的安全金鑰與鹽值、以及逐一檢查使用者清單。WordPress 官方的加固文件可以當成還原後的檢查依據（見 Hardening WordPress）。

一份可以照抄的備份稽核清單

策略最後要落成固定動作，否則三個月後一定回到「有裝外掛就好」的狀態。下面這份清單是我自己在用的，你可以直接抄走改成自己的頻率。清單的價值在於它把「檢查備份」從一個念頭變成一個有時間點的動作。

每週（約三分鐘）

1. 看備份紀錄的「上次成功時間」是不是在預期範圍內。
2. 比對最新備份檔的大小跟上週是否相近。突然變小代表打包被切斷，突然暴增可能是備份檔把自己也包進去了。
3. 確認外部儲存那邊真的收到新檔案，不要只看 WordPress 後台顯示成功。

每月（約二十分鐘）

1. 下載一份完整備份到本機，實際解壓縮打開。
2. 確認 .sql 檔可以開啟且結尾完整、wp-content/uploads 的檔案數與正式站接近、wp-config.php 與 .htaccess 都在。
3. 把這份備份複製到離線媒體（外接硬碟），複製完拔線。
4. 檢查一次雲端儲存的分享權限沒有被改成公開。

每季（約一到兩小時）

1. 做一次完整還原演練，全程照第五節的步驟。
2. 計時並記下復原時間，跟上一季比較。
3. 更新還原手冊：這一季有沒有換主機、換外掛、改過 wp-config.php。
4. 複查憑證清單是否仍然有效，尤其是兩階段驗證的裝置與備用碼。

事件觸發（不定期，但不能省）

1. 升級 PHP 版本、更新主要外掛或佈景主題之前，手動做一份並下載到本機。
2. 大量匯入內容、批次修改文章、跑資料庫最佳化之前，手動做一份。
3. 換主機、換網域、改網址結構之前，手動做一份並保留較長期限。
4. 發現任何異常（不明管理員帳號、不明檔案、流量異常）時，先保留當下狀態的備份再處理，不要覆蓋掉可用的舊版本。

如果你的站是用來接案的作品集或形象站，這份清單可以縮減頻率，但「每季演練」那一項我建議保留。作品集站的內容變動少，可是它掛掉的時機通常剛好是有客戶在看的時候，復原速度比備份頻率更重要。作品集站的架構考量我另外寫在接案作品集網站怎麼做。

最後給一個排序建議，如果你今天只能做一件事：先把「異地那一份」建起來，因為它處理的是最不可逆的風險。頻率、保留期、工具選擇都可以之後再調整，但「所有備份都跟站一起消失」這個結構性缺陷，只能靠異地副本解決。

做完異地之後，第二件事是排一次演練。一次成功的還原，帶給你的確定性遠超過三個備份外掛加起來的儀表板綠燈。

常見問題

主機商說有每日備份，我還需要自己備份嗎？

需要。主機商備份與你自己的備份共用同一個故障域，帳號或供應商出事時兩者會一起消失。帳號被停用、供應商發生大規模事故或結束服務都屬於這種情況；而且快照通常只能還原回同一家的環境，你拿不到可攜檔案。WordPress 官方文件也提到多數主機會備份整台伺服器，但向主機商索取副本需要時間，而災難發生時速度很關鍵，因此仍建議自己學會備份與還原（見 官方備份說明）。把主機商備份當成第二層，不要當成唯一一層。

只備份資料庫夠嗎？

不夠，資料庫與檔案是兩件不同的事，兩者都備才能完整還原。WordPress 官方文件明確指出這兩部分都需要才能完整還原一個典型的 WordPress 站，而且下載網站目錄並不會順便備份資料庫，因為資料庫存在另一套系統裡（見 官方備份說明）。只備份資料庫的還原結果是文章都在但所有圖片破圖，因為圖片檔存在 wp-content/uploads，資料庫裡只有路徑。

備份多久一次才夠？

用「你能接受重做多少內容」反推，那個時間長度就是你的備份間隔上限。這在災難復原領域對應的是 RPO——距離上一個可復原時間點的可接受最大時間量（定義見 AWS Well-Architected）。WordPress 官方文件的建議是：內容較少的小型網站每週一次，高活動、發文量大的網站每天一次，並且升級前一定要備份（見 官方備份說明）。有會員、留言或訂單的站要再往上加，因為那些資料你無法自己重做。

還原演練要多久做一次？

建議至少每季一次，並在換主機、升級 PHP 版本、更換佈景主題或大幅改版之後各補做一次。演練要在跟正式站無關的環境進行（本機工具或另一家主機的測試環境），並且只使用異地那份備份，不從原主機拿任何檔案。演練時記錄從開始到首頁正常顯示的時間，那個數字就是你真實的復原時間，比任何備份設定畫面都可靠。

備份要留幾份、留多久？

WordPress 官方文件建議保留至少 3 到 5 份近期備份，並把副本存在不同位置。做法上可以一份在主機、一份在雲端儲存、一份下載到本機（見 官方備份說明）。保留期則要長於「你發現問題所需的時間」，否則遇到緩慢的資料損壞或入侵時，所有備份都已經是壞的版本。我的做法是階梯式保留：最近七天每天一份、近一到兩個月每週一份、更早每月一份。

備份檔可以放在網站目錄裡嗎？

不建議，備份檔放在可公開存取的路徑等於把整站資料庫攤在網路上。它含有完整資料庫（使用者 email、密碼雜湊、留言資料）與 wp-config.php 的連線資訊，而自動化掃描工具會例行嘗試常見的備份路徑與檔名，目錄列表沒關時連猜檔名都不必。正確做法是備份完成後立即上傳到外部儲存並刪除本地副本；若必須留在站內，要放到 web root 之外，或用伺服器層規則封鎖存取並關閉目錄列表（Apache 的做法見 官方 .htaccess 說明）。

免費的備份外掛夠用嗎？

對多數個人站來說，只要能做到「排程、外部儲存、可單獨還原資料庫、備份檔是開放格式」這四件事就夠用。這些能力在免費版本中並非都不可得，具體差異請看各外掛官方頁面的說明（例如 UpdraftPlus、BackWPup）。真正決定你救不救得回來的，是有沒有異地副本與有沒有做過還原演練，而不是付費與免費的差別。本文不列價格與空間額度，因為這類資訊變動頻繁，請以官方頁面公告為準。

延伸閱讀

• 自架站新手的六個決策：網域、主機、佈景主題與上線後維護該怎麼取捨——備份屬於「上線後維護」，最好在選主機時就一起決定。
• WordPress 佈景主題推薦 2026：免費與付費主題怎麼選（含速度考量）——付費主題的安裝檔與授權要另外備份。
• Elementor 新手教學：從安裝到做出第一個頁面的完整步驟——視覺編輯器做的版面存在資料庫裡，還原時要一併驗收。
• Google Search Console 新手完整教學：從驗證網站到找出可優化關鍵字——用來確認演練站沒有被索引、還原後索引是否恢復。
• 在咖啡廳與共享空間工作：選點、設備、公共 Wi-Fi 資安與禮儀全指南——在外操作備份與後台時的連線安全。
• SEO 關鍵字研究工具推薦 2026：免費與付費工具怎麼搭配用——還原後若排名波動，可用來追蹤恢復狀況。