以下內容涵蓋多種不同類型的災難情況。數據中心故障不是應用程序范圍內發生故障的唯一原因。設計不良或管理錯誤也會導致中斷。請在恢復計划的設計和測試階段設想可能導致故障的原因，這樣做很重要。一個好的計划可充分利用 Azure 功能，並通過應用程序特有的策略強化這些功能。由應用程序的重要性、RPO 和 RTO 規定所選的響應。
如前所述，Azure 結構控制器會自動處理因主機虛擬機中的底層硬件或操作系統軟件引起的故障。Azure 會在正常運行的服務器上創建新的角色實例，然后將其添加到負載平衡器輪換中。如果角色實例數大於一，Azure 會將處理過程切換到其他正在運行的角色實例，同時替換發生故障的節點。
但是，還會發生與任何硬件或操作系統故障無關的嚴重應用程序錯誤。應用程序可能因邏輯錯誤或數據完整性問題導致的災難性異常而發生故障。必須在代碼中加入足夠的遙測，以使監視系統可檢測到故障情況並通知應用程序管理員。完全了解災難恢復過程的管理員可決定調用故障轉移過程，也可以簡單接受可用性中斷以解決關鍵性錯誤。
Azure 自動將你的 Azure SQL Database 和 Azure 存儲數據在同一數據中心內的不同容錯域中冗余地存儲三次。如果使用異地復制，則再將這些數據在另一個數據中心內存儲三次。但是，如果用戶或應用程序損壞了主副本中的數據，則會將損壞情況迅速復制到其他副本。不幸的是，這將產生三份損壞的數據。
若要應對可能的數據損壞，將需要管理你自己的備份，以保持事務一致性。你可以將備份存儲在 Azure 中或存儲在本地，具體取決於你的業務需求或治理監管。有關詳細信息，請參閱災難恢復的數據策略部分。
當 Azure 網絡的某些部分中斷時，你可能無法訪問應用程序或數據。如果一個或多個角色實例因網絡問題而不可用，則 Azure 將利用應用程序剩余的可用實例。如果應用程序因 Azure 網絡中斷而無法訪問其數據，則可以通過使用緩存數據在本地以降級模式運行，因此需要在應用程序中為在降級模式下運行制定災難恢復策略。某些應用程序可能做不到這一點。另一個選項是將數據存儲在備用位置，直到連接恢復。如果降級模式不是好辦法，則剩余的選項為產生應用程序停機時間或故障轉移到備用數據中心。設計在降級模式下運行應用程序多出於業務決策而非技術決策。應用程序功能降級部分深入討論了這一問題。
Azure 提供的許多服務可能會定期停機。設想 Azure Shared Caching 為例。這項多租區服務向應用程序提供緩存功能。設想如果依賴服務不可用，應用程序中將發生什么，這樣做很重要。此方案在許多方面與網絡中斷方案類似，但是，單獨考量每一項服務有望改進整個計划。
例如，通過 Caching，多租區共享緩存模型有一個相對較新的備選項。通過角色上的 Azure Caching，可從雲服務部署中緩存到應用程序。（建議今后也這樣使用 Caching）。雖然它有一個限制，只能從單個部署中訪問它，但有可能使災難恢復獲益。首先，服務現在運行在你的部署本地的角色上。因此，在雲服務的總體管理過程中，可更好地監視和管理緩存的狀態。但是，這種類型的緩存也公布了新功能。其中一個新功能是緩存數據的高可用性。此功能通過在其他節點上保留重復的副本，幫助在一個節點發生故障時保留緩存數據。請注意，高可用性會降低吞吐量並增大延遲，因為需要在寫入時更新輔助副本。它還會將每項使用的內存量加倍，因此要為此做好規划。這個具體的示例表明，每項依賴服務都可能具有提高總體可用性和幫助抵御災難性故障的能力。
通過每個依賴服務，應了解可能產生的總中斷數。在 Caching 的示例中，或許可以直接從數據庫訪問數據，直到 Caching 功能恢復為止。在性能方面，這將是降級模式，但可提供數據方面的完整功能。
以前的故障主要還是可在同一 Azure 數據中心內應對的故障。但是，還必須為整個數據中心發生故障的可能性做好准備。當數據中心發生故障時，數據的本地冗余副本不可用。如果啟用了異地復制，則在異地數據中心內另有 Blob 和表的 3 個副本。當 Microsoft 聲稱數據中心發生故障時，Azure 會將所有 DNS 條目將重新映射到異地復制的數據中心。注意，你對此過程無任何控制權，並且僅對整個數據中心范圍的故障進行此過程。因此，還必須依靠應用程序特有的其他備份方法才能達到最高級別的可用性。有關詳細信息，請參閱災難恢復的數據策略部分。
在災難規划中，必須考慮到所有可能發生的災難情況。最嚴重的一個故障將同時涉及所有 Azure 數據中心。如同任何其他故障一樣，你可能決定在這種情況下甘冒停機時間的風險。跨越多個數據中心的廣泛故障應比涉及依賴服務或單個數據中心的孤立故障少見得多。但是，對某些任務關鍵型應用程序而言，你可能決定還必須為此方案制定備份計划。針對此事件的計划可能包括故障轉移到備選雲或混合本地和雲解決方案中的服務。