你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
Azure 存储灾难恢复计划和故障转移
Microsoft 致力于确保 Azure 服务一直可用。 但偶尔可能发生计划外服务中断。 良好的灾难恢复计划的关键组成部分包括：
本文介绍可用于异地冗余存储帐户的选项，并提供有关开发高度可用应用程序和测试灾难恢复计划的建议。
选择正确的冗余选项
Azure 存储可维护存储帐户的多个副本，以确保即使遇到故障也能满足可用性和持久性目标。 复制数据的方式提供了不同的保护级别。 每个选项都有其自己的优势，因此选择的选项取决于应用程序所需的复原能力级别。
本地冗余存储 (LRS) 是成本最低的冗余选项，可在单个数据中心内自动存储和复制存储帐户的三个副本。 尽管 LRS 可保护数据免受服务器机架和驱动器故障的影响，但它不会考虑数据中心内的火灾或洪水等灾难。 如果发生此类灾难，配置为使用 LRS 的存储帐户的所有副本可能会丢失或无法恢复。
相比之下，区域冗余存储 (ZRS) 将保留存储帐户的副本，并将其复制到同一区域中三个单独的可用性区域中的每一个。 有关可用性区域的详细信息，请参阅 Azure 可用性区域。
异地冗余存储和故障转移
异地冗余存储 (GRS)、异地区域冗余存储 (GZRS) 和读取访问异地区域冗余存储 (RA-GZRS) 都是异地冗余存储选项的示例。 配置为使用异地冗余存储（GRS、GZRS 和 RA-GZRS）时，Azure 会将数据异步复制到次要地理区域。 这些地区位于数百英里甚至数千英里之外。 借助此级别的冗余助，可以在整个主要区域发生中断时恢复数据。
与 LRS 和 ZRS 不同，异地冗余存储还支持在主要区域发生中断时向次要区域进行计划外故障转移。 在故障转移过程中，存储帐户服务终结点的 DNS（域名系统）条目会自动更新，以便次要区域的终结点成为新的主终结点。 在计划外故障转移完成后，客户端便可以开始对新的主终结点执行写入操作。
读取访问异地冗余存储 (RA-GRS) 或读取访问异地区域冗余存储 (RA-GZRS) 也会提供异地冗余存储，但提供了对次要终结点进行读取访问的额外优点。 这些选项非常适合为高可用性业务关键型应用程序设计的应用程序。 如果主终结点遇到服务中断，则配置为对次要区域进行读取访问的应用程序可以继续运行。 Microsoft 建议使用 RA-GZRS 实现存储帐户的最大可用性和持久性。
有关 Azure 存储的冗余的详细信息，请参阅 Azure 存储冗余。
规划故障转移
Azure 存储帐户支持三种类型的故障转移：
- 客户管理的计划的故障转移（预览版） - 客户可以管理存储帐户故障转移来测试其灾难恢复计划。
- 客户管理的（计划外）故障转移 - 客户可以管理发生意外服务中断时的存储帐户故障转移。
- Microsoft 托管的故障转移 - 仅当主要区域中发生严重灾难时才可能由 Microsoft 启动。 1,2
1 无法为单个存储帐户、订阅或租户启动 Microsoft 托管的故障转移。 有关详细信息，请参阅 Microsoft 托管的故障转移。
2 使用客户管理的故障转移选项来开发、测试和实现灾难恢复计划。 不要依赖于 Microsoft 托管的故障转移，它仅用于极端情况。
每种类型的故障转移都有一组唯一的用例、相应的数据丢失预期，并支持启用了分层命名空间的帐户 (Azure Data Lake Storage)。 下表总结了每种故障转移类型的这些方面：
| 类型 | 故障转移范围 | 用例 | 预期数据丢失 | 支持分层命名空间 (HNS)。 |
|---|---|---|---|---|
| 客户管理的计划的故障转移（预览版） | 存储帐户 | 主要区域和次要区域的存储服务终结点已可用，并且你希望执行灾难恢复测试。 主要区域的存储服务终结点可用，但另一个服务阻碍了工作负荷正常运行。 主动为可能会影响一个地区的大规模灾难做准备，如飓风。 |
否 | 是 （在预览版中） |
| 客户管理的（计划外）故障转移 | 存储帐户 | 主要区域的存储服务终结点变得不可用，但次要区域可用。 你收到了一份 Azure 公告，其中 Microsoft 建议你执行可能受中断影响的存储帐户的故障转移操作。 |
是 | 是 （在预览版中） |
| 由 Microsoft 管理 | 整个区域 | 由于发生重大灾难，主要区域不可用，但次要区域可用。 | 是 | 是 |
下表比较了每种故障转移类型后存储帐户的冗余状态：
| 故障转移的结果... | 客户管理的计划的故障转移（预览版） | 客户管理的（计划外）故障转移 |
|---|---|---|
| ...次要区域 | 次要区域将成为新的主要区域 | 次要区域将成为新的主要区域 |
| ...原始主要区域 | 原始主要区域将成为新的次要区域 | 删除原始主要区域中的数据副本 |
| ...帐户冗余配置 | 存储帐户将转换为 LRS | 存储帐户转换为 LRS |
| ...异地冗余配置 | 保留异地冗余 | 异地冗余丢失 |
下表总结了每种类型故障转移和故障回复过程的每个阶段生成的冗余配置：
| 原始 配置 |
之后 故障转移 |
重新启用后 异地冗余 |
之后 故障回复 |
重新启用后 异地冗余 |
|---|---|---|---|---|
| 客户管理的计划的故障转移 | ||||
| GRS | GRS | n/a 1 | GRS | n/a 1 |
| GZRS | GRS | n/a 1 | GZRS | n/a 1 |
| 客户管理的（计划外）故障转移 | ||||
| GRS | LRS | GRS | LRS | GRS |
| GZRS | LRS | GRS | ZRS | GZRS |
1 在计划的故障转移期间会保留异地冗余，无需手动重新配置。
客户管理的计划的故障转移（预览版）
计划的故障转移可用于多种场景，包括计划灾难恢复测试、应对大规模灾难的主动方法或从非存储相关中断中恢复。
在计划的故障转移过程中，将交换主要区域和次要区域。 原始主要区域将降级，成为新的次要区域。 同时，原始次要区域将升级，成为新的主要区域。 故障转移完成后，用户可以继续访问新主要区域中的数据，管理员可以验证其灾难恢复计划。 存储帐户必须同时在主要区域和次要区域中可用，然后才能启动计划的故障转移。
只要主要区域和次要区域在整个过程中可用，计划的故障转移和故障回复过程中应不会丢失数据。 有关详细信息，请参阅预测数据丢失和不一致部分。
要了解这种类型的故障转移对用户和应用程序的影响，了解计划的故障转移和故障回复过程每个步骤中发生的情况会很有帮助。 有关此过程工作原理的详细信息，请参阅客户管理的（计划的）故障转移的工作原理。
重要
客户管理的计划的故障转移目前处于预览状态，限制为以下区域：
- 法国中部
- 法国南部
- 印度中部
- 印度西部
- 东亚
- 东南亚
有关 beta 版本、预览版或尚未正式发布的版本的 Azure 功能所适用的法律条款，请参阅 Microsoft Azure 预览版的补充使用条款。
重要
计划的故障转移后，存储帐户的上次同步时间 (LST) 值可能会过时，或者在 Azure 文件存储数据存在时报告为 NULL。
在存储帐户的次要区域中定期创建系统快照，以在故障转移和故障回复期间保持使用一致的恢复点。 启动客户管理的计划的故障转移会导致原始主要区域成为新的次要区域。 在某些情况下，在计划的故障转移完成后，新的次要区域中没有系统快照可用，导致帐户的总体 LST 值显示为过时或显示为 Null。
由于创建、修改或删除对象等用户活动可以触发创建快照，因此在计划的故障转移后发生这些活动的任何帐户都不需要额外的注意。 但是，在触发创建系统快照之前，没有快照或用户活动的帐户可能会继续显示 Null LST 值。
如有必要，请为存储帐户中的每个共享执行下列活动之一来触发创建快照的操作。 完成后，帐户应在 30 分钟内显示有效的 LST 值。
- 装载共享，然后打开任何文件进行读取。
- 将测试文件或示例文件上传到共享。
客户管理的（计划外）故障转移
如果存储帐户中存储服务的数据终结点在主要区域中不可用，则可以发起计划外故障转移到次要区域。 故障转移完成后，次要区域将成为新的主要区域，用户可以继续在那里访问数据。
要了解这种类型的故障转移对用户和应用程序的影响，了解计划外故障转移和故障回复过程每个步骤中发生的情况会很有帮助。 有关此过程工作原理的详细信息，请参阅客户管理的（计划外）故障转移的工作原理。
Microsoft 托管的故障转移
Microsoft 可能会在极端情况下启动区域故障转移，例如影响整个地理区域的灾难性灾害。 在这些事件期间，无需执行任何操作。 如果存储帐户配置为 RA-GRS 或 RA-GZRS，则应用程序可以在 Microsoft 管理的故障转移期间从次要区域读取。 但在故障转移过程完成之前，你没有对存储帐户的写入访问权限。
重要
使用客户管理的故障转移选项来开发、测试和实现灾难恢复计划。 不要依赖于 Microsoft 托管的故障转移，它仅用于极端情况。 将为整个物理单元（例如区域或数据中心）启动 Microsoft 托管的故障转移。 它无法为单个存储帐户、订阅或租户启动。 如果需要选择性故障转移单个存储帐户，请使用客户管理的计划的故障转移。
预计数据丢失和不一致
注意
客户管理的（计划外）故障转移通常涉及一定数量的数据丢失，还可能导致文件和数据不一致。 在灾难恢复计划中，请务必在启动数据之前考虑帐户故障转移对数据的影响。
因为数据是从主要区域异步写入次要区域，所以在写入主要区域的数据复制到次要区域前始终存在延迟。 如果主要区域不可用，则可能尚未将最近的写入复制到次要区域。
如果发生计划外故障转移，主要区域中的所有数据就会在次要区域成为新的主要区域时丢失。 当故障转移发生时，将保留已复制到次要区域的所有数据。 但写入到次要区域中尚不存在的主数据库的任何数据将会永久丢失。
新的主要区域在故障转移后配置为本地冗余 (LRS)。
如果存储帐户启用了以下一个或多个功能，则也可能遇到文件或数据不一致：
上次同步时间
“上次同步时间”属性指示最近一次将主要区域中的数据写入次要区域的时间。 对于具有分层命名空间的帐户，相同的“上次同步时间”属性也适用于由分层命名空间（包括访问控制列表 ACL）管理的元数据。 在上次同步时间之前写入的所有数据和元数据可用于辅助区域。 相比之下，上次同步时间之后写入的数据和元数据可能尚未复制到辅助区域，并且可能会丢失。 在服务中断期间，使用此属性可估计启动帐户故障转移时可能会造成的数据丢失量。
最佳做法是将应用程序设计为可以使用“上次同步时间”来评估预期数据丢失。 例如，通过记录所有写入操作，可以将上次写入操作的时间与上次同步时间进行比较。 使用此方法，你能够确定哪些写入尚未同步到辅助区域，并且存在丢失的危险。
如需详细了解如何检查“上次同步时间”属性，请参阅检查存储帐户的“上次同步时间”属性。
Azure Data Lake Storage 的文件一致性
启用了分层命名空间 (Azure Data Lake Storage) 的存储帐户复制在文件级别进行。 由于复制在此级别发生，因此主要区域中的中断可能会阻止容器或目录中的一些文件成功复制到次要区域。 无法保证在存储帐户故障转移后容器或目录中所有文件的一致性。
更改源和 blob 数据不一致
对启用了更改源的存储帐户进行客户管理的（计划外）故障转移可能会导致更改源日志与 blob 数据和/或元数据之间不一致。 这种不一致可能是主要区域和次要区域之间更改日志更新和数据复制的异步性质造成的。 可以通过采取以下预防措施来避免不一致：
- 确保所有日志记录都刷新到日志文件。
- 确保所有存储数据都从主区域复制到了次要区域。
有关更改源的详细信息，请参阅更改源的工作原理。
请记住，其他存储帐户功能也需要启用更改源。 这些功能包括 Azure Blob 存储的运行备份、对象复制和块 Blob 的时间点还原。
时间点还原不一致
包含块 blob 的常规用途 v2 标准层存储帐户支持客户管理的故障转移。 然而，对存储帐户执行客户管理的故障转移会为该帐户重置尽可能早的还原点。 块 blob 的时间点还原数据仅在故障转移完成时间之前保持一致。 因此，只能将块 blob 还原到不早于故障转移完成时间的时间点。 可以在 Azure 门户中存储帐户的“冗余”选项卡中查看故障转移完成时间。
故障转移的时间和成本
客户管理的故障转移在启动后完成所用的时间可能会有所不同，但通常不到一小时。
客户管理的计划的故障转移不会在故障转移和后续故障回复后丢失其异地冗余，但客户管理的计划外故障转移会。
启动客户管理的计划外故障转移会自动将存储帐户转换为新主要区域中的本地冗余存储 (LRS)，并删除原始主要区域中的存储帐户。
可以为帐户重新启用异地冗余存储 (GRS) 或读取访问异地冗余存储 (RA-GRS)，但将数据重新复制到新的次要区域会产生费用。 此外外，需要先将任何已存档 blob 解除冻结到联机层，然后才能将帐户配置为使用异地冗余。 这种解除冻结也会产生额外的费用。 有关定价的详细信息，请参阅：
在你为存储帐户重新启用 GRS 后，Microsoft 便会开始将帐户中的数据复制到新的次要区域。 完成复制所需的时间取决于多个因素。 这些因素包括：
- 存储帐户中对象的数量和大小。 复制许多小型对象所需的时间可能比复制较少的大对象要长。
- 可用于后台复制的资源，例如 CPU、内存、磁盘和 WAN 容量。 实时流量优先于异地复制。
- 每个 Blob 的快照数（如果适用）。
- 如果存储帐户包含表，则需要数据分区策略。 复制过程不能扩展到超过所用分区键数量的地步。
支持的存储帐户类型
所有异地冗余套餐都支持 Microsoft 托管的故障转移。 此外，某些帐户类型支持客户管理的帐户故障转移，如下表所示：
| 故障转移类型 | GRS/RA-GRS | GZRS/RA-GZRS |
|---|---|---|
| 客户管理的计划的故障转移（预览版） | 常规用途 v2 帐户 常规用途 v1 帐户 旧 Blob 存储帐户 |
常规用途 v2 帐户 |
| 客户管理的（计划外）故障转移 | 常规用途 v2 帐户 常规用途 v1 帐户 旧 Blob 存储帐户 |
常规用途 v2 帐户 |
| Microsoft 托管的故障转移 | 所有帐户类型 | 常规用途 v2 帐户 |
经典存储帐户
重要
只有使用 Azure 资源管理器 (ARM) 部署模型部署的存储账户才支持客户管理的故障转移。 不支持 Azure Service Manager (ASM) 部署模型（也称为经典）。 若要使经典存储帐户符合客户管理的帐户故障转移的条件，必须先将其迁移到 ARM 模型。 必须可以访问存储帐户来执行升级，因此主要区域当前不能处于失败状态。
在发生影响主要区域的灾难期间，Microsoft 将会管理经典存储帐户的故障转移。 有关详细信息，请参阅 Microsoft 托管的故障转移。
分层命名空间 (HNS)
重要
对于已启用 Azure Data Lake Storage Gen2 的帐户，由客户管理的（计划外）故障转移目前为预览版，在所有公共 GRS/GZRS 区域中受支持。
有关 beta 版本、预览版或尚未正式发布的版本的 Azure 功能所适用的法律条款，请参阅 Microsoft Azure 预览版的补充使用条款。
重要
对于已启用 SSH 文件传输协议 (SFTP) 的帐户，客户管理的（计划外）故障转移目前为预览版，仅在以下区域受支持：
- （亚太）印度中部
- （亚太）- 东南亚
- （欧洲）欧洲北部
- （欧洲）瑞士北部
- （欧洲）瑞士西部
- （欧洲）西欧
- （北美）加拿大中部
- （北美）美国东部 2
- （北美）美国中南部
有关 beta 版本、预览版或尚未正式发布的版本的 Azure 功能所适用的法律条款，请参阅 Microsoft Azure 预览版的补充使用条款。
如果发生影响主要区域的重大灾难，Microsoft 将管理具有分层命名空间的帐户的故障转移。 有关详细信息，请参阅 Microsoft 托管的故障转移。
不支持的功能和服务
客户管理的故障转移不支持以下功能和服务：
- Azure 文件同步不支持客户管理的帐户故障转移。 不应对用作 Azure 文件同步云终结点的存储帐户进行故障转移。 故障转移会中断文件同步，并可能导致新分层文件意外数据丢失。 有关详细信息，请参阅使用 Azure 文件同步进行灾难恢复的最佳做法。
- 无法对包含高级块 Blob 的存储帐户执行故障转移。 支持高级块 Blob 的存储帐户暂不支持异地冗余。
- 对象复制策略中的源帐户或目标帐户均不支持客户管理的故障转移。
- 存储帐户故障转移不支持网络文件系统 (NFS) 3.0 (NFSv3)。 无法创建为启用了 NFSv3 的异地冗余配置的存储帐户。
下表可用于参考功能支持。
| 计划的故障转移 | 计划外故障转移 | |
|---|---|---|
| Azure Data Lake 存储 | 支持（预览） | 支持（预览） |
| 更改源 | 不支持 | 支持 |
| 对象复制 | 不支持 | 不支持 |
| SFTP | 支持（预览） | 支持（预览） |
| NFSv3 | GRS 不受支持 | GRS 不受支持 |
| 存储操作 | 支持1 | 支持1 |
| 时间点还原 (PITR) | 不支持 | 支持 |
1 如果启动了客户管理的计划内或计划外故障转移，则存储任务在故障回复到原始主要区域之前无法对帐户进行操作。 了解详细信息。
故障转移不适用于帐户迁移
存储帐户故障转移是一种临时解决方案，用于部署和测试灾难恢复 (DR) 计划，或从服务中断中恢复。 不应将故障转移用作数据迁移策略的一部分。 有关如何迁移存储帐户的信息，请参阅 Azure 存储迁移概述。
包含存档 Blob 的存储帐户
包含已存档 blob 的存储帐户支持帐户故障转移。 但在客户管理的故障转移完成后，必须先将所有已存档 Blob 解除冻结到联机层，然后才能将帐户配置为使用异地冗余。
存储资源提供程序
Microsoft 提供两个 REST API 用于处理 Azure 存储资源。 这些 API 构成了可对 Azure 存储执行的所有操作的基础。 使用 Azure 存储 REST API 可以处理存储帐户中的数据，包括 Blob、队列、文件和表数据。 利用 Azure 存储资源提供程序 REST API，可以管理存储帐户和相关的资源。
故障转移完成后，客户端可再次读取并写入新的主要区域中的 Azure 存储数据。 但是，Azure 存储资源提供程序不会进行故障转移，因此资源管理操作仍必须在主要区域中进行。 如果主要区域不可用，则无法对存储帐户执行管理操作。
由于 Azure 存储资源提供程序不会进行故障转移，因此在故障转移完成后，Location 属性将返回原始主位置。
Azure 虚拟机
在帐户故障转移过程中，Azure 虚拟机 (VM) 不会故障转移。 故障转移完成后，需要重新创建已故障转移到次要区域以响应中断的任何 VM。 帐户故障转移可能会导致虚拟机 (VM) 关闭时临时磁盘中存储的数据丢失。 Microsoft 建议使用以下特定于 Azure 中虚拟机的高可用性和灾难恢复指南。
Azure 非托管磁盘
非托管磁盘在 Azure 存储中存储为页 blob。 如果 VM 在 Azure 中运行，任何附加到 VM 的非托管磁盘都会被租用。 如果 Blob 上有租用，便无法继续帐户故障转移。 必须先关闭磁盘盘，然后才能在包含附加到 Azure VM 的非托管磁盘的帐户上启动故障转移。 因此，Microsoft 建议的最佳做法包括将任何非托管磁盘转换为托管磁盘。
要对包含非托管磁盘的帐户执行故障转移，请执行以下步骤：
- 开始前，先记下任何非托管磁盘的名称、逻辑单元号 (LUN) 和要将其附加到的 VM。 此操作可便于在故障转移完成后更轻松地重新附加磁盘。
- 关闭 VM。
- 删除 VM，但保留非托管磁盘的虚拟硬盘 (VHD) 文件。 记下 VM 删除时间。
- 等待上次同步时间更新，并确保它晚于删除 VM 的时间。 此步骤可确保在发生故障转移时使用 VHD 文件完全更新次要终结点，并且 VM 可在新的主要区域中正常运行。
- 启动帐户故障转移。
- 等到帐户故障转移完成，且次要区域成为新的主要区域。
- 在新的主要区域中创建 VM，并重新附加 VHD。
- 启动新 VM。
请注意，当 VM 关闭时，临时磁盘中存储的任何数据都会丢失。
将数据复制为故障转移替代方法
如前所述，可以通过将应用程序配置为使用配置为具有次要区域读取访问权限的存储帐户来保持高可用性。 但如果不希望在主要区域中的中断期间进行故障转移，则可以手动复制数据作为替代方法。 使用 AzCopy 和 Azure PowerShell 等工具，可以将受影响区域存储帐户中的数据复制到不受影响区域中的另一个存储帐户。 复制操作完成后，可以将应用程序重新配置为在未受影响的区域中使用存储帐户，以实现读取和写入可用性。
旨在实现高可用性
请务必从一开始就设计高可用性应用程序。 有关设计应用程序和规划灾难恢复方面的指导，请参阅以下 Azure 资源：
- 设计适用于 Azure 的可复原应用程序：概述了在 Azure 中生成高可用性应用程序的关键概念。
- 复原能力清单：用于验证应用程序是否实现高可用性最佳设计做法的清单。
- 使用异地冗余设计高度可用的应用程序：有关如何生成可利用异地冗余存储的应用程序的设计指南。
- 教程：生成使用 Blob 存储的高可用性应用程序：介绍了如何生成在模拟故障和恢复时自动切换终结点的高可用性应用程序的教程。
请参阅以下最佳做法来维护 Azure 存储数据的高可用性：
- 磁盘： 利用 Azure 备份备份 Azure 虚拟机使用的 VM 磁盘。 还应考虑在发生区域灾难时使用 Azure Site Recovery 来保护 VM。
- 块 blob： 启用软删除以防发生对象级删除和覆盖，或使用 AzCopy、Azure PowerShell 或 Azure 数据移动库将块 blob 复制到其他区域中的另一个存储帐户内。
- 文件：使用 Azure 备份来备份文件共享。 同时启用软删除，以防止意外删除文件共享。 对于 GRS 不可用时的异地冗余，请使用 AzCopy 或 Azure PowerShell 将文件复制到不同区域中的另一个存储帐户。
- 表：使用 AzCopy 将表数据导出到其他区域中的另一个存储帐户内。
跟踪服务中断
客户可以订阅 Azure 服务运行状况仪表板，以跟踪 Azure 存储和其他 Azure 服务的运行状况及状态。
Microsoft 还建议将应用程序设计为，可以应对可能出现的写入故障。 应用程序应公开写入故障，以提醒你主要区域可能存在服务中断。