網站備份要救得回來：頻率、保留幾代、異地存放與還原演練怎麼訂

作者｜瞻新資訊　陳俊鳴顧問（資深SEO顧問・搜尋流量與銷售漏斗規劃）

問一家公司「網站有沒有備份」，十家有九家會說有。主機商每天自動備、後台裝了備份外掛、工程師說有在備。

換一個問法：「現在把網站整個刪掉，多久可以回來？回來的會是哪一天的內容？」多數人就答不出來了。

「有備份」跟「救得回來」是兩件事。 中間隔著四個問題：多久備一次、留幾份、放在哪裡、有沒有真的還原過。這篇把四個問題拆開來談，每一個都給判斷的方法，不給標準答案。每天有訂單的購物網站，跟半年才改一次的形象官網，答案本來就不會一樣。

先講清楚範圍：這裡說的網站備份，是替自己經營的網站留一份能還原的複本。把某個網頁的畫面存下來（像網站時光機那一類工具）是網頁存檔，是另一件事，文末的常見問題有一題說明差別。

網站備份救不回來的四種情況

有備份卻救不回來，原因通常落在四種：備份早就停了沒人知道、備份跟網站放在一起、只留了一份、從來沒有還原過。

最有名的例子是 GitLab。這家做程式碼代管的公司，在 2017 年 1 月 31 日有工程師誤刪了正式資料庫。他們每天都有備份，照理說還原就好。結果回頭去找備份，GitLab 自己寫的事故檢討是這樣描述的：每日的資料庫備份「不在那裡」，放備份的儲存空間是空的。

原因其實很小。備份程式的版本跟資料庫不合，每次執行都出錯；出錯會寄通知信，但通知信被收信端擋掉了。所以備份一直是失敗的，卻沒有任何人知道。

最後救回 GitLab 的，是一位工程師在事故前大約六小時、為了別的工作順手做的一份快照。即使如此，仍有大約 5,000 個專案、5,000 則留言、700 個新帳號的資料找不回來。檢討裡有一題問得很直接：為什麼備份流程沒有定期測試？答案是「因為沒有人負責」。

全是工程師的公司都會這樣，一般公司的官網更容易。四種情況攤開來看：

• 備份早就停了。 排程壞了、空間滿了、授權到期了，備份不再產生，也沒有人收到通知。
• 備份跟網站放在一起。 備份檔存在同一台主機上，主機壞掉或被入侵，兩個一起沒。
• 只留了一份。 新的蓋掉舊的，等你發現內容被改壞，唯一那份已經是壞掉之後的版本。
• 從來沒有還原過。 備份檔在，但沒人知道怎麼還原、要多久、還原出來缺什麼。

這四種情況有一個共同點：平常完全看不出來，要到出事那天才會知道。 後面幾節，就是一題對一題的解法。

網站備份要備哪些東西：檔案、資料庫，還有不在主機上的那幾樣

一個網站至少有兩個部分要備：檔案與資料庫。WordPress 官方文件講得很白：兩個都有，才能完整還原一個網站。

用搬家來比喻。檔案是房子和家具，也就是程式、版型、外掛、上傳的圖片；資料庫是你這幾年寫下來的東西，文章、訂單、會員資料都在裡面。只搬房子，裡面是空的；只搬內容，沒地方放。官方文件還提醒一件常被誤會的事：把網站資料夾整個下載下來，不會包含資料庫，資料庫要另外匯出。

真正容易漏的，是不在主機上的那幾樣：

最後一列最常被忽略。表單、電子報、預約、金流如果用的是外部服務，資料存在對方那裡，你的網站備份裡一筆都沒有。這類雲端服務的備份責任怎麼分，站上〈雲端預約系統的資料主權〉有完整的說明；這裡只要記得：定期把第三方服務裡的資料匯出一份，跟網站備份放在一起。

備份範圍的判準只有一句：把主機整台換掉之後，要讓網站恢復原樣還需要哪些東西，那些就都要備。

備份頻率怎麼訂：先問能接受丟掉多久的資料

備份頻率不是看網站大小，是看一個問題：如果現在出事，你能接受丟掉多久的資料？

