什麼是災難復原？| Oracle 台灣

災難復原 (DR) 是組織內各種業務部門設計和維護之最重要業務持續計畫的一面。有效的災難復原計畫可減輕任務和關鍵業務系統發生非計畫或甚至計畫性中斷所造成的影響，降低企業營運並持續獲利的能力。

為達成此目標，DR 計畫為組織提供了靈活的結構，使組織能夠以統一且協同合作的方式運作，以復原、重新開發及重新活化系統，並建構更具彈性的基礎架構。

災難復原為何重要？

如果在計算薪資並撥款帳戶之前遺失其薪資系統，企業會繼續運作多久？公司因聯邦、州及地方稅的延遲付款而產生什麼罰款？公司會因為未準時支付員工的後果，以及員工的持續工作時間為何？

是否要進行災難復原？已不再是這個問題。真正的問題是，損失數分鐘、數天或數週重要資料和信託建立在數年後，真正的成本是多少？

由於現今組織預期會立即回應顛覆性的事件並保持營運，因此在預算充足的情況下，災難復原再也無法繼續維持原樣，組織必須更深入評估沒有計畫的實際成本，而不是被導入彈性計畫的成本所驅逐。例如，檢查無法達成的服務層級協議 (SLA)，或因停機而導致的收入損失。將執行 DR 的成本與罰款、收入損失、客戶信賴度損失做比較，然後選擇清楚。

營收、生產力及忠誠度損失影像；說明如下 — 來源：由 Forrester Consulting 代表 IBM 進行的委託研究，2019 年 8 月。「您的組織因為計畫性和非計畫性停機所造成的下列哪些成本？」
基本：美國大型企業 100 名 IT 主管 (排名前 3 名)

非計畫性停機

無論中斷是由自然災難、IT 營運商 / 服務供應商錯誤、資料毀損或勒索軟體攻擊所造成，組織都必須能夠自主避免營運中斷而導致災難性損失、被機會競爭者取代，以及聲譽和商譽損失。

雖然這些結果看似戲劇性，但它們反映許多知名組織近期的經驗，這些組織無法及時復原，並且遺失大量的關鍵交易資料、客戶資訊和信任。

各式各樣的情境和根本原因都可能破壞業務營運。

計畫性停機

雲端中的災難復原即服務 (DRaaS) 可為企業提供無與倫比的作業彈性選項。組織會比從災難性事件中復原更頻繁地使用災難復原解決方案來處理計畫性停機。

常見痛點

傳統災難復原方法需要投資自動化。

災難復原的主要目標

災難復原的兩個主要目標是盡可能快速將受影響的系統返回作業狀態，並在災難性事件或計畫性停機後，盡可能減少資料遺失。這兩個主要目標的測量結果分別稱為復原時間目標 (RTO) 和復原點目標 (RPO)。

視 IT 作業與業務擁有者之間的服務層次協議而定，每個業務系統對於這兩個指標會有不同的需求。

復原時間目標

復原時間目標是在計畫性或非計畫性中斷後，將業務系統回復至完全營運狀態所花費的時間。

復原點目標

復原點目標是造成任何指定業務系統有害之前，可能遺失的最大資料量。RPO 通常從上次資料備份、複製或快照的差異時間進行測量。

災難復原與高可用性

傳統上，高可用性 (HA) 可防止單一故障點發生，而災難復原可防止多個故障點發生。在雲端運算中，對於實體基礎架構層 (包括電源、冷卻、儲存、網路及實體伺服器) 的單一故障點的保護，會透過可用性和容錯域完全抽象化到整體架構中。

在這種情況下，高可用性可擴展，而且具有極高的彈性，可處理效能的資料遺失或遺失。幾乎所有企業級雲端供應商都會在其產品中建立高可用性。

當涉及複雜的資料對應和複寫技術時，可提供零資料遺失和零停機保護給資料庫的高可用性災難復原解決方案會變得昂貴。這些解決方案不提供勒索軟體保護，透過包含時間點復原點目標和不可變儲存的全面備份實現。

傳統高可用性解決方案可與低成本的雲端災難復原 (CDR) 解決方案搭配運作。附加的 CDR 技術為需要零資料遺失、零停機 HA 且需要長期增量倒回的勒索軟體保護的資料庫提供多一層保護。

內部部署災難復原是難以置信且昂貴的解決方案，因為在來源位置和固定的目標資料中心位置複製 IT 基礎架構需要高成本。它無法在 WAN 上運作或移轉不同環境之間的伺服器，因此需要來源與目標資料中心之間的專用迴路，才能像單一相互連線的 LAN 環境一樣運作。傳統災難復原也無法在不同的異質環境 (例如內部部署環境和雲端平台) 之間或在兩個不同的雲端平台之間移轉伺服器。

