备份 SQL Server AlwaysOn 可用性组

  • 项目

备份 SQL Server AlwaysOn 可用性组 (AG) 时，如果所有节点都位于恢复服务保管库所在的区域和订阅中，Azure 备份将提供端到端支持。 但是，如果 AG 节点分散在多个区域/订阅/本地和 Azure 中，则需要记住几个注意事项。

注意

  • Azure 备份不支持备份基本可用性组数据库。
  • 若要详细了解支持的配置和场景，请参阅 SQL 备份支持矩阵。

Azure 备份 SQL AG 使用的备份首选项仅支持从主要副本运行完整和差异备份。 因此，无论备份首选项如何，这些备份作业始终在主节点上运行。 对于仅复制完整备份和事务日志备份，在确定运行备份的节点时，会考虑 AG 备份首选项。

AG 备份首选项 完整和差异备份运行于 仅复制和日志备份取自
主要 主副本 主副本
仅辅助 主副本 次要副本中的任何一个
优先辅助 主副本 首选次要副本，但备份也可以在主要副本上运行。
无/任意 主副本 任意副本

向 Azure 备份服务注册节点时，系统会在该节点上安装工作负载备份扩展。 为 AG 数据库配置备份时，备份计划会推送到 AG 的所有注册节点。 计划将在所有 AG 节点上触发，这些节点上的工作负载备份扩展相互同步，以决定哪个节点将执行备份。 节点选择取决于备份类型和备份首选项，如第 1 部分所述。

所选节点继续执行备份作业，而在其他节点上触发的作业则退出，即跳过该作业。

注意

Azure 备份在决定使用哪个次要副本时不考虑备份优先级或副本。

将 AG 节点注册到恢复服务保管库

恢复服务保管库仅支持从其所在区域和订阅中的 VM 备份数据库。

  • 你必须将主节点注册到保管库（否则无法进行完整备份）。
  • 如果备份首选项是“仅次要”，则需要向保管库注册至少一个次要节点（否则无法进行日志/仅复制完整备份）。

如果不满足上述条件，则无法为 AG 数据库配置备份，并显示错误代码 FabricSvcBackupPreferenceCheckFailedUserError。

以下面的 AG 部署作为参考。

Diagram for AG deployment as reference.

基于上述示例 AG 部署，以下是各种注意事项：

  • 由于主节点位于区域 1 和订阅 1 中，因此恢复服务保管库（保管库 1）必须位于区域 1 和订阅 1 中，才能保护此 AG。
  • VM3 无法注册到保管库 1，因为它位于不同的订阅中。
  • VM4 无法注册到保管库 1，因为它位于不同的区域中。
  • 如果备份首选项是“仅次要”，则 VM1（主要）和 VM2（次要）必须注册到保管库 1（因为完整备份需要主节点，而日志备份需要次要节点）。 对于其他备份首选项，VM1（主要）必须注册到保管库 1，VM2 可选（因为所有备份都可以在主节点上运行）。
  • 虽然 VM3 可以注册到订阅 2 中的保管库 2，AG 数据库随即会出现在保管库 2 中以获得保护，但由于保管库 2 中没有主节点，备份配置将失败。
  • 同样，虽然 VM4 可以注册到区域 2 中的保管库 4，但由于主节点未在保管库 4 中注册，备份配置将失败。

处理故障转移

在 AG 故障转移到某个次要节点后：

  • 如果新的主节点已注册到保管库，则会从该节点继续执行完整和差异备份。
  • 日志和仅复制完整备份将根据备份首选项从主/次要节点继续进行。

注意

如果故障转移与备份不一致，则在故障转移时不会发生日志链中断。

基于上面的示例 AG 部署，下面说明了各种故障转移可能性：

  • 故障转移到 VM2
    • 完整和差异备份将从 VM2 进行。
    • 日志和仅复制完整备份将根据备份首选项从 VM1 或 VM2 进行。
  • 故障转移到 VM3（另一个订阅）
    • 由于未在保管库 2 中配置备份，因此不会进行任何备份。
    • 如果备份首选项不是“仅次要”，现在可以在保管库 2 中配置备份，因为主节点已在此保管库中注册。 但这可能会导致冲突/备份失败。 有关这方面的详细信息，请参阅为多区域 AG 配置备份。
  • 故障转移到 VM4（另一个区域）
    • 由于未在保管库 4 中配置备份，因此不会进行任何备份。
    • 如果备份首选项不是“仅次要”，现在可以在保管库 4 中配置备份，因为主节点已在此保管库中注册。 但这可能会导致冲突/备份失败。 有关这方面的详细信息，请参阅为多区域 AG 配置备份。

