災難復原 (DR) 規劃

災難復原 (DR) 簡介

對於 Professional Cloud Architect 而言，災難復原 (Disaster Recovery) 是為了「不可預見的情況」做準備——例如區域性停電、大規模數據損壞事件或勒索軟體攻擊。DR 與高可用性 (HA) 不同。HA 專注於在單個組件（如磁碟或區域）故障中生存，而 DR 則專注於在主要基礎設施發生 完整毀滅性故障 時生存。

白話文解釋（Plain English Explanation）

類比 1 — 有姊妹店的餐廳（跨區域複製）

想像台北一家熱門餐廳，在台中也開了一間一模一樣的姊妹店。每筆台北接到的訂單，幾秒內就被拍照傳真到台中——這就是 Cloud SQL Cross-Region Replica，複製延遲在秒級以下。如果颱風淹了台北（區域性故障），台中把菜單、食譜、訂位名單升格為「本店」（replica promotion），被 Cloud DNS Failover 重新導向的客人可以繼續點餐，最多只損失幾秒鐘的訂單（RPO）。

類比 2 — 有鏡像基地的機場塔台（多區域 Spanner）

大型機場在兩個城市各設一座塔台，透過同步投票同時處理航班資料。這就是 multi-region Spanner：寫入只有在跨區域達成多數共識（Paxos）後才會 commit。如果一座塔台被摧毀，另一座已經擁有每一個 byte 的資料——RPO 為零，RTO 幾近為零。代價是什麼？兩座塔台都得 24/7 滿編運轉，所以 Spanner 多區域的成本是單區域的約 3 倍。

類比 3 — 每季演練一次的保險（DR 演練節奏）

工廠買了地震保險，但也每季拿著馬錶做一次完整的疏散演練，事後寫檢討報告。有 DR 計畫 跟 知道 DR 計畫會動 是兩回事。跳過演練的公司，在真正出事時才發現 Backup and DR Service 的快照已經 47 天沒更新、Terraform state 不見了、沒人記得 on-call 輪值表。每季桌面推演 (tabletop) + 年度全量容錯演練，等於是 runbook 裡的火災警報。

定義 DR 目標：RTO 與 RPO

整個 DR 策略圍繞著兩個數字構建：

1. 復原時間目標 (RTO)： 可忍受的最大 停機時間。「在損失過多資金之前，業務可以離線多久？」（例如：4 小時）。
2. 復原點目標 (RPO)： 可忍受的最大 數據丟失量。「如果我們從備份中還原，我們可以接受丟失多少工作量？」（例如：15 分鐘的交易量）。

DR 分層定義：Cold、Warm、Hot

GCP 災難復原規劃指南把 DR 分為三層，對應不同 RTO/RPO 區間：

Cold DR (Backup and Restore)

• RTO： 小時到天。RPO： 小時（取決於備份頻率）。
• 架構： 資料存在 Cloud Storage (Nearline/Coldline/Archive)，沒有運算資源在跑。
• 復原： 用 Terraform 或 Deployment Manager 重建基礎設施，再還原資料。
• 成本來源： 只有儲存。運算 = $0，直到 failover。

Warm DR (Pilot Light / Warm Standby)

• RTO： 數分鐘到 1 小時。RPO： 秒到分鐘。
• 架構： DR 區域跑著最小化的 stack——Cloud SQL cross-region read replica、最小 size 的 GKE node pool、min_replicas=1 的 MIG。資料持續複製。
• 復原： 擴充運算、把 replica 升級為 primary、把 Cloud DNS 或 Global Load Balancer 後端重新指向 DR。

Hot DR (Active-Active / Multi-region)

• RTO： 秒（或零）。RPO： 零（Spanner）或近零。
• 架構： 流量同時從兩個區域服務，透過 Global External HTTP(S) LB。資料在 multi-region Spanner、multi-region BigQuery 或 multi-region GCS。
• 成本來源： 完整 stack 全時段雙倍運轉，通常是單區域成本的 2-3 倍。