DRaaS 使用廠商提供的備份解決方案和開源移轉工具的修補工作，建立嚴格控管且高度特定的環境。一般使用者只能從其 VMware 內部部署環境，在 DRaaS 提供者的傳統代管環境中復原工作負載。這些供應商提供的解決方案可能相當昂貴，並受限於可保護的工作負載範圍和可支援的運算環境。

DR 工作流程、執行手冊及計畫

Oracle 通常會將 DR 工作流程稱為 DR 計畫。災難復原計畫 (或 Runbook) 是必須完成的預先決定步驟或作業清單，能夠將運算執行處理、平台、資料庫及應用程式轉換成雲端中預先確定的復原區域。這些作業包括進行災難復原作業 (例如切換移轉或容錯移轉) 時，由人力或部分自動化執行的所有作業或個別步驟。DR 計畫、DR 執行手冊及 DR 工作流程等術語都可以互換。

DR 作業 (切換移轉與容錯移轉的比較)

災難復原作業是執行 DR 計畫中每個預先確定的步驟或作業的程序，這些步驟或作業是將基礎架構、資料庫及應用程式回復為完全作業的狀態所需。使用兩個不同的術語描述將應用程式堆疊轉換成不同位置：容錯移轉和切換移轉。

故障轉移

容錯移轉意謂著應用程式、資料庫及虛擬機器發生故障時的非計畫性停機，以及所有資源 (包括儲存體、資料和來賓作業系統) 都處於不一致的狀態。在此情況下，主要雲端區域會假定完全無法存取或無法使用，這表示需要觸發真正的災難復原作業。

因此，DR 計畫中的所有災難復原作業只能在待命雲端區域執行。雲端提供者的 DRaaS 解決方案是專為待命區域的高可用性所設計，以確保雲端提供者的 DRaaS 解決方案能夠在災難性災難性攻擊時獲得存取和運作。

切換移轉

切換移轉意指計畫性停機時間，包括依序關閉應用程式、資料庫以及虛擬機器或伺服器。在這種情況下，主要和待命區域都正常運作，而且 IT 作業人員可以專注於將一或多個系統從一個區域「移轉」至另一個區域，以進行維護或完成輪流升級。

雲端部署策略

現代化企業可能會基於各種原因利用下列一或多個雲端部署模型，包括成本、效能及業務連續性需求。隨著公司持續將作業移轉至雲端，強大的雲端部署策略越來越普遍。

跨區域災難復原解決方案

跨區域災難復原解決方案可保護組織避免完整中斷，進而影響對單一雲端供應商雲端基礎架構中託管之業務系統的存取。如名稱所代表的意義，任一指定業務系統 (包括虛擬機器、資料庫和應用程式) 的整個應用程式堆疊都可以隨選轉換為不同地理位置中完全不同的雲端區域。

DRaaS 解決方案應該可以將整個企業系統 (例如人力資源入口網站、金融服務入口網站或企業資源管理應用程式) 轉換到完全不同的雲端區域。DRaaS 解決方案應該可以將整個企業系統 (例如人力資源入口網站、金融服務入口網站或企業資源管理應用程式) 轉換到完全不同的雲端區域。

跨區域災難復原解決方案 (例如 Oracle Cloud Infrastructure (OCI) Full Stack Disaster Recovery) 可保護整個企業應用程式，使其免於遭受整個雲端區域的災難性存取損失，包括該區域中所有可用性網域的損失。

混合式雲端 DR 解決方案

混合雲端 DR 是一個非常熱門的解決方案，可讓企業將工作負載和虛擬機器從自己的資料中心轉換到雲端基礎架構。混合雲端通常用來作為災難復原解決方案，以保護公司關鍵業務系統的資料和可行性。

對於 Oracle 客戶，混合雲端是 OCI 和實體伺服器、Oracle 雲端設備或公司實體資料中心內其他系統之間的鬆散式聯合。Oracle 雲端應用設備 (例如 Oracle Private Cloud Appliance X9-2 和 Oracle Exadata Cloud@Customer) 是與 OCI 自然整合的絕佳內部部署系統範例。

Oracle 合作夥伴的部分產品 (例如 Rackware) 可用來在內部部署基礎架構和 OCI 之間實現災難復原。您可以透過 Oracle Cloud Marketplace 取得機架軟體。

多雲端 DR 解決方案

多重雲端災難復原解決方案藉由將應用程式堆疊的各種元件分散至兩個或多個雲端提供者的雲端基礎架構，保護應用程式和資料。Oracle 與 Microsoft Azure 的合作關係是多重雲端關係的最佳範例。