为多区域 AG 配置备份

恢复服务保管库不支持跨订阅或跨区域备份。 本部分总结了如何为跨订阅或 Azure 区域的 AG 启用备份以及相关注意事项。

  • 评估是否确实需要从所有节点启用备份。 如果一个区域/订阅拥有大部分 AG 节点，并且很少故障转移到其他节点，则在第一个区域设置备份可能就足够了。 如果经常发生到另一个区域/订阅的故障转移，并且持续时间很长，那你可能还需要在另一个区域主动设置备份。

  • 启用备份的每个保管库都有自己的一组恢复点链。 只能对在该保管库中注册的 VM 执行从这些恢复点还原的操作。

  • 只有在具有主节点的保管库中才能成功进行完整/差异备份。 其他保管库中的这些备份将不断失败。

  • 日志备份将在以前的保管库中继续运行，直到某个日志备份在新保管库（即存在新主节点的保管库）中运行并中断旧保管库的日志链。

    注意

    日志备份有一个 15 天的硬性限制，超过这个期限，日志备份将开始失败。

  • 仅复制完整备份可在所有保管库中运行。

  • 每个保管库中的保护都被视为不同的数据源并单独计费。

为了避免两个保管库之间发生日志备份冲突，建议将备份首选项设置为“主要”。 这样，具有主节点的保管库也将进行日志备份。

基于上面的示例 AG 部署，下面介绍了从所有节点启用备份的步骤。 其中假设所有步骤都满足该备份首选项。

步骤 1：在区域 1、订阅 1（保管库 1）中启用备份

由于主节点在该区域和订阅中，因此，可按常规步骤启用备份。

步骤 2：在区域 1、订阅 2（保管库 2）中启用备份

  1. 将 AG 故障转移到 VM3，以便主节点出现在保管库 2 中。
  2. 为保管库 2 中的 AG 数据库配置备份。
  3. 此时：
    1. 保管库 1 中的完整/差异备份将失败，因为所有注册节点都无法进行此备份。
    2. 日志备份将在保管库 1 中成功运行，直到某个日志备份在保管库 2 中运行并中断保管库 1 的日志链。
  4. 将 AG 故障回复到 VM1。

步骤 3：在区域 2、订阅 1（保管库 4）中启用备份

与步骤 2 相同。

备份跨 Azure 和本地的 AG

适用于 SQL Server 的 Azure 备份不能在本地运行。 如果主节点在 Azure 中，并且 Azure 中的节点满足备份首选项，则可以按照上述多区域 AG 指南为 Azure 中的副本启用备份。 如果故障转移到本地节点，Azure 中的完整和差异备份将开始失败。 日志备份可能会持续到日志链中断/15 天后。

AG 数据库中备份作业的限制

目前，备份限制适用于单个计算机级别。 默认限制为 20 - 如果同时触发超过 20 个备份，前 20 个将运行，其他将排队。 正在运行的作业完成后，排队的作业将开始运行。

如果并发备份导致节点上的内存/IO/CPU 资源紧张，可以将此值更改为较小的值。 由于限制发生在节点级别，因此 AG 节点不均衡可能会导致备份同步问题。 为了理解这一点，我们以双节点 AG 为例。

例如，第一个节点保护 50 个独立数据库，两个节点都保护 5 个 AG 数据库。 实际上，节点 1 计划了 55 个数据库备份作业，而节点 2 只有 5 个。 此外，所有这些备份配置为每小时同时运行一次。 在某一时刻，所有 55 个备份都将在节点 1 上触发，其中 35 个排入队列。 其中一些备份是 AG 数据库备份。 但在节点 2 上，AG 数据库备份将继续进行，无需任何排队。

由于 AG 数据库作业在一个节点上排队，在另一个节点上运行，因此备份同步（在第 6 部分中提到）将无法正常工作。 节点 2 可能假设节点 1 已关闭，因此来自节点 2 的作业不会进行同步。 这可能导致日志链中断或额外备份，因为两个节点都可以独立进行备份。

如果受保护的 AG 数据库数量超过限制，则会发生类似问题。 在这种情况下，DB1 的备份可能在节点 1 上排队，在节点 2 上运行。