每天備一次，最壞的情況是丟掉將近一天的資料；每週備一次，最壞是六天多。這段「最多會丟多久」，業界叫 RPO（復原點目標）。美國國家標準暨技術研究院（NIST）的應變計畫指引對它的說明是：出事之後，資料可以回復到中斷前的哪一個時間點，反映的是業務能容忍多少資料損失。這份指引是寫給美國聯邦機關的，這裡只借用定義。

所以問題要反過來問：丟掉多久的資料，我還補得回來？

• 形象官網，一個月改兩三次。丟掉一週，頂多重貼一篇文章。每週備一次，加上改完內容手動備一次，通常就夠。
• 天天發文的內容網站。丟掉一天，是一篇文章加上當天的留言，補得回來但很痛，每天備比較合理。
• 購物網站或會員網站。丟掉的是訂單與註冊，幾乎補不回來，資料庫要備得比每天更密。

算一筆帳會更有感覺。假設一家購物網站平均一天接 30 筆訂單，每天凌晨備份一次。傍晚出事，最壞是丟掉當天二十幾筆訂單：客人錢付了，你卻不知道該出貨給誰。改成每小時備一次資料庫，最壞是丟掉一兩筆。

WordPress 官方文件也是同一個方向：多久備一次，取決於你多常更新、資料不見時會有多難受，「這由你決定」，它只附了一個粗略的參考：小網站每週、更新頻繁的網站每天。NIST 的指引則寫，最低頻率要依資料的重要性與新資料產生的頻率來訂。兩份文件都把決定權交回給網站主人。

還有一個省成本的觀念：檔案跟資料庫可以用不同的頻率。 程式與版型只有更新或改版時才會動，資料庫卻是每一筆訂單都在變。資料庫備得密、檔案備得疏，比整包天天備划算。

💡 小提醒

不管平常多久備一次，更新系統核心、外掛或佈景主題之前，都先手動備一次。WordPress 官方文件寫的是「定期備份資料庫，而且每次升級前一定要備」。

備份要保留幾代：看多久才會發現出事

保留幾代，看的是另一個問題：從出事到你發現，中間會隔多久？

頻率管的是「最近那一份有多新」，代數管的是「最舊那一份有多舊」。這是兩個獨立的決定，很多人只想了前一個。

想像行車紀錄器。記憶卡滿了，新的畫面會蓋掉舊的。事故剛發生就去調畫面，沒問題；三天後才想到，那一段早被蓋過去了。

備份也一樣。美國電腦緊急應變小組（US-CERT）的備份文件提醒過：滾動式的備份，會把主檔案裡的損壞或惡意程式悄悄帶進備份。只留一份、每天覆蓋，等於只有一天的時間可以發現問題。

舉一個常見的情況。假設一家公司的形象官網，用主機方案內建的備份，只保留最近七天。某個外掛的漏洞讓網站被塞進隱藏的垃圾連結，首頁看起來一切正常，三週後才有人從搜尋結果發現不對勁。這時候打開備份清單，七份全部是被動過手腳之後的版本。備份每天都成功，還是救不回來。保留期間比發現問題的時間短，備份再勤也沒有用。

天天有人看後台的網站，發現得快，可以留短一點；放著半年沒人登入的官網，留兩三週等於沒留。

實務上常見的做法是「近的留密、遠的留疏」：最近的每天留一份，再往前每週留一份，更久以前每月留一份，不必存幾百份也回得到幾個月前。WordPress 官方文件建議至少保留三到五份近期的備份；要留多久，回到上面那個問題自己推。

順帶提醒，備份救得了資料，救不了漏洞。網站被入侵之後能不能直接還原，是另一套順序，站上〈網站中毒之後的處理順序〉有完整的說明。

頻率與代數是兩個數字，各由一個問題決定，不要只訂了一個就當作訂完了。

異地備份與 3-2-1 原則：別讓備份跟網站被同一件事帶走

備份要放在主機以外的地方，判準是：會讓網站消失的那件事，會不會把備份一起帶走。

這就像備用鑰匙。跟正本掛在同一串，包包掉了，兩把一起不見。備份檔存在同一台主機上就是這種情況：硬碟壞了、帳號被停了、被入侵了，網站跟備份同時消失。