災難復原即服務應該可以因應跨區域災難復原、混合雲災難復原以及多雲災難復原。OCI 目前可為跨區域災難復原和混合雲端災難復原提供 DRaaS。

資料庫的資料一致性

資料庫的可行災難復原解決方案應一律包括確保資料一致性的方法。資料庫可復原至完整資料一致性 (包括進行中的交易) 的時間點會定義復原點目標。

資料一致性遠低於無伺服器或純文字檔資料庫的問題，但將複雜的關聯式資料庫 (例如 Oracle Database 或 MySQL) 復原到指定時間點的資料一致性狀態非常複雜，但仍至關重要。

MySQL 資料庫的災難復原考量

在 OCI 中使用 MySQL Database 服務時，MySQL 資料庫系統是一或多個 MySQL 執行處理的邏輯容器。它提供一個介面來管理作業，例如佈建、自動備份以及時間點復原。

MySQL 二進位日誌和原生複製技術可實現時間點復原、高可用性和災難復原。MySQL 群組複寫通常用來建立本機容錯叢集以實現高可用性，而 MySQL 非同步複寫則通常用於地理分散式災難復原。

啟用高可用性的資料庫系統有三個 MySQL 執行處理放置在不同的可用性網域或容錯域。資料庫系統保證如果一個執行處理失敗，另一個執行處理會接管，而不會遺失資料，也不會發生最少的停止工作時間。為了在不同區域進行災難復原，也可以建立兩個資料庫系統之間的輸入複製通道。

您可以使用下列連結，深入瞭解雲端中 MySQL 的災難復原。

Oracle 資料庫的災難復原考量

Oracle Maximum Availability Architecture (MAA) 為 Oracle 資料庫提供架構、組態和生命週期最佳做法，可為位於內部部署、雲端或混合組態的資料庫啟用高可用性服務層次。

您可以使用下列連結深入瞭解 Oracle Maximum Availability Architecture 以在雲端中進行災難復原。

Oracle Maximum Availability Architecture 登陸頁面
Oracle Maximum Availability Architecture 參考架構
Oracle Maximum Availability Architecture Oracle Fusion Middleware 的最佳做法
Oracle Maximum Availability Architecture 的應用程式最佳做法

雲端部署架構

部署架構描述運算、平台 / 資料庫以及應用程式等各種元件在雲端區域之間部署，以建立從資料中心總故障復原的彈性方法。部署架構描述應用程式套件正常作業期間的所有內容，以及待命區域要復原哪些項目，才能再次執行。

Oracle 認為 DRaaS 解決方案應該具備納入任何 DR 部署架構組合的彈性，以滿足每個獨特業務系統的個別服務層次需求。雲端供應商應該提供客戶自由選擇「上述所有」解決方案，以滿足組織通常支援的各種商業系統 SLA。

許多術語均用於描述災難復原策略與部署架構。不過，描述如何部署災難復原的基礎架構、平台及應用程式的各種方法和樣式，分成兩個廣泛的策略類別：作用中 / 作用中和作用中 / 待命災難復原。

下表分解了用於描述落於兩個廣泛 DR 策略之不同部署架構的常用術語。

策略	部署架構	RPO	RTO
作用中 / 待命	冷待命	小時	小時
作用中 / 待命	飛行燈	分鐘	小時
作用中 / 待命	暖待命	秒	小時
作用中 / 待命	熱待命	秒	分鐘
有效 / 有效	有效 / 有效	接近零	接近零

本節嘗試區分作用中 / 作用中和作用中 / 待命方法與災難復原的部分變化。這兩種災難恢復策略都有它們在武器庫中實現業務連續性。

作用中 / 待命部署架構

作用中 / 待命部署架構有許多變化。作用中 / 待命部署 (有時稱為作用中 / 被動部署) 通常會被描述為試驗燈、冷、暖和熱待命部署。

試行方案燈、冷待命資料庫、暖待命資料庫和熱待命方案都代表相同主題的某些形式，其中 100% 的應用程式堆疊在主要區域執行，而同一業務系統的 100% 則是在待命區域中主動執行。

下列一系列非常高階的概念圖表是說明常見部署架構之間的部分基本差異，並不表示作為參照架構；它們並不描述如何為應用程式堆疊實行 DR。

冷待命

在此情況下，虛擬機器 (VM)、資料庫及應用程式只存在於目前的主要區域。包含開機磁碟的檔案和區塊儲存磁碟區群組以及每個 VM 的其他虛擬磁碟，都會複製到待命區域。