建议使用以下备份首选项来避免这些同步问题：

  • 对于双节点 AG，将备份首选项设置为“主要”或“仅次要”- 只有一个节点可以进行备份，另一个始终退出。
  • 对于具有超过 2 个节点的 AG，将备份首选项设置为“主要”- 只有主节点可以进行备份，其他节点将退出。

AG 备份计费

与独立的 SQL 实例相同，一个备份的 AG 实例被视为一个受保护的实例。 系统按实例中所有受保护数据库的总前端大小收费。 以下面的部署为例：

Diagram showing the calculation of protected instances of databases.

受保护的实例的计算方式如下：

受保护的实例/计费实例 考虑用于计算前端大小的数据库
AG1 DB1、DB2
AG2 DB4
VM2 DB3
VM3 DB6
VM4 DB5

将受保护的数据库移入或移出 AG

Azure 备份将 SQL 实例或 AG 名称\数据库名称视为数据库唯一名称。 当独立数据库受保护时，其唯一名称为 StandAloneInstanceName\DBName。 当它移入 AG 时，唯一名称更改为 AGName\DBName。 独立数据库的备份将开始失败，并显示错误代码：UserErrorBackupFailedStandaloneDatabaseMovedInToAG。

该数据库必须配置为在 AG 下进行保护。 它将被视为具有单独恢复点链的新数据源。 可以停止独立数据库的旧保护，并保留数据，以避免将来在该数据库上触发备份且备份失败。 同样，当受保护的 AG 数据库移出 AG 并成为独立数据库时，其备份开始失败并显示错误代码：UserErrorBackupFailedDatabaseMovedOutOfAG。

该数据库必须配置为在独立实例下进行保护。 它将被视为具有单独恢复点链的新数据源。 可以停止 AG 数据库的旧保护，并保留数据，以避免将来在该数据库上触发备份且备份失败。

在 AG 中添加/删除节点

将新节点添加到配置为进行备份的 AG 时，已注册的 AG 节点上运行的工作负载备份扩展会在下一个计划数据库发现作业期间检测 AG 拓扑更改，并通知 Azure 备份服务。 当这个新节点注册到与其他现有节点相同的恢复服务保管库进行备份时，Azure 备份服务会触发一个工作流，该工作流使用执行 AG 备份所需的元数据来配置这个新节点。

之后，新节点从 Azure 备份服务同步 AG 备份计划信息，并开始参与同步备份过程。 如果新节点无法同步备份计划并参与备份，那么，在节点上触发重新注册也会强制重新配置节点以进行 AG 备份。 同样，删除节点时，工作负载扩展会检测这种情况下的 AG 拓扑更改并通知 Azure 备份服务。 该服务会在删除的节点中启动节点取消配置工作流，以清除 AG 数据库的备份计划并删除与 AG 相关的元数据。

从 Azure 备份注销 AG 节点

如果某个节点属于 AG，该 AG 具有一个或多个配置为进行备份的数据库，则 Azure 备份不允许注销该节点。 这是为了防止没有此节点就无法满足备份首选项，从而导致将来的备份失败。 若要注销节点，首先需要将其从 AG 中删除。 当节点取消配置工作流完成，清理了该节点，就可以注销该节点。

将数据库从 Azure 备份还原到 AG SQL 可用性组时，不支持直接将数据库还原到 AG。 数据库需要还原到独立的 SQL 实例，然后需要加入 AG。

为 SQL 数据库服务器重新创建可用性组的情况

在以下情况下，重新创建的可用性组 (AG)、重复的 AG 和备份项目将被列为“可保护项目”或“受保护项目”：

  • 在“配置备份”页面和“受保护项目”列表中，重新创建的已受保护的 AG 将显示为重复的 AG。 如果要保留旧 AG 中已有的备份数据，请先使用“停止保护并保留数据”选项停止备份，然后再重新创建新 AG 项目并安排备份。

    根据设计，Azure 备份会在“受保护项目”列表、“配置备份”页面或“可保护项目”列表上列出重复项目，并显示这些项目，直到你想要保留备份数据为止。

  • 如果不希望备份数据来自较旧的 AG，请在重新创建新 AG 并安排备份之前，使用“停止保护并删除数据”选项来为较旧的项目停止备份操作。

    注意

    “停止保护并删除数据”是一项破坏性操作。

  • 你可以在执行上述某个“停止保护”过程后重新创建 AG，以避免备份失败。

后续步骤

了解如何：