通过

Azure非托管磁盘的备份和灾难恢复

适用于：✔️ Linux VM ✔️ Windows VM ✔️ 灵活规模集

2026 年 3 月 31 日，非托管磁盘即将停用。 如果使用非托管磁盘，请在该日期之前迁移到托管磁盘。 有关退役的详细信息，请参阅 在 2026 年 3 月 31 日之前迁移您的 Azure 非托管磁盘。

本文介绍如何在 Azure 中规划 IaaS virtual machines（VM）和磁盘的备份和灾难恢复（DR）。 本文档介绍非托管磁盘或页 blob。

首先，我们将介绍Azure平台中的内置容错功能，以帮助防范本地故障。 然后介绍内置功能未全面涵盖的灾难恢复方案。 此外，本文档演示了几个工作负载方案示例，它们的备份和 DR 注意事项各不相同。 最后，介绍适用于 IaaS 磁盘 DR 的可行解决方案。

介绍

Azure平台使用各种方法来实现冗余和容错，以帮助保护客户免受本地化硬件故障的影响。 本地故障可能包括Azure 存储服务器上的计算机出现问题，例如存储虚拟磁盘部分数据的计算机出现故障，或者该服务器上的 SSD 或 HDD 出现故障。 此类隔离的硬件组件故障可能会在正常操作期间发生。

Azure平台旨在应对这些故障。 重大灾难可能导致许多storage服务器甚至整个数据中心发生故障或不可访问。 尽管本地故障通常不会对 VM 和磁盘造成影响，但有必要采取额外措施，以保护工作负载不受整个区域内的灾难性故障（如重大灾难）影响，此类故障可能会影响 VM 和磁盘。

除了可能出现的平台故障外，客户应用程序或数据也可能会出现问题。 例如，应用程序的新版本可能会在无意间对数据进行更改，导致应用程序中断。 在这种情况下，我们建议将应用程序和数据还原到上一版已知的良好状态。 这需要维护定期备份。

对于区域性灾难恢复，必须在不同区域中备份 IaaS VM 磁盘。

在了解备份和 DR 选项之前，先来回顾一下本地故障的一些处理方法。

Azure IaaS 复原能力

复原是指对硬件组件中发生的常见故障实现容错。 恢复能力是指从故障中恢复并继续工作的能力。 复原并不旨在避免故障发生，而是通过响应故障来避免故障时间或数据丢失。 复原的目标是在故障发生后将应用程序恢复到可完全正常运行的状态。 Azure虚拟机和磁盘被设计为具有弹性，能够抵抗常见硬件故障。 让我们看看 Azure IaaS 平台如何提供这种复原能力。

虚拟机主要由以下两部分组成：计算服务器和永久性磁盘。 这两部分都会影响虚拟机的容错。

如果托管 VM 的Azure计算主机服务器遇到硬件故障（很少见），Azure旨在自动还原另一台服务器上的 VM。 如果发生这种情况，计算机会重新启动，并在一段时间后备份 VM。 Azure自动检测此类硬件故障并执行恢复，以帮助确保客户 VM 尽快可用。

对于 IaaS 磁盘，数据的持久性对持久存储平台至关重要。 Azure客户在 IaaS 上运行的重要业务应用程序，它们依赖于数据的持久性。 Azure 为这些 IaaS 磁盘设计了保护方案，在本地存储的数据中有三个冗余副本。 这些副本提供高持续性来应对本地故障。 如果托管磁盘的硬件组件之一出现故障，VM 不会受到影响，因为有两个额外的副本支持磁盘请求。 即使两个支持磁盘的不同硬件组件同时出现故障（这比较罕见），VM 也能正常运行。

为了确保始终维护三个副本，如果三个副本之一不可用，Azure Storage会自动在后台生成数据的新副本。 因此，不应将 RAID 与Azure磁盘一起使用，以便容错。 简单的 RAID 0 配置应足以对磁盘进行必要分区，以创建更大的卷。

由于此体系结构，Azure一直为 IaaS 磁盘提供企业级持续性，年化故障率为行业领先的零%。

计算主机或存储平台上的本地化硬件故障有时会导致受Azure SLA VM 可用性影响的虚拟机暂时不可用。 Azure 还为使用 Azure 高级 SSD 的单个 VM 实例提供行业领先的 SLA。

为了保护应用程序工作负载不受磁盘或 VM 暂时不可用带来的故障时间影响，客户可以使用可用性集。 可用性集中的两个或多个虚拟机为应用程序提供冗余。 然后，Azure使用不同的电源、网络和服务器组件在单独的容错域中创建这些 VM 和磁盘。

