Compartir a través de

Azure VM 备份概述

本文介绍 Azure 备份 服务如何备份Azure虚拟机（VM）。

Azure 备份提供独立和独立的备份，以防止 VM 上的数据意外销毁。 备份存储在提供恢复点内置管理的恢复服务保管库中。 配置和缩放很简单，备份经过优化，可以轻松地根据需要还原。

在备份过程中，将创建快照，并将数据传输到恢复服务保管库，而不影响生产工作负荷。 快照提供了不同的一致性级别，如此文所述。 可以在备份策略中选择基于代理的应用一致性/文件一致性备份或无代理的崩溃一致性备份。

Azure 备份还针对SQL Server和SAP HANA等数据库工作负荷提供专用产品/服务，提供 15 分钟的 RPO（恢复点目标），并允许备份和还原各个数据库。

备份过程

下面是Azure 备份如何为 Azure VM 完成备份：

  1. 对于为备份选择Azure VM，Azure 备份根据指定的备份计划启动备份作业。
  2. 如果选择了应用程序或文件系统一致备份，VM 需要安装备份扩展才能协调快照过程。
  1. 首次备份期间，如果 VM 已运行，则会在 VM 上安装备份扩展。
  2. 对于正在运行的Windows VM，Azure 备份与Windows卷影复制服务（VSS）协调，以拍摄 VM 的应用一致性快照。
    • 备份服务默认创建完整的 VSS 备份。
    • 如果备份服务无法创建应用一致性快照，则会创建基础存储的文件一致性快照（因为当 VM 停止时，不会发生应用程序写入）。
  3. 对于 Linux 虚拟机，备份将进行文件一致性备份。 为了获得应用程序一致性快照，您需要手动自定义前置/后置脚本。
  4. 对于 Windows 虚拟机，已安装 Microsoft Visual C++ 2015 Redistributable （x64） 版本 14.40.33810.0，将卷影复制服务（VSS）的启动方式更改为自动，并添加了 Windows 服务 IaaSVmProvider。
  5. 备份服务创建快照后，会将数据传输到保管库。
    • 可以通过并行备份每个 VM 磁盘来优化备份。
    • 对于每个正在备份的磁盘，Azure 备份会读取磁盘上的数据块，并仅识别和传输自上次备份以来发生更改的那些数据块（即增量）。
    • 快照数据可能不会立即被复制到保管库中。 在高峰期，可能需要几个小时。 每日备份策略规定的 VM 备份总时间不会超过 24 小时。

Diagram 显示Azure虚拟机备份体系结构.

Azure VM 备份的加密

使用Azure 备份备份Azure VM 时，使用存储服务加密（SSE）对 VM 进行静态加密。 Azure 备份还可以备份使用Azure 磁盘加密加密的Azure VM。