大單位也會栽在這裡。2025 年 9 月底，韓國政府資料中心的機房發生火災，公務員共用的文件儲存系統跟著燒毀。韓聯社的報導指出，這套系統沒有做外部備份；主管部門的官員事後也承認，沒有外部備份是個錯誤。

談異地備份，一定會提到 3-2-1 原則：

• 3：重要的檔案保留 3 份（1 份正本加 2 份備份）。
• 2：放在 2 種不同的儲存媒體上。
• 1：其中 1 份放在異地。

最常被引用的官方出處，是 2012 年卡內基美隆大學替 US-CERT 製作的〈Data Backup Options〉，也就是上一節那份文件；文件的註腳註明，原則出自 Peter Krogh 寫給攝影師的數位檔案管理書。它本來就是一條經驗法則，不是哪一國的法規。

台灣的官方文件也採用它。數位發展部資通安全署 2026 年發布的〈中小企業基本資安防護指引〉，在「定期備份資料」那一項寫的是：3 份備份資料、2 種不同儲存媒體、1 份異地存放，而且至少 1 份要離線存放，並定期執行備份演練。兩份文件對「3 份」的數法不太一樣（US-CERT 把正本算在裡面），重點都一樣：不只一份、不同媒體、不同地點。

為什麼強調離線？因為勒索軟體會連備份一起加密。TWCERT/CC 的〈勒索軟體防護指南〉寫得很明白：備份資料必須離線儲存，不能連在既有的企業網路上。

美國網路安全暨基礎設施安全局（CISA）的勒索軟體指引把原因講得更直接：許多勒索軟體會先找出連得到的備份，刪除或加密，讓受害者不付贖金就沒辦法還原。備份如果跟網站一樣隨時連在線上，入侵者刪得到網站，也就刪得到備份。

後來也有備份軟體廠商提出 3-2-1-1-0 這類延伸版本，多加一份不可竄改的複本與還原零錯誤的要求。那是廠商的版本，不是官方標準。

異地要多遠才算異地

沒有規定的公里數。資安署在資安法常見問題回答過：異地備份宜朝「不遭受同一風險或事件影響」的方向考量，目前並未設置距離要求。這一題是回答公務機關的，判斷方式一般公司一樣用得上。換成網站的情況，就是三個檢查：

• 不在同一台主機上。
• 最好不在同一家服務商的同一個帳號底下，帳號被盜或被停權時才不會一起鎖住。
• 至少有一份平常是離線的，或是寫入之後不能被網站那邊的帳號刪改。

主機商的自動備份只能算其中一份

主機商有每日自動備份是好事，但它只是 3 份裡的 1 份。WordPress 官方文件說得很實際：多數主機商會備份整台伺服器，但要跟他們調出你的那一份需要時間，而出事時快速復原很關鍵，所以你得學會自己備份、自己還原。

選主機時該問哪些備份條件，站上〈WordPress 主機怎麼選？〉已經列過。這裡補上另一半：不同的備份方式，各自救不了什麼。

沒有哪一種方式可以單獨涵蓋全部情況，所以才需要不只一份。 多數中小企業的網站，用主機商自動備份、排程傳到異地、重大更新前手動下載一份這三樣搭配，就能補掉彼此的洞。

⚠️ 注意

備份檔不要放在網站的公開目錄底下。那個位置的檔案只要知道網址就下載得到，等於把整個資料庫（包含會員資料）放在門口。存在主機上的備份，要放在網頁連不到的位置，或是傳走之後就刪掉。

還原演練怎麼做：把網站備份還原一次，量出要多久

確認備份有沒有用，只有一個辦法：實際還原一次。 這跟消防演習是同一個道理，逃生門平常鎖著，要推一次才知道打不打得開。

演練不用很隆重，照下面五步做（官方文件沒有逐步清單，以下是實務做法）：

1. 挑一份備份，不要每次都挑最新的。 偶爾挑兩週前的，確認舊的也打得開。
2. 還原到另一個環境，不要蓋掉正式站。 測試站或自己的電腦都可以。
3. 照順序還原。 WordPress 官方文件建議先還原檔案，再匯入資料庫；資料庫的帳號密碼換過的話，設定檔要跟著改。
4. 逐項點一遍。 首頁、最近發的那一篇、後台登入、表單送出、圖片有沒有破；購物網站再看最近幾筆訂單在不在。
5. 記下三件事：花了多久、卡在哪裡、缺了什麼。