由于这些单独的容错域，本地硬件故障通常不会同时影响可用性集中的多个 VM。 单独的容错域为应用程序提供了高可用性。 如果需要高可用性，最好使用可用性集。 下一部分介绍灾难恢复方面。

备份和灾难恢复

灾难恢复是指能够从罕见但非常重大的事件中恢复。 这些事件包括非暂时性的大规模故障，如影响整个区域的服务中断。 灾难恢复包括数据备份和存档，并且可能包括手动干预，如通过备份还原数据库。

如果发生重大灾难导致大规模中断，则Azure平台针对本地化故障的内置保护可能无法完全保护 VM/磁盘。 这些大规模中断事件包括数据中心遭遇飓风、地震、火灾或大规模硬件单元故障等灾难性事件。 此外，可能还会遇到应用程序或数据问题导致的故障。

要保护 IaaS 工作负载不受中断影响，应计划冗余和备份，以便能够进行恢复。 对于灾难恢复，应该在远离主站点的不同地理位置备份。 该方式有助于确保最初影响 VM 或磁盘的相同事件不会对备份造成影响。

DR 注意事项可能包括以下方面：

  • 高可用性：应用程序能够以正常状态继续运行，而没有显著增加故障时间。 “正常状态”是指，应用程序有响应，用户可以连接到应用程序，并与之交互。 某些任务关键型应用程序和数据库可能需要始终可用，即使平台上有故障，也不例外。 对于这些工作负载，可能需要为应用程序和数据计划冗余。

  • 数据持续性：在某些情况下，主要注意事项是确保在灾难发生时保留数据。 因此，可能需要在不同站点中备份数据。 对于此类工作负载，可能不需要为应用程序计划完全冗余，只需定期备份磁盘即可。

备份和 DR 方案

让我们看看一些典型的应用程序工作负荷方案示例，以及规划灾难恢复时的注意事项。

应用场景 1：主要数据库解决方案

假设生产数据库服务器（如 SQL Server 或 Oracle）可以支持高可用性。 关键生产应用程序和用户依赖此类数据库。 此系统的灾难恢复计划可能需要满足以下要求：

  • 数据必须受保护且可恢复。
  • 服务器必须可用。

灾难恢复计划可能需要将不同区域中的数据库副本作为备份进行维护。 解决方案包括主动-主动或主动-被动副本站点、定期脱机备份数据，具体视服务器可用性和数据恢复要求而定。 关系数据库（如 SQL Server 和 Oracle）提供各种复制选项。 对于SQL Server，请使用 SQL Server Always On 可用性组实现高可用性。

为了实现冗余，MongoDB 等 NoSQL 数据库也支持副本。 可以使用实现高可用性的副本。

应用场景 2：冗余 VM 群集

假设由提供冗余和负载均衡的 VM 群集处理工作负载。 例如，在区域中部署的 Cassandra 群集。 此类体系结构已在相应区域提供了高水平冗余。 不过，为了保护工作负载免受区域级故障影响，应考虑在两个区域分布群集，或定期备份到另一个区域。

应用场景 3：IaaS 应用程序工作负荷

让我们探讨一下 IaaS 应用程序工作负载。 例如，此应用程序可能是Azure VM 上运行的典型生产工作负荷。 它可能是保存内容和其他站点资源的 Web 服务器或文件服务器。 也可能是在 VM 上运行的专门定制的商业应用程序，将数据、资源和应用程序状态存储到 VM 磁盘上。 在这种情况下，请务必定期进行备份。 应根据 VM 工作负载的性质确定备份频率。 例如，如果应用程序每天都运行，并且修改数据，那么应每小时备份一次。

再例如，报表服务器从其他数据源拉取数据，并生成聚合报表。 如果丢失此 VM 或磁盘，可能导致报表丢失。 不过，可以重新运行报表进程，并重新生成输出。 在这种情况下，即使报表服务器遇到灾难，也不会真正丢失数据。 因此，可以有高水平的容错，允许报表服务器上丢失部分数据。 在这种情况下，不太频繁地进行备份可以降低成本。

应用场景 4：IaaS 应用程序数据问题

IaaS 应用程序数据问题是另一种可能的情况。 假设有一个应用程序，用于计算、维护和提供关键商业数据（如定价信息）。 新的应用程序版本有一个软件漏洞，错误地计算了定价，并损坏了平台提供的现有商业数据。 在这种情况下，最好还原到旧版应用程序和数据。 若要能够进行还原，请定期备份系统。

灾难恢复解决方案：Azure Backup

