作者：黃婉中（雲端架構師） 上篇簡介了HA、BCDR、Backup差異，這篇我們繼續談RTO、RPO、儲存備援 …作者：黃婉中（雲端架構師）

上篇簡介了HA、BCDR、Backup差異，這篇我們繼續談RTO、RPO、儲存備援還有技術選擇。

[caption id="attachment_176398" align="alignnone" width="806"] 對架構師來說，BCDR 的設計不是決定用什麼服務，而是根據風險與業務優先級，決定哪些系統值得高可用、哪些系統只需還原能力。（圖／123RF）[/caption]

重要概念：RTO 跟 RPO 是你選擇技術的依據

當你在規劃架構時，不要先想用什麼服務，先問自己兩件事：

1. RTO（Recovery Time Objective）：災難發生後，你能忍受系統最多中斷多久？
2. RPO（Recovery Point Objective）：你能忍受最多遺失多久前的資料？

支援圖片說明：

[caption id="attachment_176396" align="alignnone" width="676"] What are business continuity, high availability, and disaster recovery?（資料來源/ Microsoft Learn）[/caption]

這兩個數字決定你需要哪種架構：

• RTO 最多幾秒 → 你需要 HA
• RPO 可以接受數幾小時 → Backup 就能搞定
• 兩者都很敏感 → 必須投入完整的 BCDR 策略與預算

每一個選擇背後都是成本

舉例來說：

• 銀行的交易系統：每一筆資料都關係到金錢，幾乎不能有任何中斷與資料遺失 → 需要 HA + 高頻率同步 + 異地備援 + 快速 Failover。
• 一個內部庫存查詢系統：查不到資料不是馬上致命，只要隔天恢復就好 → Backup 即可。

正確的策略不是「用最厲害的技術」，而是「用合理的技術解決對你最重要的風險」。

補充重點：LRS、ZRS、GRS、RA-GRS 是什麼？它們和 BCDR 有什麼關係？

當你在設計 BCDR 架構時，不是只有 VM 要設計 HA，儲存的容錯能力也要一併考慮。這時候，就會遇到 Azure 上的儲存備援選項：LRS、ZRS、GRS、RA-GRS。
這些選項決定了你的資料能不能被讀取、能不能從災難中恢復，是構成 BCDR 策略的基礎。

（圖表來源／ 中途筆記）

支援圖片說明：

[caption id="attachment_176397" align="alignnone" width="813"] Data redundancy in Azure Files。（資料來源/ Microsoft Learn）[/caption]

換句話說：

• ZRS 是為了不中斷（BC）：讓資料在 Zone 掛掉時仍可即時存取。
• GRS/RA-GRS 是為了災後復原（DR）：讓資料在整個 Region 掛掉時仍能回復。
• LRS 則無法處理跨資料中心災難，只適合開發測試用途。

如果你正在規劃 BCDR 架構，但儲存還是用 LRS，就像蓋防火屋卻拿紙糊的地基一樣，風險潛藏卻看不見。

技術怎麼選？Azure 上可以這樣做：

（圖表來源／ 中途筆記）

想實現 BCDR，不是一個服務就搞定，而是多項組合、根據你的 RTO/RPO 需求，搭配設計出來的整體架構。

結論：選技術之前，先選擇「你能承受多少損失」

對架構師來說，BCDR 的設計不是決定用什麼服務，而是根據風險與業務優先級，決定哪些系統值得高可用、哪些系統只需還原能力。
在系統設計上，沒有萬能解。
你真正該問的是：

• 我的服務幾分鐘不能停？（這是 RTO）
• 我的資料最多能損失多久？（這是 RPO）
• 這個系統一旦中斷，會不會直接影響業務營收？
• 我能為這些風險投入多少預算？

這些問題的答案，才是BCDR 策略的起點。

小結

