以下内容涵盖多种不同类型的灾难情况。数据中心故障不是应用程序范围内发生故障的唯一原因。设计不良或管理错误也会导致中断。请在恢复计划的设计和测试阶段设想可能导致故障的原因，这样做很重要。一个好的计划可充分利用 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 数据中心。如同任何其他故障一样，你可能决定在这种情况下甘冒停机时间的风险。跨越多个数据中心的广泛故障应比涉及依赖服务或单个数据中心的孤立故障少见得多。但是，对某些任务关键型应用程序而言，你可能决定还必须为此方案制定备份计划。针对此事件的计划可能包括故障转移到备选云或混合本地和云解决方案中的服务。