何謂災害復原？
災害是單一重大事件，其影響範圍和延續時間遠超過應用程式可透過其設計的高可用性部分來減輕的程度。 災害復原 (DR)是指從重大影響事件中復原，例如自然災害或不成功的部署 (導致停機和資料遺失)。 無論原因為何，解決災害的最佳辦法是定義完善且經過測試的 DR 方案，以及主動支援 DR 的應用程式設計。
復原目標
完整的 DR 方案必須為應用程式所實作的每個流程指定下列重要商務需求：
復原點目標 (RPO) 是可接受資料遺失的持續時間上限。 RPO 是以時間單位來測量，而不是時間量，例如「30 分鐘的資料」或「四小時的資料」。RPO 牽涉到的是資料遺失 (而不是資料竊取) 的限制和復原。
復原時間目標 (RTO) 是可接受的停機持續時間上限，您可以在規格中定義「停機」。 例如，若發生災害時可接受的停機持續時間是八小時，則 RTO 就是八小時。
藉由檢查災害案例風險和潛在的復原策略，應用程式實作的每個主要程序或工作負載都應該有個別的 RPO 和 RTO 值。 指定 RPO 和 RTO 的程序會因為您獨特的商務考慮 (成本、影響、資料遺失等)，有效地為應用程式建立 DR 需求。
為災害復原而設計
災害復原不是自動功能，但必須經過設計、建置和測試。 為了支援穩固的 DR 策略，您必須從頭開始建置具有 DR 考量的應用程式。 Azure 提供服務、功能和指引，協助您在建立應用程式時支援DR。
資料復原
在災害期間，有兩種還原資料的主要方法：備份和複寫。
備份可將資料還原至特定的時間點。 使用備份，您可以提供簡單、安全且符合成本效益的解決方案，將您的資料備份和復原到 Microsoft Azure 雲端。 使用 Azure 備份來建立長時間存留的唯讀資料快照集，以便用於復原。
資料複寫可在多個資料存放區複本中建立即時或近乎即時的即時資料複本，同時考慮到最少的資料遺失。 複寫的目標是要以最低限度的延遲維持複本同步，同時保有應用程式回應性。 大多數功能齊全的資料庫系統和其他資料儲存體產品與服務，都會因其運作和效能需求，而將某種類型的複寫當成緊密整合的功能來提供。 其中一個範例是異地備援儲存體 (GRS)。
複寫設計種類眾多，並且在資料一致性、效能和成本方面各有其不同的優先考量。
「主動」複寫需要同時對多個複本執行更新，可確保一致性，但輸送量較高。
「被動」複寫會在背景中執行同步處理，使應用程式效能不再受限於複寫，但會增加 RPO。
「主動-主動」或「多重主機」複寫可同時使用多個複本，以達到負載平衡的效益，但相對會犧牲資料一致性。
「主動-被動」複寫會將複本僅保留給容錯移轉期間的即時使用。
注意
大部分功能完整的資料庫系統及其他資料儲存體產品和服務都因為其功能與效能需求，而包含某種複寫功能，例如異地備援儲存體 (GRS)。
建置彈性應用程式
災害的狀況通常也會導致停機，無論是因為網路連線有問題、資料中心中斷、虛擬機器 (VM) 受損，還是軟體部署損毀，都是如此。 在大部分情況下，應用程式復原涉及容錯移轉至個別的工作部署。 因此，在發生大規模災害時，可能需要在另一個 Azure 區域中復原程序。 其他考量可能包括：復原位置、複寫的環境數目，以及如何維護這些環境。
視應用程式設計而定，您可以使用數種不同的策略和 Azure 功能，例如 Azure Site Recovery，以改善應用程式在災害後程序復原的支援。
服務特定的災害復原功能
在 Azure 平台即服務 (PaaS) 供應項目上執行的大部分服務 (例如 Azure App Service) 都提供支援 DR 的功能和指引。 在某些情況下，您可以使用服務特定的功能來支援快速復原。 例如，Azure SQL Server 支援異地複寫，以便在另一個區域中快速還原服務。 Azure App Service 具有備份與還原功能，而文件中包含使用 Azure 流量管理員來支援將流量路由傳送到次要區域的指引。