實現 BCDR 架構不是購買某一個 Azure 服務就能完成，而是依據你的業務目標、風險容忍度，去組合一組能支撐「不中斷」與「能復原」的整體策略。

還沒看上篇？先從這裡開始：雲端HA、BCDR、Backup 分不清？從客戶案例一次搞懂（上）

💡延伸閱讀

如果你對今天講的 HA、BCDR、RTO、ZRS 都感到有趣，或開始思考：「我也想變成能設計這種架構的人」，那你可能會對這篇文章有興趣：我如何轉職成為雲端解決方案架構師 Cloud Solution Architect

這篇文章 雲端HA、BCDR、Backup 分不清？從客戶案例一次搞懂（下）｜專家論點【黃婉中】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

作者：黃婉中（雲端架構師） 我想跟你聊聊 High Availability（HA）、BCDR（Busines …作者：黃婉中（雲端架構師）

我想跟你聊聊 High Availability（HA）、BCDR（Business Continuity & Disaster Recovery）、Backup、Failover 這幾個常被搞混的詞。

這不只是技術名詞的差別，而是關係到你公司的系統能不能「在關鍵時刻繼續營運」的核心問題。

[caption id="attachment_176385" align="alignnone" width="881"] 很多企業在選擇雲端架構方案時，其實還沒釐清「自己能接受多大的風險」，就跳進選技術或服務，結果花了錢卻買不到真正需要的東西。（圖／123RF）[/caption]

真實案例：關於「做 Backup」的誤會

有一次，一位客戶跟我說他想做 Backup。我問他為什麼，他說：

「因為之前美國有資料中心斷線，導致 host 在美國的網站全掛掉。所以我們現在想做 Backup，讓網站可以一直在線上。」

聽完後我問他：

「你是希望當資料中心斷線時，網站可以自動跑到其他地區（比如亞洲）繼續服務嗎？」

他點點頭：「沒錯。」

這時我跟他說：「那你要的其實不是 Backup，而是 High Availability（高可用性），搭配 Failover（自動切換） 的架構。」

是網站不中斷運行，不是資料能不能備份。

那 Backup 是什麼？

Backup 是為了資料保存。也就是說：如果你誤刪資料，或是系統中毒了，可以還原。
但問題是，你只能回到「最後一次備份的時間點」。所以會有資料遺失的風險（也就是 RPO）。
除非你做的是即時備份，但那是另一種解法，如 log shipping、replication 或者近乎即時的 snapshot 機制。

Backup 一定會有時間差。這段時間差可能是幾個小時，也可能是一兩天，取決於你的備份頻率。
如果你沒辦法接受這段資料遺失，那光靠 Backup 是不夠的。

HA、BCDR、Backup 的關係是什麼？

從架構師的角度來說， HA 和 Backup 都是 BCDR 策略的一部分。
BCDR 是一個大傘，涵蓋了「不中斷營運」（BC）+「災後能復原」（DR）這兩個方向。

用這張表格說明：

（圖表來源／ 中途筆記）

Failover（故障切換）是實現 HA 的常見手段之一。當系統出現異常時，會自動切換到備援資源（例如異地 VM、備用 DNS 端點），確保服務不中斷。但 Failover 是技術方法，不是最終目的，真正目標是維持「高可用性」。

小結

很多企業在選擇雲端架構方案時，其實還沒釐清「自己能接受多大的風險」，就跳進選技術或服務，結果花了錢卻買不到真正需要的東西。

在下一篇文章中，我會繼續說明：

• BCDR 的商業與成本考量
• 為什麼選擇儲存類型（LRS、ZRS、GRS）是成敗關鍵
• Azure 上該怎麼做出正確的技術選擇

接著看下篇：
HA、BCDR、Backup 分不清？從客戶案例一次搞懂（下）：BCDR 技術與儲存選擇怎麼搭配？

這篇文章 雲端HA、BCDR、Backup 分不清？從客戶案例一次搞懂（上）｜專家論點【黃婉中】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。