Azure Backup 用于备份和 DR，适用于 managed disks 和非托管磁盘。 可以创建备份作业，其中包含基于时间的备份、VM 轻松还原和备份保留策略。

如果将 高级 SSD、 托管磁盘或其他磁盘类型与 本地冗余存储 选项配合使用，则定期进行 DR 备份尤其重要。 Azure Backup将数据存储在恢复服务保管库中，以便长期保留。 为备份恢复服务保管库选择异地冗余存储选项。 此选项可确保将备份复制到其他Azure区域，以保护区域灾难。

对于非托管磁盘，可以将本地冗余存储类型用于 IaaS 磁盘，但请确保在恢复服务保管库中为 Azure Backup 启用异地冗余存储选项。

注释

如果对非托管磁盘使用 异地冗余存储或 读访问异地冗余存储选项，则仍需要备份和灾难恢复的一致快照。 使用 Azure Backup 或 consistent snapshots。

下表汇总了可用于 DR 的解决方案。

情景 自动复制 DR 解决方案
高级 SSD 本地（本地冗余存储） Azure 备份
托管磁盘 本地（本地冗余存储） Azure 备份
非托管本地冗余存储磁盘 本地（本地冗余存储） Azure 备份
非管理异地冗余存储磁盘 跨区域（地理冗余存储） Azure 备份
一致性快照
非托管读取访问地理冗余存储磁盘 跨区域（读取访问异地冗余存储） Azure 备份
一致性快照

要实现高可用性，最好在可用性集中使用托管磁盘，并结合使用 Azure 备份。 如果使用非托管磁盘，仍可使用 Azure Backup 进行 DR。 如果无法使用 Azure Backup，则采用 一致性快照（如后面的部分所述）是备份和 DR 的替代解决方案。

下面展示了在应用程序或基础结构一级可选择的高可用性、备份和 DR 选项：

级别 高可用性 备份或 DR
应用程序 SQL Server 始终在线 Azure 备份
基础结构 可用性集 具有一致性快照的地理冗余存储

使用 Azure Backup

Azure Backup可以将运行 Windows 或 Linux 的 VM 备份到Azure恢复服务保管库。 必须在生成数据的应用程序仍在运行时备份业务关键型数据，这让备份和还原业务关键型数据变得更加复杂。

若要解决此问题，Azure Backup为Microsoft工作负荷提供应用程序一致性备份。 它使用卷影复制服务来确保数据正确写入存储。 对于 Linux VM，默认的备份一致性模式是文件一致性备份，因为 Linux 不像 Windows 那样具有与卷影服务相当的功能。 对于 Linux 计算机，请参阅 Azure Linux VM 的应用程序一致性备份。

Azure Backup流程

Azure Backup在计划时间启动备份作业时，它会触发 VM 中安装的备份扩展以创建时间点快照。 创建快照时，会借助卷影服务来获取虚拟机中磁盘的一致性快照，不必关闭该虚拟机。 生成所有磁盘的一致性快照前，VM 中的备份扩展会刷新所有写入。 拍摄快照后，数据将通过Azure Backup传输到备份保管库。 为了使备份过程更加高效，服务只标识并传输在上次备份后已更改的数据块。

若要还原，可以通过Azure Backup查看可用的备份，然后启动还原。 可以通过 Azure portal、使用 PowerShell 或使用 Azure CLI 创建和还原Azure备份。

备份启用步骤

使用以下步骤通过 Azure portal 启用 VM 备份。 步骤可能有一些差异，具体视确切方案而定。 有关完整详细信息，请参阅 Azure Backup 文档。 Azure Backup也支持使用托管磁盘的虚拟机。

  1. 为 VM 创建恢复服务保管库：

    a。 在 Azure portal 中，浏览 所有资源并查找 Recovery Services 保管库。

    b. 在“恢复服务保管库”菜单上，单击“添加”，并按相关步骤操作，在 VM 所在区域中新建一个保管库。 例如，如果 VM 位于“中国北部”区域，请为保管库选择“中国北部”。

  2. 验证新创建的保管库的存储复制。 在 复原服务保管库下访问保管库，并转到 属性>备份配置>更新。 确保默认选择 地理冗余存储 选项。 该选项可确保保管库自动复制到辅助数据中心。 例如，中国北部的保管库会自动复制到中国东部。

  3. 配置备份策略，再从同一 UI 中选择 VM。

  4. 确保在 VM 上安装了备份代理。 如果使用 Azure 库中的镜像创建 VM，则已安装备份代理程序。 否则（即，如果使用自定义映像），请使用说明将 VM 代理安装到虚拟机上。

  5. 完成上述步骤后，会按备份策略中指定的时间间隔定期进行备份。 如有必要，可以从Azure portal上的保管库仪表板手动触发第一个备份。

