Azure 致力于确保 Azure 服务一直可用。 意外服务中断仍可能会发生，因此应制定灾难恢复 (DR) 计划来处理区域服务中断。 灾难恢复计划的一个重要组成部分是，准备在主终结点不可用时将故障转移到辅助终结点。 本文介绍灾难恢复 (DR) 和存储帐户故障转移所涉及的概念和过程。
重要
如果存储同步服务也进行故障转移，则 Azure 文件同步仅支持存储帐户故障转移。 这是因为 Azure 文件同步要求存储帐户和存储同步服务位于同一 Azure 区域。 如果仅对存储帐户进行故障转移，则在将存储同步服务故障转移到次要区域之前，同步和云分层操作将失败。 如果要故障转移包含 Azure 文件同步中用作云终结点的 Azure 文件共享的存储帐户，请参阅 Azure 文件同步灾难恢复最佳做法 和 Azure 文件同步服务器恢复。
| 管理模型 | 计费模式 | 媒体层 | 冗余 | 中小型企业 (SMB) | 网络文件系统(NFS) |
|---|---|---|---|---|---|
| Microsoft.Storage | 预配版本 v1 | SSD（高级） | 本地 (LRS) |  |
|
| Microsoft.Storage | 预配版本 v1 | SSD（高级） | 区域 (ZRS) | |
|
| Microsoft.Storage | 即用即付 | HDD（标准） | 本地 (LRS) | |
 |
