網站備份與災難復原指南：要備什麼、多久備一次、誰負責還原
備份這件事的尷尬之處在於：平常做得再好都沒有人會注意，真的需要用到時卻決定了公司能不能繼續營運。很多企業一直以為自己有備份，直到某天主機出狀況、開口要還原，才發現備份只有程式碼沒有資料庫，或是最近一次成功的備份已經是三個月前。
網站不是只會壞在硬體上。誤刪內容、改版覆蓋、外掛更新出錯、遭到入侵、服務商帳號問題，每一種都可能讓網站回不去。這篇把備份與復原的實務拆開來談，讓你能檢查現況並提出正確的問題。
備份要備的四類東西
「有備份」這句話太籠統，實際上一個網站由四類資產組成，缺一項就還原不回完整的樣子。
一、程式碼與樣板。 網站本身的程式、佈景、外掛與自訂功能。通常會存放在版本控制系統中，若有妥善使用，這一項其實是最安全的。
二、資料庫。 文章內容、商品、訂單、會員、設定值大多存在這裡。這是最重要也最容易被漏掉的一項——只備份檔案而沒備份資料庫，還原出來會是一個空殼。
三、使用者上傳的檔案。 圖片、影片、PDF、附件、會員上傳的證明文件。這些通常不在版本控制裡，一旦遺失無法從程式碼重建。
四、環境設定與憑證。 伺服器設定、網域與 DNS 設定、SSL 憑證、各項外部服務的金鑰與帳號歸屬。這一類不佔空間，卻最常被忽略；沒有它，即使前三項都在，也可能要花好幾天才能讓網站重新跑起來。
檢查現況的方式很直接：逐項問「這一類最近一次備份是什麼時候、存在哪裡、誰能取用」。四題都答得出來才算真的有備份。
頻率與保留期怎麼訂
備份頻率沒有標準答案，判斷依據只有一個問題：你能接受遺失多久的資料。
- 內容幾乎不變的形象官網，每週一次可能就夠。
- 有部落格或定期更新內容的網站，每日一次比較合理。
- 有訂單、會員、金流的網站，每日備份再加上資料庫的高頻備份才安全——遺失半天的訂單，後果通常不是重打資料就能解決。
另一個要一起訂的是保留期。只保留最近幾天的風險在於：很多問題不是當天發現的。資料被誤刪、內容被竄改，常常是幾週後才有人察覺，這時能還原的版本可能都已經出問題了。
常見的安排是每日備份留數週、每週備份留數個月、每月備份留一年。這種做法一般稱為分層保留，可以搭配業界常講的 3-2-1 原則一起看——同時保有多份副本、存放在不同媒介、其中一份放在異地。知道這兩個名詞的好處是，你可以直接用它們去問廠商，也方便自己延伸查資料。重點不是照抄這個組合，而是先想清楚「我最晚可能多久才會發現異常」，再往回推保留期。
還有一條原則值得遵守：備份不要只存在同一個地方。與網站放在同一台主機、同一個帳號下的備份，在帳號層級出問題時會一起消失。至少要有一份存在不同服務或不同帳號上。主機形式會影響能怎麼安排，可以對照網站主機怎麼選裡的比較。
沒有驗證過的備份等於沒有備份
這是實務上最痛的一課：備份程序每天都顯示成功，真的要還原時卻打不開，或還原出來的資料庫缺了幾張表。
備份會失敗的原因很多——磁碟寫滿、權限變更、資料表結構調整後的相容問題、排程被關掉沒人發現。這些問題在「備份」這一端都不會報錯，只有在「還原」時才會現形。
所以必須做兩件事：
自動檢查。 至少確認備份檔案有產生、大小落在合理範圍、不是零位元組。備份失敗時要有人收到通知，而不是靠人工去翻紀錄。
定期還原演練。 定期把備份實際還原到一個獨立環境，打開來確認內容正確、能登入、關鍵流程能跑。演練的時候順便記錄實際花了多久——這個數字就是你真實的復原時間，通常比想像中久。
演練頻率可以視系統重要性調整，但至少每年一次，以及每次架構有較大變動之後。
復原目標：兩個要先講定的數字
災難復原的規劃通常圍繞兩個概念，不需要記英文縮寫，理解意思即可。
可接受的資料遺失範圍。 出事時能接受回到多久以前的狀態。這個答案直接決定備份頻率——若只能接受遺失一小時的訂單，每日一次的備份顯然不夠。
可接受的停機時間。 從發現問題到服務恢復，最長能忍受多久。這個答案決定復原方式：能接受數小時的網站，從備份還原就夠；只能接受幾分鐘的系統，就需要預先準備好待命環境。
這兩個數字應該由經營層決定，而不是由工程端預設。設想一家以線上訂購為主要收入來源的店家，週末尖峰時段的停機成本和平日深夜完全不同，備援投資的合理程度也不一樣。先把數字講清楚，後面的安排才有依據。
不同災難的處理方式不一樣
把「災難」一詞拆開，會發現處理方式差很多：
- 硬體或服務商故障：影響範圍明確，通常從最近一次備份還原即可，重點是還原速度。
- 人為誤刪或改壞：常常只需要還原單一檔案或單一資料表，因此備份要支援「部分還原」，不能只有整台還原一種選項。
- 遭到入侵：不能直接還原了事，否則會把入侵管道一起還原回去。完整的處理順序與責任邊界屬於資安事故的範疇，見企業網站資安基本功；在備份這一端，只需要回答一個問題——哪一份備份才算乾淨。若查不出入侵是什麼時候開始的，就得一路往回找到可以確認乾淨的版本，這正是保留期不能只留最近幾天的理由，也是還原前要先看備份日期與內容的原因。
- 帳號層級的問題：例如服務商帳號被停用、負責人離職後無人知道帳號歸屬。這類問題靠技術備份救不了，要靠帳號與權限的制度管理。
最後一項特別值得提醒：所有服務的帳號都應該登記在公司名下並有清單，包含網域、主機、郵件、金流、分析工具。這份清單本身就是備份的一部分。
誰負責：把責任寫清楚
「我以為對方有在做」是備份失效最常見的原因。責任要落到具體的角色上，至少釐清這幾件事：
- 誰執行備份、用什麼方式、存放在哪裡。
- 備份失敗時通知誰、多久之內要處理。
- 還原由誰執行、需要誰授權。
- 還原演練多久做一次、結果給誰看。
- 發生事故時第一個聯絡的人是誰、非上班時間怎麼處理。
如果網站由外部團隊維護，這些應該明確寫進維護合約，而不是停留在口頭默契。合約內容與服務範圍的談法可以對照網站維護費用包含什麼。
合約裡的備份專屬條款
維護或開發合約的整體服務範圍是另一回事，這裡只列與備份、還原直接相關的六項，談約時可以逐條對照：
- 備份範圍：明列程式碼、資料庫、上傳檔、環境設定四類各自的處理方式，缺哪一類要寫明。
- 頻率與保留期：寫成具體的週期與保留長度，不要只寫「定期備份」。
- 存放位置與取用方式：存在哪裡、是否有一份在你自己的帳號下、你能不能自行下載、需要時多久能拿到。
- 還原服務的範圍：能不能做單一檔案或單一資料表的部分還原、哪些情況包含在維護費內、哪些屬於另行計費。
- 備份失效與還原請求的回應時間：備份連續失敗時多久通知你、你提出還原需求後多久開始處理。
- 合作結束時的移交：備份資料本身、帳號權限與設定清單的交付方式與時間。
這些條款在挑選合作對象時就可以拿出來問，對方的回答方式往往比條款本身更能說明他們的作業成熟度，相關提問可以參考如何挑選軟體開發公司。
現在就可以做的檢查
不需要等到規劃完整的災難復原方案，今天先確認這五題：
- 最近一次成功的備份是什麼時候？
- 備份包含資料庫和使用者上傳的檔案嗎？
- 備份存在哪裡？和網站是同一個帳號嗎？
- 上次實際還原成功是什麼時候？
- 網站現在完全掛掉，誰負責處理、預計多久能恢復？
若有任何一題答不出來，那就是目前最該補的缺口。備份的價值不在平常，而在你需要它的那一天——而那一天不會事先通知。
把上面五題問完之後，若有答不出來的項目想找人一起盤，和 NETVANA 聊聊你的專案。我們不賣固定方案：備份與復原的安排會依系統規模、資料敏感度與你能接受的停機標準逐案評估，確認要補的缺口之後才報價；服務範圍與交付物列在軟體服務介紹。
延伸閱讀：上線前該一併確認的項目，看網站上線前檢查清單；網域、主機與憑證的關係沒弄懂會影響復原速度，看網域與 DNS 白話指南；備份含有個資時的處理原則，看網站隱私權政策怎麼寫；長期缺乏維護會累積的風險，看技術債是什麼。