有关使用脚本自动化 Azure Backup，请参阅 用于 VM 备份的 PowerShell cmdlets。

恢复步骤

如果需要修复或重新生成 VM，可以从保存库中的任意备份恢复点还原 VM。 可以通过下列两种不同方式来执行恢复：

  • 可以新建 VM，表示处于特定时间点的已备份 VM。

  • 可以还原磁盘，再使用 VM 模板自定义和重新生成还原后的 VM。

有关详细信息，请参阅使用 Azure Portal 还原虚拟机的说明。 这篇文档还逐步介绍了在主数据中心发生灾难时，如何使用异地冗余备份保管库将已备份 VM 还原到已配对数据中心。 在这种情况下，Azure Backup使用次要区域中的计算服务来创建还原的虚拟机。

还可以使用 PowerShell 从还原的磁盘创建新 VM。

备用解决方案：一致性快照

如果无法使用Azure Backup，可以使用快照实现自己的备份机制。 为 VM 使用的所有磁盘创建一致性快照，再将这些快照复制到另一个区域的过程比较复杂。 因此，Azure认为使用备份服务比生成自定义解决方案更好。

如果使用读取访问异地冗余存储/异地冗余存储用于磁盘，快照将自动复制到辅助数据中心。 如果使用本地冗余存储来存放磁盘数据，则需要自行复制数据。 有关详细信息，请参阅 使用增量快照备份Azure非托管 VM 磁盘。

快照表示处于特定时间点的对象。 快照因保留数据的大小递增而产生费用。 有关详细信息，请参阅 创建 blob 快照。

当 VM 正在运行时创建快照

尽管可以随时生成快照，但如果 VM 正在运行，就仍有数据流式传输到磁盘上。 快照可能包含部分正在测试的操作。 此外，如果涉及到多个磁盘，各个磁盘的快照可能在不同时间生成。 这些情况可能导致快照不协调。 如果在备份期间发生了更改，带分区的卷文件就会被破坏，因此对此类文件来说，缺乏协调性导致的问题尤为严重。

为了避免这种情况发生，必须在备份过程中执行以下步骤：

  1. 冻结所有磁盘。

  2. 刷新所有挂起写入。

  3. 为所有磁盘创建 blob 快照。

某些 Windows 应用程序（如SQL Server）通过卷影服务提供协调的备份机制，以创建应用程序一致性备份。 在 Linux 上，可以使用 fsfreeze 等工具来协调磁盘。 此工具提供文件一致性备份，而不是应用程序一致性快照。 此过程很复杂，因此应考虑使用已实现此过程的 Azure Backup 或第三方备份解决方案。

上述过程会生成所有 VM 磁盘的协调快照集合，用于表示处于特定时间点的 VM。 这就是 VM 的备份还原点。 可以按原定时间间隔重复执行此过程，从而创建定期备份。 请参阅将备份复制到另一个区域，了解将快照复制到另一个区域进行 DR 的步骤。

当 VM 脱机时创建快照

创建一致性备份的另一种做法是，关闭 VM，再为每个磁盘生成 Blob 快照。 生成 Blob 快照比协调正在运行的 VM 的快照更为简单，但会出现几分钟的停机时间。

  1. 关闭 VM。

  2. 创建每个虚拟硬盘 Blob 的快照，这只需要几秒钟的时间。

    若要创建快照，可以使用 PowerShell， Azure Storage REST API、Azure CLI 或Azure Storage客户端库之一，例如 Storage .NET之一。

  3. 启动 VM，这将终止故障时间。 整个过程通常会在几分钟内完成。

此过程生成所有磁盘的一组一致性快照，提供 VM 的备份还原点。

将快照复制到另一个区域

仅仅创建快照可能不足以执行 DR。 还必须将快照备份复制到另一个区域。

如果您将异地冗余存储或读取访问异地冗余存储用于磁盘，那么快照会自动复制到次要区域。 复制前，可能会有几分钟的延迟。 如果主数据中心在快照完成复制之前出现故障，则无法access辅助数据中心的快照。 这种情况发生的可能性很小。

注释

仅仅在异地冗余存储或读取访问异地冗余存储帐户中拥有磁盘，无法保护虚拟机免受灾难的影响。 还必须创建协调快照或使用Azure Backup。 要将 VM 恢复到一致状态，必须这样做。

如果使用本地冗余storage，则必须在创建快照后立即将快照复制到其他storage帐户。 复制对象可能是位于不同区域的本地冗余存储帐户，因此副本位于远程区域。 还可以将快照复制到同一区域中的读取访问异地冗余存储帐户。 在这种情况下，快照会延迟复制到远程次要区域。 在复制完成后，备份就不会受到主站点所发生灾难的影响。