第五步最有價值。花了多久，就是這個網站實際的復原時間，業界叫 RTO（復原時間目標），NIST 指引的定義是：系統最多可以停擺多久，才不會對它支援的業務造成無法接受的影響。沒演練過的復原時間只是願望，演練過的才是數字。

復原時間拖長，賠掉的不只是那幾天的訂單。Google 搜尋中心在〈暫停或停用網站〉裡提醒，把整個網站停用只適合非常短的時間（最多幾天），否則會在 Google 搜尋中對網站造成重大影響；網站一旦從索引裡完全移除，恢復需要的時間並不固定，也沒有機制可以加快。這份文件談的是業主主動暫停網站，不是出事，但方向相同：網站消失得越久，搜尋那一邊越不是修好就立刻回來。

「缺了什麼」通常落在設定、金鑰與 DNS 這幾樣：憑證沒備、金流的金鑰不知道在哪、DNS 不知道原本怎麼設。這些東西只有真的還原一次才會浮出來。

還原演練多久做一次

沒有官方的固定頻率。NIST 的指引只說，要參照組織自己的政策與業務衝擊分析來決定。台灣的《資通安全責任等級分級辦法》附表十，對防護需求等級「中」的系統要求「定期測試備份資料，以驗證備份媒體之可靠性及資訊之完整性」，等級「高」的系統要「將備份還原，作為營運持續計畫演練之一部分」，同樣沒有寫多久一次。

要先說清楚：這部辦法管的是公務機關與特定非公務機關，不是所有企業的法定義務。 一般公司可以拿它當一把尺：連最基本的等級「普」，都要求「訂定資料可容忍損失之時間要求」並執行資料備份。先決定能丟多久的資料，是最低的要求，不是進階的做法。

一般公司比較實際的做法：網站上線時做一次，每次換主機或大改版再做一次，平常依網站的重要程度固定排。另外，每個月花五分鐘打開備份清單，看最新那一份的日期是不是昨天、檔案大小是不是跟上次差不多。GitLab 那種「備份一直失敗卻沒人知道」的情況，這一眼就擋得住。備份成功與否的通知，也要寄到有人會看的信箱，並且偶爾確認真的收得到。

備份檔裡有會員個資時，備份本身也要保護

只要資料庫裡有會員、訂單或表單留下的個人資料，備份檔就是另一份完整的個資檔案，要用同樣的標準保護。

現行《個人資料保護法》第 27 條要求，非公務機關保有個人資料檔案，要採行適當的安全措施，防止個人資料被竊取、竄改、毀損、滅失或洩漏。（2025 年 11 月修正公布的條文把這項義務移到第 20 條之 1，施行日期在本文查閱當日還沒有公告。）施行細則第 12 條列出這些措施可以包括的項目，像是資料安全管理及人員管理、設備安全管理、事故的預防通報及應變機制，並以跟保護目的「具有適當比例」為原則。

從條文可以讀出兩件事。「滅失」也在要防止的範圍裡，備份本身就是防止滅失的一種做法；反過來說，備份多一份，要保護的地方就多一處。

條文沒有指定要用哪一種技術。下面是建議做法，不是法條原文：

• 備份檔的存取權限只給需要的人，離職或換廠商時收回。
• 放在外部儲存的備份加密，或至少設成不公開。
• 下載到個人電腦的備份用完就刪，不要散落在好幾個人的硬碟裡。
• 過期的備份要真的刪掉。會員要求刪除資料之後，那筆資料還會在舊備份裡留一陣子；保留期間訂得越長，這個尾巴越長。

保留越多代越安全，但個資留得越久責任越重，這兩件事要一起看，不是代數越多越好。

一頁網站備份計畫：把六個答案寫下來，並指定負責人

一份備份計畫夠不夠，看三個時間就知道：最多會丟掉多久的資料、最久隔多久才會發現、要多久才救得回來。 前面的判斷，最後要收成一頁紙，回答六個問題就夠：