Backup and DR Service 架構

Google Cloud Backup and DR Service（前身為 Actifio）是 GCE VM、Cloud SQL、VMware Engine、SAP HANA 以及地端負載的應用程式一致性備份產品。核心概念：

組件

• Management Console： 區域型部署，負責編排政策、排程、復原。
• Backup/Recovery Appliance： 跑在你 VPC 裡的 VM，處理快照接收。依容量分級（4 TiB 到 200 TiB）。
• Backup Vault： 不可變、不可刪除 的 GCS 後端儲存。一旦寫入並設定保留鎖，連 project owner 也無法在到期前刪除——這就是抗勒索軟體的關鍵。

Backup Plans

• 政策範本 定義頻率（例如：每小時快照）、保留時間（例如：30 天）、目標（vault 或 appliance）。
• 應用程式一致性 在 Windows 用 VSS、Linux 用 pre/post script，先 flush DB buffer 再做快照。
• 跨區域複製 把 vault 內容複製到第二個區域，提供地理冗餘。

gcloud 指令

# 建立 backup plan
gcloud backup-dr backup-plans create critical-vms-plan \
  --location=us-central1 \
  --resource-type=compute.googleapis.com/Instance \
  --backup-rules=name=hourly,frequency=HOURLY,retention=720h

Multi-region Spanner 容錯移轉

Cloud Spanner multi-region 配置（例如：nam-eur-asia1、nam3）透過 Paxos 共識在三個區域間做同步複製。

拓撲

• Read-write regions（2 個）： 持有完整副本、參與 Paxos 投票、服務寫入。
• Witness region（1 個）： 只存 metadata、參與投票、沒有資料副本。
• Read-only regions（選用）： 服務 stale read、不投票。

Failover 行為

• 自動： 如果一個 read-write region 失效，剩下的 quorum 繼續服務寫入，不需要人工介入。
• RPO = 0： 寫入只有在 Paxos 多數 commit 後才回應，資料遺失在設計上不可能。
• RTO ≈ 秒： 客戶端透過全域 Spanner endpoint 重新連到存活的 leader。

成本

Multi-region Spanner 的 node-hour 單價約是 regional Spanner 的 3 倍。非關鍵負載用 regional Spanner + 每日備份 便宜得多。

Cloud SQL 跨區域副本升級

MySQL、PostgreSQL、SQL Server 負載若需要 warm-standby DR：

設定

1. 在 primary 啟用 自動備份 與 binary logging。
2. 在 DR 區域建立 跨區域 read replica。
3. 透過 Cloud Monitoring 的 replica_lag 指標監控複製延遲。

容錯移轉程序（手動）

# 1. 停止應用程式對 primary 的寫入（或接受 replica lag 以外的資料遺失）
# 2. 升級 replica
gcloud sql instances promote-replica dr-replica --region=us-east1

# 3. 重新指向應用程式連線字串（或更新 Cloud DNS）
# 4. （primary 恢復後）設定反向複製或重建

取捨

• RPO： 等於複製延遲，通常是秒級，但在重寫入負載下會飆高。
• RTO： 升級 + DNS/設定變更約 5-15 分鐘。
• Promotion 是單向的： 升級後的 replica 變成獨立 primary，之後必須重建複製鏈。

GCS Turbo Replication

標準 multi-region GCS bucket 是非同步複製，最終一致（通常分鐘級）。Turbo replication 是 dual-region bucket 的付費附加功能，提供：

• RPO ≤ 15 分鐘 的 100% SLA——物件在寫入後 15 分鐘內必定在兩個區域都可讀。
• 每 GB 額外費用，加在標準 dual-region 儲存費用之上。
• 使用場景： 關鍵資料湖、受監管的封存、ML 訓練資料集——任何在 failover 後不能接受 stale read 的場景。

