概要了解 Azure VM 备份
本文介绍 Azure 备份服务如何备份 Azure 虚拟机 (VM)。
Azure 备份提供独立且隔离的备份来防止 VM 上的数据被意外破坏。 备份存储在提供恢复点内置管理的恢复服务保管库中。 配置和缩放很简单，备份经过优化，可以轻松地根据需要还原。
在备份过程中，将创建快照，并会将数据传输到恢复服务保管库，而不影响生产工作负荷。 快照提供了不同的一致性级别，如此文所述。 可以选择在备份策略中选择基于代理的应用程序一致/文件一致备份或无代理崩溃一致备份。
Azure 备份还针对数据库工作负荷（例如 SQL Server 和 SAP HANA）提供了专门的工作负荷感知型产品/服务，可提供 15 分钟 RPO（恢复点目标），并允许备份和还原单个数据库。
备份过程
下面介绍 Azure 备份如何对 Azure VM 完成备份：
- 对于选择进行备份的 Azure VM，Azure 备份服务将根据指定的备份计划启动备份作业。
- 如果选择了应用程序或文件系统一致备份，VM 需要安装备份扩展才能协调快照过程。
- 首次备份期间，如果 VM 已运行，则会在 VM 上安装备份扩展。
- 对于 Windows VM，将安装 VMSnapshot 扩展。
- 对于 Linux VM，将安装 VMSnapshotLinux 扩展。
- 对于正在运行的 Windows VM，Azure 备份会与卷影复制服务 (VSS) 互相配合，来创建 VM 的应用一致快照。
- 备份服务默认创建完整的 VSS 备份。
- 如果备份服务无法创建应用一致性快照，则会创建基础存储的文件一致性快照（因为当 VM 停止时，不会发生应用程序写入）。
- 对于 Linux VM，Azure 备份将创建文件一致性备份。 对于应用一致性快照，需要手动自定义前脚本/后脚本。
- 对于 Windows VM，Microsoft Visual C++ 2013 Redistributable (x64) 版本 12.0.40660 已安装，卷影复制服务 (VSS) 的启动更改为自动，并添加了 Windows Service IaaSVmProvider。
- 备份服务创建快照后，会将数据传输到保管库。
- 可以通过并行备份每个 VM 磁盘来优化备份。
- 对于每个要备份的磁盘，Azure 备份将读取磁盘上的块，识别并只传输自上次备份以来已发生更改的数据块（增量传输）。
- 快照数据可能不会立即复制到保管库。 在高峰期，可能需要好几个小时才能完成复制。 每日备份策略规定的 VM 备份总时间不会超过 24 小时。
加密 Azure VM 备份
使用 Azure 备份备份 Azure VM 时，将使用存储服务加密 (SSE) 对 VM 进行静态加密。 Azure 备份还可以备份使用 Azure 磁盘加密进行加密的 Azure VM。
| 加密 | 详细信息 | 支持 |
|---|---|---|
| SSE | Azure 存储使用 SSE 提供静态加密，在存储数据之前，它会自动加密数据。 Azure 存储还会在检索数据之前解密数据。 Azure 备份支持使用两种类型的存储服务加密对 VM 进行备份： |
Azure 备份使用 SSE 对 Azure VM 进行静态加密。 |
| Azure 磁盘加密 | Azure 磁盘加密可以加密 Azure VM 的 OS 磁盘和数据磁盘。 Azure 磁盘加密与在 Key Vault 中作为机密受到保护的 BitLocker 加密密钥 (BEK) 相集成。 Azure 磁盘加密还与 Azure Key Vault 密钥加密密钥 (KEK) 相集成。 |
Azure 备份支持备份仅使用 BEK 加密的，或者同时使用 BEK 和 KEK 加密的托管型和非托管型 Azure VM。 BEK 和 KEK 都会得到备份和加密。 由于 KEK 和 BEK 都会得到备份，拥有相应权限的用户可根据需要，将密钥和机密还原到 Key Vault。 这些用户还可以恢复已加密的 VM。 未经授权的用户或 Azure 无法读取已加密的密钥和机密。 |
对于托管和非托管 Azure VM，备份服务支持仅经过 BEK 加密的或者同时经过 BEK 和 KEK 加密的 VM。
备份的 BEK（机密）和 KEK（密钥）将会加密。 只有在经授权的用户将它们还原到 Key Vault 之后，才能读取和使用它们。 未经授权的用户和 Azure 都无法读取或使用备份的密钥或机密。
同时会备份 BEK。 因此，在 BEK 丢失的情况下，经授权的用户可将 BEK 还原到 Key Vault 并恢复加密的 VM。 只有拥有所需的权限级别的用户才可以备份和还原加密的 VM 或密钥和机密。
快照创建
Azure 备份根据备份计划创建快照。
如果选择了应用程序或文件系统一致备份，VM 需要安装备份扩展才能协调快照过程。
Windows VM： 对于 Windows VM，备份服务将与 VSS 相配合，来创建 VM 磁盘的应用一致性快照。 默认情况下，Azure 备份会执行完整的 VSS 备份（它在备份时会截断 SQL Server 等应用程序的日志，以获取应用程序级别的一致备份）。 如果在 Azure VM 备份时使用 SQL Server 数据库，则可以修改设置以执行 VSS 副本备份（以保留日志）。 有关详细信息，请参阅此文章。
Linux VM： 若要创建 Linux VM 的应用一致性快照，请使用 Linux 前脚本和后脚本框架编写自己的自定义脚本，以确保一致性。
- Azure 备份只调用你编写的前脚本/后脚本。
- 如果前脚本和后脚本成功执行，Azure 备份会将恢复点标记为应用程序一致。 但是，在使用自定义脚本时，你最终需要为应用程序一致性负责。
- 详细了解如何配置脚本。
快照一致性
下表解释了不同的快照一致性类型：
| 快照 | 详细信息 | 恢复 | 注意事项 |
|---|---|---|---|
| 应用程序一致 | 这是 VM 备份策略中的默认设置。 应用一致性备份捕获内存内容和挂起的 I/O 操作。 应用一致性快照使用 VSS 编写器（或适用于 Linux 的前/后脚本）来确保备份之前的应用数据一致性。 | 使用应用一致性快照恢复 VM 时，VM 将会启动。 不会发生数据损坏或丢失。 应用将以一致的状态启动。 | Windows:所有 VSS 编写器均成功 Linux：前/后脚本已配置并成功 |
| 文件系统一致性 | 这是 VM 备份策略中的默认设置。 文件系统一致性备份通过同时创建所有文件的快照来提供一致性。 |
使用文件系统一致性快照恢复 VM 时，VM 将会启动。 不会发生数据损坏或丢失。 应用需要实现自己的“修复”机制以确保还原的数据一致。 | Windows：某些 VSS 编写器失败 Linux：默认值（如果前/后脚本未配置或失败） |
| 崩溃一致 | 崩溃一致快照是 VM 备份策略中的选择加入设置。 如果 VM 在备份期间未运行，并且应用程序/文件一致备份失败，则 Azure 备份也会执行崩溃一致备份。 只会捕获并备份在备份操作时磁盘上已存在的数据；不会捕获读/写主机缓存中的数据。 |
从 VM 启动过程开始，然后进行磁盘检查以修复损坏错误。 在崩溃之前未传输到磁盘的任何内存中数据或写入操作将会丢失。 应用实现自身的数据验证。 例如，数据库应用可以使用其事务日志进行验证。 如果事务日志中有条目不在数据库中，则数据库软件将回滚事务，直到数据一致。 | 当你选择应用程序/文件系统备份且 VM 处于关闭状态（已停止/解除分配）时以及重试快照时。 你已选择无代理崩溃一致备份 |
注意
如果预配状态为“成功”，则 Azure 备份会执行文件系统一致性备份。 如果预配状态为“不可用”或“失败”，则会执行崩溃一致性备份。 如果预配状态为“正在创建”或“正在删除”，则意味着 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 的每个数据磁盘的最大支持大小。
与此类似，备份存储的收费是基于 Azure 备份中存储的数据量，即每个恢复点中实际数据之和。
以 A2-Standard 大小的 VM 为例，该 VM 有两个额外的数据磁盘，其最大大小各为 32 TB。 下表显示了其中每个磁盘上存储的实际数据：
| 磁盘 | 最大大小 | 实际存在的数据 |
|---|---|---|
| OS 磁盘 | 32 TB | 17 GB |
| 本地/临时磁盘 | 135 GB | 5 GB（不包括在备份中） |
| 数据磁盘 1 | 32 TB | 30 GB |
| 数据磁盘 2 | 32 TB | 0 GB |
此示例中，VM 的实际大小为 17 GB + 30 GB + 0 GB = 47 GB。 此受保护实例大小 (47 GB) 成为按月计费的基础。 随着 VM 中数据量的增长，用于计费的受保护实例大小也会相应变化。