雲端災難復原實戰：當公有雲機房斷線，您的 RTO/RPO 達標了嗎？

「我們的系統都已經上公有雲了，公有雲那麼穩，還需要做災難復原 (DR) 嗎？」這是許多企業 IT 主管常有的迷思。然而，歷史告訴我們，無論是 AWS 的 US-East-1 或是 GCP 的全球網路，都曾發生過區域性的重大斷線。把系統放上雲端，並不等於它擁有了自動跨區域存活的能力。

災難復原的兩大靈魂指標：RPO 與 RTO

在討論架構前，我們必須先幫助企業釐清業務的底線，也就是 RPO 與 RTO。這不是技術問題，而是純粹的商業決策：

• RPO (Recovery Point Objective，復原點目標)： 災難發生時，企業「最大能容忍遺失多少時間的資料」？如果是電商的訂單資料庫，RPO 可能必須趨近於 0（零遺失）；但如果是一般的報表系統，RPO 可能是 24 小時（每天備份一次即可）。
• RTO (Recovery Time Objective，復原時間目標)： 系統掛掉後，必須在「多久之內恢復對外服務」？如果是線上交易系統，RTO 可能要求在 15 分鐘內切換完畢；企業內部 ERP 則可能容忍 4 小時的 RTO。

要達到 RPO=0 且 RTO=0 的架構（如 Active-Active 雙活），其成本將是天文數字。JCloud 團隊的核心價值，就是協助企業在「預算」與「風險」之間找到最佳的黃金交叉點。

備份不等於備援：從 Pilot Light 到 Warm Standby

很多工程師以為設定了 EC2 快照 (Snapshot) 或 RDS 的自動備份，就做好了災難復原。事實上，當機房真的失聯時，要人工去另一個機房把快照轉成映像檔 (AMI)、重開機器、重設網路、修改 DNS... 這個過程往往會耗費數十個小時，嚴重違反企業的 RTO 承諾。

真正的災難復原 (DR) 架構，通常有以下幾種層級：

1. 備份與還原 (Backup & Restore)： 成本最低，但 RTO 最長。資料定期跨區域複製，災難發生時透過 Infrastructure as Code (IaC) 腳本重新拉起整個環境。
2. 指示燈架構 (Pilot Light)： 核心資料庫 (如 RDS) 在備援區域維持即時同步，但運算節點 (EC2/GKE) 平時是關閉或處於極小規模的。災難發生時才自動擴容 (Auto Scaling) 接手流量。這是成本與效益 CP 值最高的選擇。
3. 暖備援 (Warm Standby)： 備援區域平時就跑著一套縮小版的完整系統，能隨時提供服務。切換速度極快，但平時需支付雙倍的基礎設施費用。

對抗勒索軟體的最後防線：不可變備份 (Immutable Backup)

近年來，勒索軟體 (Ransomware) 的攻擊手法已經進化。駭客一旦潛入內網並取得高權限的 IAM 憑證，他們第一件做的事不是加密正式機，而是「清空你所有的備份」。如果你只有普通的快照，將會面臨無法復原的絕境。

為了防禦這種極端情況，JCloud 協助企業導入了符合 WORM (Write Once, Read Many) 規範的不可變備份架構。例如透過 AWS Backup Vault Lock 或 GCP Cloud Storage Object Hold。一旦資料被寫入這個保險庫，在設定的留存期限內（如 30 天），即使是擁有 AdministratorAccess 最高權限的根帳號，也絕對無法將其刪除或竄改。這確保了企業永遠握有乾淨且可還原的底牌。