1. 備什麼？ 檔案、資料庫、設定與金鑰、DNS 紀錄、第三方服務的資料，各自在哪裡。
2. 多久備一次？ 資料庫與檔案分開寫，並寫下理由：能接受丟掉多久的資料。
3. 留幾代、留多久？ 寫下理由：多久才會發現出事。
4. 放在哪裡？ 至少兩個地方，其中一個不在主機上；誰有權限。
5. 怎麼還原、要多久？ 步驟寫下來，附上最近一次演練的日期與花費的時間。
6. 誰負責？ 誰確認備份有在跑、誰做還原演練、出事的時候誰動手。

第六題最重要。GitLab 的檢討已經示範過：工具都在，只是沒有人負責確認。

網站如果是委外製作或代管，這六題也是合約與規格該寫清楚的地方。備份多久一次、保留多久、還原要不要另外收費、交接時備份與帳號怎麼移交，都寫成可以驗收的句子，寫法可以參考〈客製化網站設計規格怎麼寫？〉裡非功能性需求那一節。

備份計畫的價值不在文件本身，在於出事那天，接手的人不用猜。 如果你的網站目前答不出這六題，或是不確定現有的備份到底能不能還原，瞻新資訊的團隊可以協助盤點現況，把缺的那幾題補上。

常見問題

參考資料

• Postmortem of database outage of January 31 — GitLab，2017-02-10（英文，國際，當事公司的事故檢討，2026-10-12 查證）
• Backups — WordPress Developer Resources，2026-06-04 更新（英文，國際，2026-10-12 查證）
• Contingency Planning Guide for Federal Information Systems（SP 800-34 Rev. 1） — 美國國家標準暨技術研究院（NIST），2010（英文，美國，對象為美國聯邦資訊系統，2026-10-12 查證）
• Data Backup Options — Paul Ruggiero、Matthew A. Heckathorn，卡內基美隆大學為 US-CERT 製作，2012（英文，美國，2026-10-12 查證）
• 資安署發布中小企業基本資安防護指引 三大面向16項檢核協助產業防駭 — 數位發展部資通安全署，2026-04-16（繁體中文，台灣，指引全文見頁面附件，2026-10-12 查證）
• 勒索軟體防護指南 — TWCERT/CC 台灣電腦網路危機處理暨協調中心，2023-01-19 更新（繁體中文，台灣，2026-10-12 查證）
• 資安法常見問題：資通安全責任等級分級辦法應辦事項—其他 — 數位發展部資通安全署（繁體中文，台灣，第 4.11 題，2026-10-12 查證）
• 資通安全責任等級分級辦法 — 全國法規資料庫，2026-01-07 修正（繁體中文，台灣，附表十資通系統防護基準，2026-10-12 查證）
• 個人資料保護法 — 全國法規資料庫，2025-11-11 修正公布、修正條文施行日期未定（繁體中文，台灣，2026-10-12 查證）
• 個人資料保護法施行細則 — 全國法規資料庫，2016-03-02 修正（繁體中文，台灣，2026-10-12 查證）
• #StopRansomware Guide — 美國網路安全暨基礎設施安全局（CISA）等，2023 年更新（英文，美國，2026-10-12 查證）
• 暫停或停用網站 — Google 搜尋中心，2025-12-31 更新（繁體中文，2026-10-12 查證）
• Wayback Machine General Information — Internet Archive（英文，美國，2026-10-12 查證）
• 112 online gov’t services restored after data center fire — 韓聯社（Yonhap）電稿，The Korea Times 刊載，2025-10-02（英文，韓國，通訊社報導，2026-10-12 查證）

ℹ️ 關於本文

本文引用的官方指引、法規條文與技術文件，以查閱當日（2026 年 10 月 12 日）的版本為準；法規會修正、官方文件會更新，實際請以主管機關與各文件的最新版本為準。文中對備份頻率、保留期間、存放位置與還原演練的判斷，是一般性的實務說明，實際做法會因網站的類型、資料量、主機環境與合約範圍而不同，不保證照做就能在任何情況下完整復原。涉及個人資料與資通安全法規的部分只是整理條文重點，不構成法律意見。文中的新聞事件引自通訊社報導，只當討論的例子。