在切換移轉或容錯移轉等災難復原作業期間，會在待命區域啟用包含相同 VM 的複製儲存，並在停止或當機時再次啟動相同的確切 VM。VM 是先前在作用中區域執行之相同虛擬機器。

此部署架構有多項優點，包括降低部署成本、降低維護負荷和降低營運成本。不過，這可能不是依賴關聯式資料庫的後端應用程式的最佳解決方案，因為唯一能確保資料一致性執行定期冷備份的方式。此方法適用於可容許偶爾短暫完整中斷的應用程式。

大多數 IT 作業都會定期關閉資料庫、建立區塊儲存的快照，然後繼續正常作業來解決這個問題。這會定義復原點目標，因為您只能回復至完成備份的時間點。

此架構將有稍微長的復原時間，因此資料遺失的風險也大幅增加，但它是正確工作負載的可行解決方案。舉例來說，這對於依賴純文字檔資料庫、無伺服器資料庫或完全沒有資料庫的應用程式來說，這可能是絕佳的解決方案，或只想在區域之間進行一組虛擬機器行動以提高彈性的客戶不用。

此部署架構的 DR 工作流程範例

下列兩個案例概述冷待命部署災難復原作業的處理流程如何進行。

若為切換移轉，會在主要和待命區域執行下列作業：

主要應用程式已靜止。
主要資料庫已靜止並同步至待命區域。
主要虛擬機器會妥善停止。
主要儲存已同步至待命區域。
複寫式儲存於線上，系統會反向複寫，而且現在是待命區域中的主要儲存體。
會啟動主要虛擬機器的複寫複本，以及應用程式堆疊所需的任何系統應用程式或工具，而且現在都位於待命區域。
使用複製儲存體中的最新冷備份或交易和重做日誌，在待命區域復原主要資料庫的複製複本。
會啟動並掛載主要資料庫的複製複本，現在則是待命區域的主要資料庫。
系統會啟動並驗證主要應用程式的複製複本，現在則是待命區域的主要應用程式。
對 DNS 和負載平衡器進行的任何變更，都可以透過公用網路存取應用程式。

在容錯移轉的情況下，下列工作只會在待命區域執行：

複寫式儲存於線上，系統會反向複寫，而且現在是待命區域中的主要儲存體。
會啟動主要虛擬機器的複寫複本，以及應用程式堆疊所需的任何系統應用程式或工具，而且現在都位於待命區域。
使用複製儲存體中的最新冷備份或交易和重做日誌，在待命區域復原主要資料庫的複製複本。
會啟動並掛載主要資料庫的複製複本，現在則是待命區域的主要資料庫。
系統會啟動並驗證主要應用程式的複製複本，現在則是待命區域的主要應用程式。
對 DNS 和負載平衡器進行的任何變更，都可以透過公用網路存取應用程式。

暖待命

在此情況下，虛擬機器同時存在於主要和待命區域，但彼此完全獨立，並且具有自己的唯一主機名稱和預先指定的 IP 位址。待命區域的 VM 存在，因此可依據客戶偏好設定來停止或執行。

資料庫必須在主要和待命區域執行。

對於 Oracle 資料庫，建議您使用 Oracle Data Guard 來複製主要和待命資料庫。如需詳細資訊，請參閱我們的金級 MAA 參考架構。

若為非 Oracle 資料庫，將使用個別的原生複製技術來讓資料庫在主要和待命區域之間保持同步。

應用程式也存在於待命雲端區域，但無法執行或存取。

此部署架構的 DR 工作流程範例

下列兩個案例概述了暖待命部署災難復原作業的處理流程如何可能進展。

若為切換移轉，會在主要和待命區域執行下列作業：

主要應用程式已靜止。
主要資料庫已靜止並同步至待命區域。
主要虛擬機器會妥善停止。
主要儲存已同步至待命區域。
複寫式儲存於線上，系統會反向複寫，而且現在是待命區域中的主要儲存體。
如果還沒有執行，則會啟動待命虛擬機器，並且會啟動應用程式堆疊所需的任何系統應用程式或工具，而且待命虛擬機器現在也會是在待命區域的主要應用程式或工具。
待命資料庫已切換為完整讀取 / 寫入存取，現在是待命區域的主要資料庫。
備用應用程式已啟動並驗證，現在主要位於備用區域。
對 DNS 和負載平衡器進行的任何變更，都可以透過公用網路存取應用程式。

在容錯移轉的情況下，下列工作只會在待命區域執行：

