# REL13-BP02 使用定義的復原策略來滿足復原目標
<a name="rel_planning_for_recovery_disaster_recovery"></a>

 定義一個符合工作負載復原目標的災難復原 (DR) 策略。選擇如下策略：備份與還原；待命 (主動/被動)；或是主動/主動。 

 如果您的主要位置變成無法執行工作負載，則災難復原策略會依賴在復原站點中支持您工作負載的能力。最常見的復原目標為 RTO 和 RPO，其討論在 [REL13-BP01 定義停機和資料遺失的復原目標](rel_planning_for_recovery_objective_defined_recovery.md)。 

 單一 AWS 區域 內跨多個可用區域 (AZ) 的 DR 策略可以緩解火災、洪水和重大停電等災難事件。如果需要實作保護，以防範阻止您的工作負載在給定 AWS 區域 中執行且不太可能發生的事件，您可以使用一個使用多個區域的 DR 策略。 

 在跨多個區域架構 DR 策略時，您應該選擇下列其中一個策略。這些策略按成本和複雜度遞增的順序列出，以及按 RTO 和 RPO 的遞減順序列出。 *復原區域* 稱為 AWS 區域，而不是用於工作負載的主要區域。 

![\[圖表：顯示 DR 策略\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2022-03-31/framework/images/disaster-recovery-strategies.png)

+  **備份與恢復** (RPO 幾小時，RTO 24 小時以內)：將您的資料和應用程式備份至復原區域。使用自動或連續備份將啟用時間點復原，在某些情況下可以將 RPO 降低至 5 分鐘。如果發生災難，您將部署您的基礎設施 (使用基礎設施架構即程式碼來減少 RTO)、部署您的程式碼，並還原備份的資料以從復原區域中的災難中復原。 
+  **指示燈** (RPO 幾分鐘，RTO 幾十分鐘)：在復原區域中佈建核心工作負載基礎設施的副本。將您的資料複寫到復原區域並在該處建立其備份。支援資料複寫和備份所需的資源 (例如資料庫和物件儲存) 始終處於開啟狀態。其他元素 (例如應用程式伺服器或無伺服器運算) 未部署，但可在需要時使用必要的組態和應用程式碼建立。 
+  **暖待命** (RPO 幾秒鐘，RTO 幾分鐘)：維持工作負載的縮減但完整功能版本，該工作負載始終在復原區域中執行。業務關鍵系統會完全複製且持續開啟，但叢集會縮小。資料會被複寫並存在於復原區域中。當需要復原時，系統會迅速擴展以處理生產負載。熱待命的縱向擴增越多，對 RTO 和控制平面的依賴就越低。完全擴展時，稱之為 **熱待命**。 
+  **多區域 (多站點) 主動-主動** (RPO 近乎零，RTO 可能為零) 您的工作負載會部署至多個 AWS 區域，並主動處理來自多個 AWS 區域 的流量。此策略需要您跨區域同步資料。必須避免或處理在兩個不同區域複本中寫入同一記錄所引起的可能衝突，這可能很複雜。資料複寫對於資料同步很有用，而且可以保護您防範某些類型的災難，但它不能保護您防範資料損毀或破壞，除非您的解決方案也包括時間點復原的選項。 

**注意**  
 指示燈和暖待命之間的差異有時可能很難理解。這兩者都在您的復原區域中包含一個環境，其中具有主要區域資產的副本。區別在於，若未先採取額外動作，指示燈無法處理請求，而暖待命可以立即處理流量 (容量層級降低)。指示燈將需要您開啟伺服器，可能會部署額外 (非核心) 基礎設施並縱向擴展，而暖待命只需要您縱向擴展 (一切都已部署並執行中)。根據您的 RTO 和 RPO 需求在這兩者之間進行選擇。

 **預期成果：** 

 對於每個工作負載，都有一個已定義和實作的 DR 策略，讓該工作負載能夠實現 DR 目標。工作負載之間的 DR 策略會利用可重複使用模式 (例如上述策略)。 

 **常用的反模式：** 
+  針對具有類似 DR 目標的工作負載實作不一致的復原程序。 
+  災難發生時臨時實作 DR 策略。 
+  沒有 DR 計劃。 
+  復原期間依賴控制平面操作。 

 **建立此最佳實務的優勢：** 
+  使用定義的復原策略可讓您使用常用的工具和測試程序。 
+  使用定義的復原策略可讓您更有效地在團隊之間分享知識，並更輕鬆地在他們擁有的工作負載上實作 DR。 

 **若未建立此最佳實務，暴露的風險等級為：** 高 
+  若沒有事先規劃、實作和測試災難復原策略，您就不可能在發生災難時實現復原目標。 

## 實作指引
<a name="implementation-guidance"></a>

 對於其中每一個步驟，請參閱下列詳細資訊。 

1.  確定將滿足此工作負載之復原要求的 DR 策略。 

1.  審查如何實作所選 DR 策略的模式。 

1.  評估工作負載的資源，以及在容錯移轉之前 (在正常操作期間) 其哪個組態將位於復原區域中。 

1.  確定並實作如何在需要時 (在災難事件期間) 使您的復原區域為容錯移轉做好準備。 

1.  確定並實作如何在需要時 (在災難事件期間) 將流量路由至容錯移轉。 

1.  設計您的工作負載將如何復原的計劃。 

 **實作步驟** 

1.  **確定將滿足此工作負載之復原要求的 DR 策略。** 

 選擇 DR 策略是在減少停機時間和資料遺失 (RTO 和 RPO) 與實作策略的成本和復雜性之間進行取捨。您應該避免實作比其所需更嚴格的策略，因為這會產生不必要的成本。 

 例如，在下圖中，企業已確定其最大允許的 RTO 以及其可以在服務還原策略上花費的限制。鑑於業務目標，DR 策略指示燈或暖待命將同時滿足 RTO 和成本準則。 

![\[圖形：顯示根據 RTO 和成本選擇 DR 策略\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2022-03-31/framework/images/choosing-a-dr-strategy.png)


 若要深入了解，請參閱 [業務持續性計劃 (BCP)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/business-continuity-plan-bcp.html)。 

1.  **審查如何實作所選 DR 策略的模式。** 

 此步驟在於了解您將如何實作所選策略。使用 AWS 區域 做為主要站點和復原站點來解釋這些策略。不過，您也可以選擇使用單一區域內的可用區域，做為您的 DR 策略，這會利用其中多個策略的元素。 

 在此步驟之後的後續步驟中，您會將此策略套用至您的特定工作負載。 

 **備份與恢復**  

 *備份與恢復* 是最不複雜的實作策略，但需要更多時間和精力來還原工作負載，從而導致更高的 RTO 和 RPO。始終對資料進行備份並將其複製到另一個站點 (例如另一個 AWS 區域) 是一種很好的做法。 

![\[圖表：顯示備份和還原架構\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2022-03-31/framework/images/backup-restore-architecture.png)


 如需此策略的詳細資訊，請參閱 [AWS 上的災難復原 (DR) 架構，第 II 部分：具有快速復原的備份和還原](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-ii-backup-and-restore-with-rapid-recovery/)。 

 **指示燈** 

 使用 *指示燈* 方法，您可以將資料從主要區域複寫至復原區域。用於工作負載基礎設施的核心資源會部署在復原區域中，不過，仍需要額外的資源和任何相依性，才能使其成為功能堆疊。例如，在圖 20 中，未部署任何運算執行個體。 

![\[圖表：顯示指示燈架構\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2022-03-31/framework/images/pilot-light-architecture.png)


 如需此策略的詳細資訊，請參閱 [AWS 上的災難復原 (DR) 架構，第 III 部分：指示燈和暖待命](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/)。 

 **暖待命** 

 AWS Well-Architected *基礎架構* 方法涉及確保在另一個區域中有一個縮減規模，但功能完全的生產環境副本。這種方法擴充了指示燈概念並減少了復原時間，因為您的工作負載始終在另一個區域中開啟。如果部署完整容量的復原區域，這稱為 *熱待命*。 

![\[顯示圖 21 的圖表：暖待命架構\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2022-03-31/framework/images/warm-standby-architecture.png)


 使用暖待命或指示燈需要縱向擴展復原區域中的資源。若要確保需要時容量可用，請考慮針對 [EC2 執行個體](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-reservations.html) 使用容量保留。如果使用 AWS Lambda，則 [佈建的並行](https://docs.aws.amazon.com/lambda/latest/dg/provisioned-concurrency.html) 可以確保執行環境，以便它們準備好立即回應您的函數叫用。 

 如需此策略的詳細資訊，請參閱 [AWS 上的災難復原 (DR) 架構，第 III 部分：指示燈和暖待命](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/)。 

 **多站點主動/主動** 

 您可以同時在多個區域中執行工作負載，做為 *多站點主動/主動* 策略。多站點主動/主動會為來自其部署至的所有區域的流量提供服務。基於 DR 以外的理由，客戶可能會選取此策略。它可以用來提高可用性，或在將工作負載部署至全球對象 (使端點更靠近使用者和/或將本地化的堆疊部署到該區域的對象) 時使用它。作為 DR 策略，如果工作負載無法在其部署至的其中一個 AWS 區域中得到支援，則會撤離該區域，而其餘區域則會用來維護可用性。多站點主動/主動是災難復原策略中操作最複雜的策略，因此只有在業務要求有此需要時才應選取它。 

![\[圖表：顯示多站點主動/主動架構\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2022-03-31/framework/images/multi-site-active-active-architecture.png)


 如需此策略的詳細資訊，請參閱 [AWS 上的災難復原 (DR) 架構，第 IV 部分：多站點主動/主動](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iv-multi-site-active-active/)。 

 **其他保護資料的做法** 

 使用所有策略時，您還必須緩解資料災難。持續資料複寫可以保護您防範某些類型的災難，但它不能保護您防範資料損毀或破壞，除非您的策略也包括所存放資料的版本控制，或時間點復原的選項。除了複本之外，您還必須備份復原站點中的複寫資料，以建立時間點備份。 

 **在單一 AWS 區域 內使用多個可用區域 (AZ)** 

 在單一區域內使用多個 AZ 時，您的 DR 實作會使用上述策略的多個元素。首先，您必須建立高可用性 (HA) 架構，使用多個 AZ，如圖 23 所示。此架構會利用多站點主動/主動方法，因為 [Amazon EC2 執行個體](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html#concepts-availability-zones) 和 [Elastic Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html#availability-zones) 已在多個 AZ 中部署資源，主動處理請求。架構也會示範熱待命，其中如果主要 [Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html) 執行個體失敗 (或 AZ 本身失敗)，則待命執行個體會提升至主要執行個體。 

![\[顯示圖 23 的圖表：異地同步備份架構\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2022-03-31/framework/images/multi-az-architecture2.png)


 除了這種 HA 架構之外，您還需要新增執行工作負載所需之所有資料的備份。這對於受制於單一區域的資料尤其重要，例如 [Amazon EBS 磁碟區](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volumes.html) 或 [Amazon Redshift 叢集](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html)。如果 AZ 失敗，您需要將此資料還原至另一個 AZ。可能的話，您也應該將資料備份複製到另一個 AWS 區域，做為額外的保護層。 

 下列部落格文章中描述了一種不太常見的單一區域替代方法 (異地同步備份 DR)： [使用 Amazon Route 53 應用程式復原控制器建置高彈性應用程式，第 1 部分：單一區域堆疊](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-1-single-region-stack/)。在這裡，策略是盡可能地在 AZ 之間保持隔離，就像區域的操作方式一樣。使用這種替代策略，您可以選擇主動/主動或主動/被動方法。 

 注意：某些工作負載具有法規資料落地要求。如果在目前只有一個 AWS 區域的區域性中，這適用於您的工作負載，則多區域將不適合您的業務需求。異地同步備份策略提供良好的保護，可防範大部分災難。 

1.  **評估工作負載的資源，以及在容錯移轉之前 (在正常操作期間) 其哪個組態將位於復原區域中。** 

 對於基礎設施和 AWS 資源，使用基礎設施即程式碼，例如 [AWS CloudFormation](https://aws.amazon.com/cloudformation) ，或使用第三方工具，例如 Hashicorp Terraform。若要使用單一作業跨多個帳戶和區域進行部署，您可以使用 [AWS CloudFormation StackSets](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html)。對於多站點主動/主動和熱待命策略，您的復原區域中部署的基礎設施具有與您主要區域相同的資源。對於指示燈和暖待命策略，部署的基礎設施將需要額外的動作，才能為生產做好準備。使用 CloudFormation [參數](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/parameters-section-structure.html) 和 [條件式邏輯](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-conditions.html)，您可以使用單一範本控制部署的堆疊是主動還是待命。這類 CloudFormation 範本的範例包含在 [這篇部落格文章](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/)。 

 所有 DR 策略都要求在 AWS 區域內備份資料來源，然後將這些備份複製到復原區域。[AWS Backup](https://aws.amazon.com/backup/) 提供了一個集中檢視，您可以在其中設定、排定和監控這些資源的備份。對於指示燈、暖待命和多站點主動/主動，您還應該將資料從主要區域複寫到復原區域中的資料資源，例如 [Amazon Relational Database Service (Amazon RDS)](https://aws.amazon.com/rds) 資料庫執行個體或 [Amazon DynamoDB](https://aws.amazon.com/dynamodb) 資料表。因此，這些資料資源是即時的，而且可以為復原區域中的請求提供服務。 

 若要深入了解 AWS 服務如何跨區域操作，請參閱此部落格系列，其位於 [使用 AWS Services 建立多區域應用程式](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/)。 

1.  **確定並實作如何在需要時 (在災難事件期間) 使您的復原區域為容錯移轉做好準備。** 

 對於多站點主動/主動，容錯移轉意味著撤離一個區域，並依賴剩餘的主 動區域。通常，這些區域已準備好接受流量。對於指示燈和暖待命策略，您的復原動作將需要部署遺漏的資源，例如圖 20 中的 EC2 執行個體，以及任何其他遺漏的資源。 

 對於上述所有策略，您可能需要提升資料庫的唯讀執行個體，以變成主要讀取/寫入執行個體。 

 對於備份和還原，從備份還原資料會為該資料建立資源，例如 EBS 磁碟區、RDS 資料庫執行個體和 DynamoDB 資料表。您也需要還原基礎設施和部署程式碼。您可以使用 AWS Backup，還原復原區域中的資料。請參閱 [REL09-BP01 識別並備份所有需要備份的資料，或從來源複製資料](rel_backing_up_data_identified_backups_data.md) 以取得詳細資訊。重建基礎設施包括建立 EC2 執行個體之類的資源，還有 [Amazon Virtual Private Cloud (Amazon VPC))](https://aws.amazon.com/vpc)、子網路，以及所需的安全群組。您可以將大部分還原程序自動化。若要了解做法，請參閱 [這篇部落格文章](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-ii-backup-and-restore-with-rapid-recovery/)。 

1.  **確定並實作如何在需要時 (在災難事件期間) 將流量路由至容錯移轉。** 

 此容錯移轉作業可以自動或手動啟動。應謹慎使用根據運作狀態檢查或警示自動啟動的容錯移轉，因為不必要的容錯移轉 (誤報) 會產生非可用性和資料遺失等成本。因此通常使用手動啟動的容錯移轉。在此情況下，您仍應將容錯移轉的步驟自動化，讓手動啟動就像按下按鈕一樣簡易。 

 使用 AWS 服務時，有數個流量管理選項需要考慮。其中一個選項是使用 [Amazon Route 53](https://aws.amazon.com/route53)。使用 Amazon Route 53，您可以將一個或多個 AWS 區域中的 IP 端節與一個 Route 53 網域名稱建立關聯。若要實作手動啟動的容錯移轉，您可以使用 [Amazon Route 53 應用程式復原控制器](https://aws.amazon.com/route53/application-recovery-controller/)，其會提供一個高度可用的資料平面 API，將流量重新路由到復原區域。實作容錯移轉時，使用資料平面作業並避免控制平面作業，其描述在 [REL11-BP04 復原期間需使用資料平面，而非控制平面](rel_withstand_component_failures_avoid_control_plane.md)。 

 若要深入了解這個和其他選項，請參閱 [災難復原白皮書的這一節](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html#pilot-light)。 

1.  **設計您的工作負載將如何復原的計劃。** 

 復原是指在災難事件減弱後將工作負載操作回復到主要區域。將基礎設施和程式碼佈建到主要區域通常遵循最初使用的相同步驟，依賴基礎設施即程式碼和程式碼部署管道。復原的挑戰是還原資料存放區，並確保它們與操作中的復原區域保持一致。 

 在容錯移轉狀態下，復原區域中的資料庫是即時的並具有最新資料。後續目標是從復原區域重新同步到主要區域，確保它是最新的。 

 有些 AWS 服務將會自動執行此動作。如果使用 [Amazon DynamoDB 全域資料表](https://aws.amazon.com/dynamodb/global-tables/)，即使主要區域中的資料表變成無法可用，則當它重新上線時，DynamoDB 仍會繼續傳播任何擱置的寫入。如果使用 [Amazon Aurora 全球資料庫](https://aws.amazon.com/rds/aurora/global-database/) 和使用 [受管規劃容錯移轉](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-disaster-recovery.html#aurora-global-database-disaster-recovery.managed-failover)，則會維護 Aurora 全球資料庫的現有複寫拓撲。因此，主要區域中先前的讀取/寫入執行個體將成為複本，並從復原區域中接收更新。 

 如果這不是自動的，您將需要在主要區域中重建資料庫，做為復原區域中資料庫的複本。在許多情況下，這將涉及刪除舊的主要資料庫並建立新的複本。例如，如需如何在假設非計劃容錯移轉的情況下使用 Amazon Aurora *全球資料庫* 執行此動作的指示，請參閱此實驗室： [復原全球資料庫](https://awsauroralabsmy.com/global/failback/)。 

 容錯移轉後，如果您可以繼續在復原區域中執行，請考慮使其成為新的主要區域。您仍會執行上述所有步驟，使先前的主要區域成為復原區域。有些組織會執行排程輪換，定期 (例如每三個月) 交換其主要區域和復原區域。 

 容錯移轉和復原所需的所有步驟都應保持在可供所有團隊成員使用的程序手冊中，並定期進行審查。 

 **實作計劃的工作量**：高 

## 資源
<a name="resources"></a>

 **相關的最佳實務：** 
+ [REL09-BP01 識別並備份所有需要備份的資料，或從來源複製資料](rel_backing_up_data_identified_backups_data.md)
+ [REL11-BP04 復原期間需使用資料平面，而非控制平面](rel_withstand_component_failures_avoid_control_plane.md)
+  [REL13-BP01 定義停機和資料遺失的復原目標](rel_planning_for_recovery_objective_defined_recovery.md) 

 **相關文件：** 
+  [AWS 架構部落格：災難復原系列](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/) 
+  [AWS 上工作負載的災難復原：在雲端中復原 (AWS 白皮書)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html) 
+  [雲端中的災難復原選項](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html) 
+  [一小時建置無伺服器的多區域、主動-主動後端解決方案](https://read.acloud.guru/building-a-serverless-multi-region-active-active-backend-36f28bed4ecf) 
+  [多區域無伺服器後端 - 重新載入](https://medium.com/@adhorn/multi-region-serverless-backend-reloaded-1b887bc615c0) 
+  [RDS：跨區域複寫僅供讀取複本](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html#USER_ReadRepl.XRgn) 
+  [Route 53：設定 DNS 備援](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover-configuring.html) 
+  [S3：跨區域複寫](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr.html) 
+  [什麼是 AWS Backup？](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html) 
+  [什麼是 Route 53 應用程式復原控制器？](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html) 
+  [AWS 彈性災難復原](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html) 
+  [HashiCorp Terraform：入門 - AWS](https://learn.hashicorp.com/collections/terraform/aws-get-started) 
+  [APN 合作夥伴：可以幫助災難復原的合作夥伴](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery) 
+  [AWS Marketplace：可用於災難復原的產品](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery) 

 **相關影片：** 
+  [AWS 上工作負載的災難復原](https://www.youtube.com/watch?v=cJZw5mrxryA) 
+  [AWS re:Invent 2018：適用於多區域主動-主動應用程式的架構模式 (ARC209-R2)](https://youtu.be/2e29I3dA8o4) 
+  [AWS 彈性災難復原入門 \$1 Amazon Web Services](https://www.youtube.com/watch?v=GAMUCIJR5as) 

 **相關範例：** 
+  [AWS Well-Architected 實驗室 - 災難復原](https://wellarchitectedlabs.com/reliability/disaster-recovery/) - 說明 DR 系列的研討會系列