# 建立啟用 turbo replication 的 dual-region bucket
gcloud storage buckets create gs://critical-dr-bucket \
  --location=NAM4 \
  --enable-turbo-replication

Cloud DNS Failover Routing

Cloud DNS 支援多種 DR 用 routing policy：

Failover Policy

• Primary 與 backup 目標，搭配 health check。
• Primary 通不過 health check 時，DNS 自動回傳 backup IP。
• TTL 控制客戶端切換速度，DR 用途通常設 30-60 秒。

Geo Policy

• 根據來源 IP 的地理位置，把使用者導向最近的健康區域。
• 搭配 health check，可實作 active-active 拓撲。

Weighted Round-Robin (WRR)

• 依權重分配流量（例如 90% primary / 10% canary DR）。
• 適合 blue-green DR 測試。

# 用 gcloud 建立 failover policy
gcloud dns record-sets create api.example.com. \
  --zone=prod-zone --type=A --ttl=60 \
  --routing-policy-type=FAILOVER \
  --routing-policy-data="primary=10.0.0.1;backup=10.1.0.1" \
  --enable-health-checking

DR Runbook 範本

Runbook 把部落知識變成壓力下可重複執行的步驟。最低限度章節：

1. 偵測與宣告： 誰宣告災難？什麼訊號觸發（例如 Cloud Monitoring 告警、Service Health Dashboard 變紅）？
2. 角色： Incident Commander、Comms Lead、Tech Lead、Scribe。On-call 輪值放在 PagerDuty / Opsgenie。
3. 起飛前檢查： 驗證備份新鮮度、DR 區域容量、DR 專案的 IAM 權限。
4. Failover 步驟： 編號、可直接複製貼上的指令。包含上面那些 gcloud sql instances promote-replica 與 DNS 更新指令。
5. 驗證： Smoke test、health endpoint、資料完整性檢查。
6. Failback 程序： 原區域復原後怎麼切回去。
7. Post-mortem 範本： 時間線、根本原因、行動項目。

DR 演練節奏（每季）

未經測試的計畫只是願望。建議節奏：

每次演練都要產出 演練報告，記錄實測 RTO/RPO 對比目標、發現的缺口、追蹤改善的議題單。

桌面推演 (Tabletop) 步驟

桌面推演是結構化討論，通常 90-120 分鐘：

1. 情境簡報（10 分鐘）： 主持人提出情境——「UTC 02:30，us-central1 變得無法連線。客戶回報 5xx 錯誤。」
2. 第一輪 – 偵測（20 分鐘）： 團隊敘述：「我會先檢查 Cloud Monitoring uptime check，再看 Service Health Dashboard，然後 page IC。」
3. 第二輪 – 決策（30 分鐘）： 「要不要 failover？誰決定？SLO 違反到什麼程度算門檻？」
4. 第三輪 – 執行（30 分鐘）： 口頭走過 runbook 指令，標記遺漏的步驟、錯誤的負責人、過期的憑證。
5. 熱檢討 (Hotwash)（15 分鐘）： 收斂缺口、指派負責人、設定 deadline。

Google Cloud 上的 DR 模式

1. 冷災難復原 (Cold DR - 備份與還原)

• 方法： 數據備份到 Cloud Storage。運算資源不運行。
• 成本： 最低。
• 復原： 使用 Terraform 重新建立基礎設施並從 GCS 還原數據。
• 使用場景： 容許 24 小時停機時間的非關鍵應用程式。

2. 溫災難復原 (Warm DR - Warm Standby)

• 方法： 運行應用程式的「引導燈 (Pilot Light)」版本。資料庫複製到次要區域（例如：Cloud SQL 跨區域副本）。一個小型 GKE 叢集或少數 VM 處於待命狀態。
• 成本： 中等。
• 復原： 擴充待命的運算資源，並將副本資料庫提升為主資料庫。

3. 熱災難復原 (Hot DR - Active-Active / 多區域)