若要高效复制增量快照，请查看 使用增量快照备份Azure非托管 VM 磁盘的说明。

使用增量快照备份Azure非托管 VM 磁盘

通过快照恢复

要检索快照，请进行复制，以新建 blob。 要从主帐户复制快照，可将快照复制到快照的基 Blob。 此过程会将磁盘还原到快照。 此过程称为“提升快照”。 如果要从辅助帐户复制快照备份，且这是一个具有读取访问权限的地理冗余存储帐户，则必须将其复制到主要帐户。 可以通过使用 PowerShell 或使用 AzCopy 实用工具复制快照。 有关详细信息，请参阅 AzCopy 命令行实用工具使用 AzCopy 命令行工具传输数据。

对于包含多个磁盘的 VM，必须复制属于同一协调还原点的所有快照。 将快照复制到可写 VHD Blob 后，可以通过 Blob 使用 VM 模板重新创建 VM。

其他选项

SQL Server

VM 中运行的SQL Server 具有自己的内置功能，用于将 SQL Server 数据库备份到 Azure Blob 存储或文件共享。 如果存储帐户是异地冗余存储或读取访问异地冗余存储，则可以在发生灾难时在存储帐户的辅助数据中心访问这些备份，但仍然存在与之前讨论的相同限制。 有关详细信息，请参阅在 Azure 虚拟机中备份和还原 SQL Server。 除了备份和还原，SQL Server Always On可用性组还可以维护数据库的次要副本。 这种功能可以大大减少灾难恢复时间。

其他注意事项

本文介绍了如何通过备份或生成 VM 及其磁盘的快照来支持灾难恢复，以及如何使用这些备份或快照恢复数据。 借助Azure Resource Manager模型，许多人使用模板在Azure中创建 VM 和其他基础结构。 可以使用模板创建每次配置都相同的 VM。 如果使用自定义映像创建 VM，还必须确保映像受到保护，方法是使用具有读取访问权限的异地冗余存储帐户来存储这些映像。

因此，备份过程可能分为以下两部分：

  • 备份数据（磁盘）。
  • 备份配置（模板和自定义映像）。

可能需要备份数据和配置，或备份服务可能会处理所有这些事务，具体视选择的备份选项而定。

附录：了解数据冗余的影响

对于 Azure 中的存储帐户，应考虑三种与灾难恢复有关的数据冗余类型：本地冗余、异地冗余或含读取访问权限的异地冗余。

本地冗余存储在同一数据中心保留三个数据副本。 VM 写入数据时，所有三个副本都在向调用方返回成功结果之前进行更新，因此可以知道它们是完全相同的。 磁盘不受本地故障影响，因为这三个副本不可能都同时受到影响。 对于本地冗余存储，由于没有地理冗余，磁盘不受保护，不能防止灾难性故障，这些故障可以影响整个数据中心或存储单元。

使用地理冗余存储和读取访问地理冗余存储，所选主要区域中会保留您数据的三个副本。 另外三个数据副本将保留在由Azure设置的相应次要区域中。 例如，如果将数据存储在中国北部，则数据将复制到中国东部。 副本保留是以异步方式完成的，主要站点和辅助站点的更新稍有延迟。 辅助站点上的磁盘副本具有每磁盘一致性（有延迟），但多个活动磁盘的副本可能不会彼此同步。 要跨多个磁盘拥有一致副本，需要创建一致性快照。

异地冗余存储与读取访问地理冗余存储的主要区别在于，使用读取访问地理冗余存储，可以随时读取次要副本。 如果出现导致主要区域中数据无法访问的问题，Azure团队会尽一切努力恢复访问。 主数据库不可用时，如果启用了读取访问异地冗余存储，则可以访问辅助数据中心中的数据。 因此，如果计划在无法访问主副本时从副本中读取，则应考虑使用支持读取访问的异地冗余存储。

如果事实证明发生了重大中断，Azure团队可能会触发地理故障转移，并将主要 DNS 条目更改为指向辅助存储。 此时，如果启用了地理冗余存储或读取访问地理冗余存储，您可以访问以前作为辅助区域的数据。 换句话说，如果存储帐户是异地冗余存储并且出现问题，则只有在发生异地故障转移时，才能访问辅助存储。

有关详细信息，请参阅 发生 Azure 存储中断时该怎么办。

后续步骤

请参阅 使用增量快照备份Azure非托管虚拟机磁盘。

  • Last updated on