複製的儲存體會上線，如果可以，便會回復複製，而且在待命區域會成為主要儲存體。
如果還沒有執行，則會啟動待命虛擬機器，並且會啟動應用程式堆疊所需的任何系統應用程式或工具，而且待命虛擬機器現在也會是在待命區域的主要應用程式或工具。
使用複製儲存體中的最新交易和重做日誌來復原待命資料庫。
待命資料庫已切換為完整讀取 / 寫入存取，現在是待命區域的主要資料庫。
備用應用程式已啟動並驗證，現在主要位於備用區域。
對 DNS 和負載平衡器進行的任何變更，都可以透過公用網路存取應用程式。

熱待命

在此情況下，虛擬機器會存在，而且會在主要和待命區域執行，並且具有自己的唯一主機名稱和預先指派的 IP 位址。

資料庫必須在主要和待命區域執行。

對於 Oracle 資料庫，建議您使用 Oracle Data Guard 來複製主要和待命資料庫。如需詳細資訊，請參閱我們的金級 MAA 參考架構。

若為非 Oracle 資料庫，將使用個別的原生複製技術來讓資料庫在主要和待命區域之間保持同步。

應用程式在待命雲端區域執行，但無法透過公用網路存取。

此部署架構的 DR 工作流程範例

下列兩個案例概述熱待命部署災難復原作業的處理流程。

若為切換移轉，會在主要和待命區域執行下列作業：

主要應用程式已靜止。
主要資料庫已靜止並同步至待命區域。
主要虛擬機器會妥善停止。
主要儲存已同步至待命區域。
複寫式儲存於線上，系統會反向複寫，而且現在是待命區域中的主要儲存體。
待命虛擬機器已在執行中，而且應用程式堆疊所需的任何系統應用程式或工具都已啟動，現在待命虛擬機器已是在待命區域的主要程式。
待命資料庫已切換為完整讀取 / 寫入存取，現在是待命區域的主要資料庫。
備用應用程式已啟動並驗證，現在主要位於備用區域。
對 DNS 和負載平衡器進行的任何變更，都可以透過公用網路存取應用程式。

在容錯移轉的情況下，下列工作只會在待命區域執行：

複製的儲存體會上線，如果可以，便會回復複製，而且在待命區域會成為主要儲存體。
如果還沒有執行，則會啟動待命虛擬機器，並且會啟動應用程式堆疊所需的任何系統應用程式或工具，而且待命虛擬機器現在也會是在待命區域的主要應用程式或工具。
使用複製儲存體中的最新交易和重做日誌來復原待命資料庫。
待命資料庫已切換為完整讀取 / 寫入存取，現在是待命區域的主要資料庫。
備用應用程式已啟動並驗證，現在主要位於備用區域。
對 DNS 和負載平衡器進行的任何變更，都可以透過公用網路存取應用程式。

作用中 / 作用中建置架構

在此情況下，整個應用程式堆疊會完全發揮功能，並在主要和待命區域中處理工作負載。

資料庫必須在主要和待命區域執行。

對於 Oracle 資料庫，建議您使用 Oracle GoldenGate 來設定作用中 / 作用中應用程式組態。除此之外，建議您在每個區域都使用 Oracle Data Guard 達成幾乎零 RTO 和 RPO。如需詳細資訊，請參閱我們的白金級 MAA 參考架構。

若為非 Oracle 資料庫，將使用個別的原生複製和主動 / 主動技術，讓資料庫在主要與待命區域之間保持同步。

應用程式在待命雲端區域透過公用網路執行及存取，並且具有正在執行的工作負載。

Oracle 團隊一直致力於為其產品設計高可用性 (包括大多數的 Oracle 企業級資料庫和應用程式)，並且經常設計最佳實務和部署架構，以便在傳統的內部部署設定和雲端中實現災難復原。每個產品線都會設計一個災難復原 (DR) 方法，針對個別應用程式納入鬆散耦合步驟，以復原支援其應用程式所需的所有元件。

以雲端為基礎的災難復原即服務，可將開發人員、雲端架構師和產品解決方案架構師所設計的所有鬆散耦合步驟，結合成單一而流暢的工作流程，只要按一下即可起始此工作流程。OCI 提供一個稱為 Full Stack Disaster Recovery 的 DRaaS 解決方案，此方案具有彈性、高擴展性且高度可擴展性。

OCI Full Stack Disaster Recovery 只需按一下，即可管理 OCI 區域之間從全球任何地方過渡的基礎架構、資料庫和應用程式。客戶可以在不重新設計或重新部署現有基礎架構、資料庫或應用程式的情況下部署災難復原環境，同時排除專業化管理或轉換伺服器的需求。

深入瞭解 OCI 全堆疊災難恢復
進一步瞭解 OCI 的災難復原