加密 详细信息 支持
SSE 使用 SSE，Azure 存储通过在存储数据之前自动加密数据来提供静态加密。 Azure 存储还会在检索数据之前解密数据。 Azure 备份支持使用两种类型的存储服务加密备份 VM：
  • 具有平台托管密钥的 SSE：默认情况下，此加密适用于 VM 中的所有磁盘。 在此处了解详细信息。
  • 具有客户管理密钥的 SSE。 使用 CMK，可以管理用于对磁盘进行加密的密钥。 在此处了解详细信息。
    		•  Azure 备份使用 SSE 对 Azure VM 进行静态加密。
    Azure 磁盘加密 Azure 磁盘加密加密 Azure VM 的 OS 和数据磁盘。

    Azure 磁盘加密与 BitLocker 加密密钥（BEK）集成，在密钥保管库中作为机密进行保护。 Azure 磁盘加密还与Azure 密钥保管库密钥加密密钥（KEK）集成。    		 Azure 备份支持备份仅使用 BEK 加密的托管Azure VM，或将 BEK 与 KEK 一起备份。

    BEK 和 KEK 都会得到备份和加密。

    由于 KEK 和 BEK 都会得到备份，拥有相应权限的用户可根据需要，将密钥和机密还原到 Key Vault。 这些用户还可以恢复已加密的 VM。

    未经授权的用户或Azure无法读取加密密钥和机密。

    对于托管的 Azure VM，备份支持仅使用 BEK 加密的 VM 或使用 BEK 和 KEK 加密的 VM。

    备份的 BEK（机密）和 KEK（密钥）将会加密。 只有在经授权的用户将它们还原到 Key Vault 之后，才能读取和使用它们。 未经授权的用户或Azure都不能读取或使用备份的密钥或机密。

    BEK 也会被备份。 因此，在 BEK 丢失的情况下，经授权的用户可将 BEK 还原到 Key Vault 并恢复加密的 VM。 只有拥有所需的权限级别的用户才可以备份和还原加密的 VM 或密钥和机密。

    快照创建

    Azure 备份根据备份计划拍摄快照。

    如果选择了应用程序或文件系统一致备份，VM 需要安装备份扩展才能协调快照过程。 对于无代理多磁盘崩溃一致备份，则快照不需要 VM 代理。

    • Windows VM： 对于Windows VM，Azure 备份与 VSS 协调以创建应用程序一致的快照。 对于运行SQL Server的 VM，Azure VM 备份默认触发 VSS 完整（Copy-Only）备份，以避免影响其他备份工具使用的 SQL 备份链。 Copy-Only 备份不会截断SQL Server事务日志。 如果您需要日志截断（并了解对 SQL 备份链的影响），可以通过使用 UseVssFullBackup 注册表设置选择 VSS 全备份（非仅复制）。 有关详细信息，请参阅此文章。

    注意

    Azure VM 备份是 VM 级备份。 如果需要使用事务日志进行数据库级时间点恢复，请使用适用于 Azure VM 中 SQL Server 的 Azure 备份（工作负荷备份）。

    • Linux VM： 若要创建 Linux VM 的应用一致性快照，请使用 Linux 前脚本和后脚本框架编写自己的自定义脚本，以确保一致性。

      • Azure 备份仅调用你编写的前/后脚本。
      • 如果预脚本和后脚本成功执行，Azure 备份将恢复点标记为应用程序一致。 但是，在使用自定义脚本时，你最终需要为应用程序一致性负责。
      • 详细了解如何配置脚本。

    • FSFreeze 和 safeFreezelockFile： Fsfreeze 是一个实用工具，用于冻结和解冻 文件系统 ，使其状态在 VM 备份期间保持一致。

      • 冻结：冻结文件系统时，允许当前正在运行的操作完成。 但是，新的写入系统操作和那些修改文件系统的操作将被停止。

      • 解冻：此操作将撤销冻结操作。 解冻文件系统时，以前停止的操作将继续有效运行，解除对任何修改的阻止。

      在 Freeze 操作期间，Azure 备份调用文件 safeFreezelockFile。 这可以防止其他进程调用类似的作，以便备份进程不会中断。 一旦操作完成，将释放锁。

    注意

    快照过程首先调用备份扩展（基于代理），使用 VSS 等工具来Windows或冻结 Linux 以确保数据一致性。 一致时，还原点集合会监视扩展并启动快照创建。 之后，使用还原点路径和提交详细信息更新元数据，以完成用于还原的备份。

    快照一致性

    下表解释了不同的快照一致性类型：

    快照 详细信息 恢复 注意事项
    应用程序一致性 这是 VM 备份策略中的默认设置。 应用一致性备份捕获内存内容和挂起的 I/O 操作。 应用一致性快照使用 VSS 编写器（或适用于 Linux 的前/后脚本）来确保备份之前的应用数据一致性。 使用应用一致性快照恢复 VM 时，VM 将会启动。 不会发生数据损坏或丢失。 应用将以一致的状态启动。 Windows：所有 VSS 编写器都成功

    Linux：前/后脚本已配置并成功
    文件系统一致性 这是 VM 备份策略中的默认设置。 文件系统一致性备份通过同时创建所有文件的快照来提供一致性。

    		 使用文件系统一致性快照恢复 VM 时，VM 将会启动。 不会发生数据损坏或丢失。 应用需要实现自己的“修复”机制以确保还原的数据一致。 Windows：某些 VSS 写入器出现故障

    Linux：默认值（如果前/后脚本未配置或失败）
    崩溃一致性 崩溃一致性快照是 VM（虚拟机）备份策略中的可选设置。 如果 VM 在备份期间未运行，并且应用程序/文件一致性备份失败，Azure 备份也会执行崩溃一致性备份。

    只会捕获并备份在备份操作时磁盘上已存在的数据；不会捕获读/写主机缓存中的数据。    		 从 VM 启动过程开始，然后进行磁盘检查以修复损坏错误。 在崩溃之前未传输到磁盘的任何内存中数据或写入操作将会丢失。 应用实现自身的数据验证。 例如，数据库应用可以使用其事务日志进行验证。 如果事务日志中有条目不在数据库中，则数据库软件将回滚事务，直到数据一致。 当你选择应用程序/文件系统备份且 VM 处于关闭状态（已停止/解除分配）时以及重试快照时。

    你已选择无代理崩溃一致性备份

    注意

    如果预配状态为 succeeded，Azure 备份采用文件系统一致性备份。 如果预配状态为“不可用”或“失败”，则会执行崩溃一致性备份。 如果预配状态为 creating 或 deleting，这意味着Azure 备份正在重试操作。

    备份和还原注意事项

    注意事项 详细信息
    磁盘 备份 VM 磁盘属于并行操作。 例如，如果 VM 有 4 个磁盘，则备份服务会尝试并行备份所有 4 个磁盘。 备份是增量式的（仅备份已更改的数据）。
    计划 若要减少备份流量，请在一天的不同时间备份不同的 VM，并确保时间不重叠。 同时备份 VM 会导致流量拥塞。
    准备备份 注意准备备份所需的时间。 准备时间可能涵盖安装或更新备份扩展，以及根据备份计划触发快照的时间。
    数据传输 请考虑Azure 备份识别上一备份中的增量更改所需的时间。

    在增量备份中，Azure 备份通过计算块的校验和来确定更改。 如果某个块发生更改，则将该块标识为要传输到保管库。 该服务将分析已标识的块，以试图进一步地尽量减少要传输的数据量。 评估所有更改块后，Azure 备份将更改传输到保管库。

    创建快照之后，可能要经过一段滞后时间才会将它复制到保管库。 在高峰时段，将快照传输到保管库可能需要长达 8 小时。 对于每日备份，VM 的备份时间小于 24 小时。
    初始备份 增量备份的总备份时间少于 24 小时，但第一次备份可能并非如此。 初始备份所需的时间取决于数据大小和备份处理时间。
    还原队列 Azure 备份同时处理从多个存储帐户还原作业，并将还原请求置于队列中。
    还原副本 在还原过程中，将保管库中的数据复制到存储帐户。

    总还原时间取决于存储帐户的每秒 I/O 操作次数 (IOPS) 和吞吐量。

    若要减少复制时间，请选择一个不带其他应用程序写入和读取负载的存储帐户。

    注意

    Azure 备份现在允许使用增强策略每天多次备份Azure VM。 借助此功能，还可以定义备份作业触发的持续时间，并将备份计划与频繁更新Azure 虚拟机的工作时间保持一致。 了解详细信息。

    备份性能

    这些常见的场景可能会影响总备份时间：

    • 将新磁盘添加到受保护的Azure VM： 如果 VM 正在进行增量备份并添加新磁盘，备份时间将增加。 总备份时间可能会超过 24 小时，因为需要对新磁盘进行初始复制，并且需要对现有磁盘进行增量复制。
    • 磁盘有碎片： 如果磁盘上的更改是相邻的，则备份操作会更快。 如果更改分散在磁盘的各个位置并出现碎片，则备份会变慢。
    • 磁盘变动率： 如果正在进行增量备份的受保护磁盘的每日变动率超过 200 GB，则备份可能需要花费很长时间（8 小时以上）才能完成。
    • 备份版本： 最新版本的备份（称为“即时还原”版本）使用比校验和比较更佳的优化进程来识别更改。 如果您正在使用即时还原并删除了备份快照，备份将切换为校验和比较。 在这种情况下，备份操作将超过 24 小时（或失败）。

    还原性能

    这些常见的场景可能会影响总还原时间：

    • 总还原时间取决于存储帐户的每秒输入/输出操作次数 (IOPS) 和吞吐量。
    • 如果目标存储帐户加载了其他应用程序读写操作，则总还原时间可能会受到影响。 若要改进还原操作，请选择未加载其他应用程序数据的存储帐户。

    最佳实践

    我们建议在配置 VM 备份时遵循以下做法：

    • 修改策略中设置的默认计划时间。 例如，如果策略中的默认时间是凌晨 12:00，请将时间递增几分钟，确保以最佳方式使用资源。
    • 如果从单个保管库还原 VM，强烈建议你使用不同的常规用途 v2 存储帐户，以确保目标存储帐户不会受到限制。 例如，每个 VM 必须具有不同的存储帐户。 例如，如果还原 10 个 VM，请使用 10 个不同的存储帐户。
    • 若要通过“即时还原”对使用高级存储的 VM 进行备份，建议从总的已分配存储空间中分配 50% 的可用空间，这只在首次备份时是必需的。 首次备份完成后，50% 的可用空间不再是备份的要求
    • 每个存储帐户的磁盘数量限制与在基础结构即服务 (IaaS) VM 上运行的应用程序访问磁盘的频率有关。 通常情况下，如果单个存储帐户上存在 5 至 10 个或以上磁盘，则可通过将一些磁盘移动到单独的存储帐户来均衡负载。
    • 若要使用 PowerShell 还原具有托管磁盘的 VM，请提供附加参数 TargetResourceGroupName 指定要将托管磁盘还原到的资源组，请在此了解详情。

    备份成本

    使用 Azure 备份 备份的Azure VM 受Azure 备份定价的约束。

    第一个备份成功完成后才会开始计费。 从这一点开始，存储和受保护的 VM 的计费也会同时开始。 只要任何与 VM 相关的备份数据存储在保管库中，就会持续计费。 如果对 VM 停止保护，但保管库中存在该 VM 的备份数据，则会继续计费。

    针对特定 VM 的计费仅在停止保护并且删除全部备份数据后才会停止。 当保护停止并且没有活跃的备份作业时，最后一次成功的 VM 备份的大小将用作每月帐单的受保护实例大小。

    如果选择了基于代理的应用程序一致备份或文件系统一致备份，则受保护的实例大小计算基于 VM 的实际大小。 VM 的大小是 VM 中除临时存储以外的所有数据之和。 定价基于数据磁盘中存储的实际数据，而不是附加到 VM 的每个数据磁盘的最大支持大小。

    注意

    无代理多磁盘崩溃一致 VM 备份功能已正式发布。 此版本包括对计费的更改;请参阅 定价详细信息。

    同样，备份存储费用基于存储在Azure 备份中的数据量，这是每个恢复点中实际数据的总和。

    以 A2-Standard 大小的 VM 为例，该 VM 有两个额外的数据磁盘，其最大大小各为 32 TB。 下表显示了其中每个磁盘上存储的实际数据：

    磁盘 最大大小 实际存在的数据
    操作系统盘 32 兆字节 17 GB
    本地/临时磁盘 135 GB 5 GB（不包括在备份中）
    数据磁盘 1 32 兆字节 30 GB
    数据磁盘 2 32 兆字节 0 GB

    此示例中，VM 的实际大小为 17 GB + 30 GB + 0 GB = 47 GB。 此受保护实例大小 (47 GB) 成为按月计费的基础。 随着 VM 中数据量的增长，用于计费的受保护实例大小也会相应变化。

    后续步骤

    • Last updated on