企業網站備份應採行 3-2-1 原則與定期還原演練以確保營運不中斷

確保網站安全的核心在於「異地、多版本、定期演練」。除了主機商提供的基本備份外，企業必須擁有獨立於主機環境之外的第三方備份，並每季執行一次還原演練，否則在遭遇勒索病毒或主機商機房故障時，備份檔案極可能因同步受損或失效而無法使用。

採用 3-2-1 備份架構防止單點故障導致資料全失

許多中小企業老闆誤以為主機商提供的「每日自動備份」就足夠，但這在資安邏輯上屬於單點故障（Single Point of Failure）。如果主機商的機房發生火災（如三年前歐洲機房失火事件）或你的主機帳號被駭客取得權限，儲存在同一環境下的備份檔案會隨之消失。必須落實 3-2-1 原則：

3 份副本：除了原始網站外，至少要有兩份備份。
2 種儲存媒介：不要全部放在同一台伺服器或同一個雲端硬碟。例如一份放在主機快照，一份放在外部物件儲存服務（如 AWS S3 或 Google Cloud Storage）。
1 份異地存放：備份必須存放在與網站伺服器物理位置不同的地方，甚至考慮跨國儲存。

取捨與代價：增加異地備份會產生額外的流量傳輸費與儲存費，且設定過程需技術介入。但相較於網站全毀後重建所需的時間成本與品牌商譽損失，這筆支出屬於必要的營運保險。

備份不是「有做就好」，必須根據業務性質設定復原點目標（RPO）與復原時間目標（RTO）。這決定了你萬一出事時，會損失多少小時的資料，以及需要花多久時間才能讓網站重新上線。

網站類型	資料變動率	建議 RPO (資料損失容忍度)	建議備份頻率	推薦儲存方式
形象官網	低 (僅偶爾更新文章)	24 - 48 小時	每日一次	主機快照 + 雲端硬碟 (Drive/Dropbox)
電子商務網站	高 (訂單、會員資料隨時變動)	1 - 4 小時	每小時同步資料庫	即時資料庫鏡像 + 每小時異地增量備份
內容媒體/論壇	中 (每日多篇稿件與留言)	6 - 12 小時	每日兩次	外部物件儲存 (S3/GCS) 支援版本控制

如果你的網站是電商平台，採用「每日備份」意味著一旦下午五點當機，你將損失當天所有訂單資訊，這對後續出貨與對帳會造成極大困擾。因此，電商類網站必須將「資料庫」與「靜態檔案（圖片）」分開處理，資料庫備份頻率應遠高於檔案備份。

「備份成功」不代表「還原會成功」。常見的備份失敗原因包括資料庫編碼錯誤、外掛衝突、或是備份過程中檔案毀損。企業應建立每季一次的還原檢核流程：

環境相容性檢查：在測試環境還原後，確認 PHP 版本、MySQL 版本是否與原環境一致。
資料庫完整性驗證：隨機抽查 10 筆最新的訂單或會員資料，確認有無亂碼或缺漏。
功能路徑測試：檢查網站圖片是否正確顯示（路徑是否仍指向舊網址）、聯絡表單是否能正常發送郵件。
SSL 憑證與權限檢查：還原後的檔案權限（Permissions）常會跑掉，導致網站出現 403 或 500 錯誤，必須確認 .htaccess 或 Nginx 設定檔已正確載入。

判斷準則：如果你的技術團隊或委外廠商無法在 4 小時內於測試機完成完整還原，代表目前的備份方案在實戰中是無效的，必須重新檢討自動化還原腳本或簡化備份結構。

現在的勒索病毒具有「潛伏性」，它會先感染你的主機並等待數週，確保你的所有備份檔案也都被加密感染後才發作。為了對抗這種威脅，企業應採用具備「物件鎖定（Object Lock）」功能的儲存空間。

這種技術稱為 WORM (Write Once, Read Many)。一旦備份檔案寫入雲端儲存空間，在設定的期限內（例如 30 天），任何人都無法刪除或修改這些檔案，即便駭客取得了你的雲端帳號權限也莫可奈何。這是目前對抗勒索病毒最有效的最後一道防線。

企業應根據自身技術能力選擇工具，不要盲目追求最高階的方案。若公司內部無專業網管，優先選擇自動化程度高的 SaaS 工具；若有開發團隊，則應自行串接 API 以節省長期成本。

現在請立即檢查你的網站管理後台，確認上一次「成功備份」的時間點，並手動下載一份備份檔到你的個人電腦中。這雖然是最原始的做法，但在你建立完善的 3-2-1 自動化架構之前，這是確保你今晚能睡得安穩的唯一方式。