• 方法： 使用 Global External HTTP(S) Load Balancer 將流量分配到兩個區域。數據儲存在多區域資料庫中，如 Spanner 或 Multi-region BigTable。
• 成本： 最高。
• 復原： 零。如果 A 區域發生故障，負載平衡器只需將所有流量發送到 B 區域。

廠商鎖定 (Vendor Lock-in) 考量

DR 架構通常會加深雲端鎖定。要權衡的取捨：

依服務分層的鎖定程度

• 低鎖定： GCE VM + GCS 快照。磁碟與映像檔可匯出成 OVA，在 AWS/Azure 或地端 rehydrate。
• 中鎖定： Cloud SQL（PostgreSQL/MySQL/SQL Server 引擎本身可攜，但 GCP 管理的 control plane 不可攜）。透過 邏輯 dump + restore 遷移。
• 高鎖定： Spanner、BigQuery、Bigtable。專有 API，沒有 drop-in 替代品。跨雲 DR 需要 透過抽象層做雙寫，或者接受只能用 export 復原。

緩解策略

• 多雲 DR： 透過 Storage Transfer Service 把備份複製到 AWS S3 或 Azure Blob，提供終極的供應商故障保護。egress 很貴。
• 開源等價物： 能用 Cloud SQL for PostgreSQL 就不要用 Spanner；能用 GKE 就不要用 Cloud Run，提高可攜性。
• IaC 紀律： Terraform 模組能保持雲端中立就保持中立。把 GCP 專屬服務封裝在應用程式碼的 interface 後面。

DR 的關鍵 GCP 服務

測試 DR 計畫

未經測試的 DR 計畫不是計畫——而是願望。

• 混沌工程 (Chaos Engineering)： 使用工具模擬區域故障。
• 演練： 每年至少執行一次「容錯移轉演練 (Failover Drill)」。
• 自動化： 使用 基礎設施即程式碼 (IaC) 確保復原環境與生產環境完全一致。

架構師警告： 在 Active-Active 設置中要警惕「腦裂 (Split-Brain)」現象，即兩個區域都認為自己是「主 (Master)」。使用像 Spanner 這樣可靠的全域共識資料庫來防止數據損壞。 ::

FAQ — 災難復原規劃

Q1. 高可用性 (HA) 與災難復原 (DR) 相同嗎？

不。HA 防止區域內單個分區或組件的故障。DR 防止整個區域或整個雲端服務供應商的故障。

Q2. 「快照排程 (Snapshot Schedule)」如何協助 DR？

Persistent Disk 的快照排程允許你自動建立備份。透過檢查快照的「多區域」或「區域」儲存位置，可以確保即使原始分區發生故障，快照仍然可用。

Q3. 最便宜的 DR 策略是什麼？

冷災難復原 (Cold DR - 備份與還原)。你只需支付備份的儲存費用。在災難實際發生且需要重建之前，你無需支付任何運算費用 (VMs/GKE)。

Q4. 我可以使用 VPC 對等互連 (VPC Peering) 進行 DR 嗎？

你可以使用 VPC 對等互連來連接不同區域的網路，但對於 DR 數據複製，通常最好使用 Google 骨幹網路上的 內部 IP 位址，或者在連接地端環境時使用 Cloud VPN。

Q5. 什麼是 "Cloud DNS Failover"？

Cloud DNS 可以使用 運作狀態檢查 (Health Checks) 自動更改網域指向的位置。如果 A 區域的 IP 停止回應，DNS 可以自動將使用者引導至 B 區域的 IP。

架構師最終提示

在 PCA 考試中，請密切注意 RTO 和 RPO 要求。如果要求是「最低成本」，請選擇 Cold DR。如果是「最小停機時間」，請選擇 Warm Standby。如果是「任務關鍵型 / 零停機時間」，請選擇 Active-Active Multi-region。另外，請記住 Cloud Storage 是 DR 的「瑞士軍刀」——它是你的備份、記錄和映像檔應該存放的地方。