| Microsoft.Storage | 即用即付 | HDD（标准） | 区域 (ZRS) | |
|
| Microsoft.Storage | 即用即付 | HDD（标准） | 异地 (GRS) | |
|
| Microsoft.Storage | 即用即付 | HDD（标准） | GeoZone （GZRS） | |
|
若要制定有效的灾难恢复策略，组织必须了解：
- 在发生中断时可以承受丢失多少数据（恢复点目标 (RPO)）
- 需要多长时间才能恢复业务功能和数据（恢复时间目标 (RTO)）
DR 的成本通常会随着 RPO/RTO 降低或为零而增加。 需要在灾难发生后几秒钟内启动并运行且无法承受任何数据丢失的公司将支付较高的灾难恢复费用，而 RPO/RTO 数值较高的公司将支付较少的费用。 Azure 提供的解决方案可以符合各种 RPO 和 RTO 要求。
Azure 文件存储提供了不同的冗余选项，以保护数据免受计划内和计划外事件的影响，这些事件包括暂时性硬件故障、网络和停电以及自然灾害。 所有 Azure 文件共享都可以使用本地冗余 (LRS) 或区域冗余存储 (ZRS)。 有关详细信息，请参阅 Azure 文件存储冗余。
Azure 文件存储支持配置了异地冗余存储 (GRS) 和异地区域冗余存储 (GZRS) 的 HDD 文件共享进行帐户故障转移，以防止区域性服务中断。 通过帐户故障转移，可以在主终结点不可用时为存储帐户启动故障转移过程。 故障转移将辅助终结点更新为，存储帐户的主终结点。 在故障转移完成后，客户端便可以开始对新的主终结点执行写入操作。
GRS 和 GZRS 仍存在数据丢失的风险，因为数据以异步方式复制到次要区域，这意味着在将写入主要区域的操作复制到次要区域之前存在延迟。 在服务中断的情况下，对主终结点执行、但尚未复制到辅助终结点的写入操作将会丢失。 这意味着如果主要区域不可恢复，影响主要区域的故障可能会导致数据丢失。 最近写入主要区域与上次写入次要区域之间的间隔是 RPO。 Azure 文件存储的 RPO 通常为 15 分钟或更短，但目前没有 SLA 规定将数据复制到次要区域所需的时间。
重要
SSD 文件共享不支持 GRS/GZRS。 但是，可以在两个 Azure 文件共享之间同步以实现地理冗余。
请务必从一开始就设计高可用性应用程序。 有关设计应用程序和计划灾难恢复方面的指导，请参阅以下 Azure 资源：
- 设计适用于 Azure 的可复原应用程序：概述了在 Azure 中生成高可用性应用程序的关键概念。
- 复原能力清单：用于验证应用程序是否实现高可用性最佳设计做法的清单。
- 使用异地冗余设计高可用性应用程序：利用 SMB 文件共享的地理冗余存储优势构建应用程序的设计指南。
我们还建议将应用程序设计为可以应对可能出现的写入故障。 应用程序应公开写入故障，以提醒你主要区域可能存在服务中断。
最佳做法是，将应用程序设计为通过检查上次同步时间属性来评估预期数据丢失。 例如，若要记录所有写入操作，可以比较上次写入操作时间与上次同步时间，以确定哪些写入操作尚未同步到次要区域。
你可以订阅 Azure 服务运行状况仪表板，以跟踪 Azure 文件存储和其他 Azure 服务的运行状况和状态。
借助客户管理的帐户故障转移，可以在主要区域因任何原因而不可用时，将整个存储帐户故障转移到次要区域。 如果你强制故障转移到次要区域，客户端可以在故障转移完成后开始向辅助终结点写入数据。 故障转移通常需要大约一小时才能完成。 建议在启动帐户故障转移之前尽可能暂停你的工作负载。
若要详细了解如何启动帐户故障转移，请参阅启动帐户故障转移。
在正常情况下，客户端将数据写入主要区域中的存储帐户，并将此数据异步复制到次要区域。 下图展示了主要区域可用时的场景：
如果主终结点因任何原因而不可用，客户端无法再向存储帐户写入数据。 下图展示了主节点不可用但尚未执行恢复时的场景：
客户启动帐户故障转移到辅助终结点。 故障转移过程更新 Azure 存储提供的 DNS 条目，这样辅助终结点就会成为存储帐户的新主终结点，如下图所示：
在 DNS 条目已更新且请求定向到新的主终结点后，异地冗余帐户便会恢复写入访问权限。 在故障转移完成后，现有存储服务终结点保持不变。 故障转移时不会保留文件句柄和租用，因此客户端必须卸载并重新装载文件共享。
重要
在故障转移完成后，存储帐户被配置为在新的主终结点或区域中保持本地冗余。 若要继续复制到新的辅助终结点，请将帐户重新配置为使用异地冗余。
请记住，通过转换本地冗余存储帐户来使用异地冗余会产生成本和时间。 有关详细信息，请参阅故障转移的时间和成本。
警告
帐户故障转移通常涉及一些数据丢失。 请务必了解启动帐户故障转移的影响。
由于数据从主要区域异步写入到次要区域，因此，如果主要区域不可用，则最近的写入可能尚未复制到次要区域。
如果强制执行故障转移，主要区域中的所有数据就会在次要区域成为新的主要区域时丢失。 故障转移后，新的主要区域配置为本地冗余。
当故障转移发生时，将保留已复制到次要区域的所有数据。 不过，任何写入主要区域、但尚未复制到次要区域的数据会永久丢失。
“上次同步时间 (LST)”属性表示，最近一次保证已将主要区域中的数据写入次要区域的时间。 上次同步时间之前写入的所有数据都已复制到次要区域中，而在上次同步时间之后写入的数据则可能尚未写入次要区域并发生丢失。 在发生服务中断时，使用此属性可估计启动帐户故障转移可能会造成的数据丢失量。
为了确保发生故障转移时文件共享处于一致状态，系统会每隔 15 分钟在主要区域中创建一次系统快照，并将其复制到次要区域。 当次要区域发生故障转移时，共享状态将基于次要区域中的最新系统快照。 如果主要区域发生故障，次要区域可能会落后于主要区域，因为对主要区域的所有写入有可能尚未复制到次要区域。 由于地理滞后或其他问题，次要区域中的最新系统快照可能会滞后 15 分钟。
在 LST 之前写入到主要区域的所有写入操作已成功复制到次要区域，这意味着，可以从次要区域读取这些操作。 在上次同步时间之后写入主要区域的任何写入操作可能已复制到次要区域，也可能未复制到次要区域，这意味着可能不适合对它们执行读取操作。
你可以使用 Azure PowerShell、Azure CLI 或客户端库查询“上次同步时间”属性的值。 “上次同步时间”属性是一个 GMT 日期/时间值。 有关详细信息，请参阅检查存储帐户的“上次同步时间”属性。
如前所述，从主要区域故障转移到次要区域后，存储帐户被配置为在新的主要区域中本地冗余。 然后，可以在新的主要区域配置帐户以实现异地冗余。 如果帐户在故障转移完成后配置为使用异地冗余，新的主要区域就会立即开始将数据复制到新的次要区域（在原始故障转移发生前为主要区域）。 但是，将新的主要区域中的现有数据完全复制到新的次要区域可能需要一段时间才能完成。
为存储帐户重新配置异地冗余后，可以启动从新的主要区域故障回复到新的次要区域。 在这种情况下，故障转移前的原始主要区域再次成为主要区域，并根据原始主要配置是 GRS 还是 GZRS 配置为本地冗余或区域冗余。 在故障恢复期间，故障转移后主要区域（原始次要区域）中的所有数据都将丢失。 如果在故障回复前存储帐户中的大部分数据都尚未复制到新的次要区域，可能会丢失大量数据。
为了避免重大数据丢失，请在恢复到原状态前检查“上次同步时间”属性的值。 若要评估预期的数据丢失，请比较上次同步时间与数据上次写入新的主节点的时间。
故障回复操作后，可再次将新的主要区域配置为异地冗余。 如果原始主要区域配置了 LRS，可以将其配置为 GRS。 如果原始主要区域配置为 ZRS，则可以将其配置为 GZRS。 有关其他选项，请参阅更改存储帐户的复制方式。
可以从 Azure 门户、PowerShell、Azure CLI 或 Azure 存储资源提供程序 API 启动帐户故障转移。 若要详细了解如何启动故障转移，请参阅启动帐户故障转移。
在由于重大灾难而导致区域丢失的极端情况下，Azure 可能会启动区域故障转移。 在此情况下，你不需要采取任何操作。 在 Azure 托管的故障转移完成之前，你对存储帐户不拥有写入访问权限。