Azure SQL 托管实例中的自动备份

适用于：Azure SQL 托管实例

本文介绍 Azure SQL 托管实例的自动备份功能。

若要更改备份设置，请参阅更改设置。 若要还原备份，请参阅使用自动数据库备份进行恢复。

什么是自动数据库备份？

数据库备份是任何业务连续性和灾难恢复策略的基本组成部分，因为数据库备份可以帮助保护数据免遭损坏或删除。 Azure SQL 托管实例提供完全托管和自动化的 SQL Server 数据库引擎备份。 这些备份可在配置的保留期（最长达 35 天）内将数据库还原到某个特定时间点。 如果数据保护规则要求备份在较长时间（最长 10 年）内可用，可以为每个数据库配置长期保留 (LTR) 策略。

备份频率

Azure SQL 托管实例：

• 每周创建完整备份。
• 每隔 12 小时创建差异备份。
• 每隔 10 分钟创建事务日志备份。

事务日志备份的频率取决于计算大小和数据库活动量。 事务日志大约每 10 分钟记录一次，但可能会有所不同。 还原数据库时，服务会确定需要按其各自的顺序还原哪些完整备份、差异备份和事务日志备份。

备份存储冗余

默认情况下，Azure SQL 托管实例将数据存储在复制到配对区域的异地冗余存储 Blob 中。 异地冗余有助于防止主要区域中的服务中断影响备份存储。 它还允许在发生灾难时将实例还原到其他区域。

存储冗余机制存储数据的多个副本，以便在计划内和计划外事件期间提供保护。 这些事件可能包括暂时性硬件故障、网络中断或断电，或大范围的自然灾害。

为确保备份保留在部署数据库的同一区域内，可以将备份存储冗余从默认的异地冗余存储更改为将数据保留在区域内的其他存储类型。 若要详细了解存储冗余，请参阅数据冗余。

可以在创建实例时配置备份存储冗余，以后可以在实例级别对其进行更新。 对现有实例所做的更改仅应用于将来的备份。 更新现有实例的备份存储冗余后，最多可能需要 24 小时才能应用所做的更改。 对备份存储冗余所做的更改仅应用于短期备份。 长期保留策略继承创建策略时指定的短期备份冗余选项。 即使短期备份的冗余选项后来发生更改，长期备份的冗余选项也仍会一直保留。

可为备份选择以下存储冗余之一：

• 本地冗余存储 (LRS)：在主要区域中的单个物理位置内同步复制备份三次。 LRS 是成本最低的复制选项，但不建议对需要高可用性或持续性的应用程序使用此选项。

  

• 区域冗余存储 (ZRS)：跨主要区域中的三个 Azure 可用性区域同步复制备份。 目前在特定区域中可用。

  

• 异地冗余存储 (GRS)：使用 LRS 在主要区域中的单个物理位置内同步复制备份三次。 然后，它将数据异步复制到配对次要区域中的单个物理位置三次。

  结果为：

  • 单个可用性区域中主要区域中的三个同步副本。
  • 单个可用性区域内的配对区域中有三个同步副本，它们是从主要区域异步复制到次要区域的。

  

备份使用情况

可使用这些备份：

• 使用 Azure 门户、Azure PowerShell、Azure CLI 或 REST API 将现有的数据库还原到在保留期内的过去某个时间点。 此操作在原始数据库所在的同一实例上或者在同一订阅和区域中的不同实例上创建新数据库。 它使用不同的名称来避免覆盖原始数据库。 还可以使用 Azure 门户将时间点数据库备份还原到与源实例不同的订阅中的实例。

  还原完成后，可以删除原始数据库。 另外，可以重命名原始数据库，并将已还原的数据库重命名为原始数据库名称。

• 将已删除的数据库还原到保留期内的某个时间点（包括删除时的时间点）。 可以将已删除的数据还原到备份所在的同一托管实例，也可以将其还原到与源实例相同或不同的订阅中的另一个实例。 在删除数据库之前，服务会创建最终事务日志备份，以防任何数据丢失。

• 将数据库还原到其他地理区域。 在无法访问主要区域中的数据库和备份时，异地还原可帮助从某个地理区域内发生的灾难中恢复。 它会在任何 Azure 区域中的任意现有托管实例上创建新数据库。

  重要

  异地还原仅适用于配置了异地冗余备份存储的数据库。 如果当前没有对数据库使用异地复制的备份，可以通过配置备份存储冗余对此进行更改。

• 如果数据库配置了 LTR 策略，请从数据库的长期备份还原数据库。 LTR 允许使用 Azure 门户、Azure CLI 或 Azure PowerShell 来还原旧版数据库，以满足合规性请求或运行旧版应用程序。 有关详细信息，请查看长期保留概述页面。

还原功能和特性

下表汇总了时间点还原 (PITR)、异地还原和长期保留的功能和特性。

备份属性	PITR	异地还原	LTR
SQL 备份类型	完整备份、差异备份和事务日志备份	PITR 备份的复制副本。	仅完整备份。
恢复点目标 (RPO)	约 10 分钟，基于计算大小和数据库活动量。	最多 1 小时，基于异地复制。 1	一周（或用户策略）。
恢复时间目标 (RTO)	还原所需的时间通常少于 12 小时，但可能需要更长时间，具体取决于大小和活动。 请参阅恢复。	还原所需的时间通常少于 12 小时，但可能需要更长时间，具体取决于大小和活动。 请参阅恢复。	还原所需的时间通常少于 12 小时，但可能需要更长时间，具体取决于大小和活动。 请参阅恢复。
保留	1 到 35 天。	默认启用，与源相同。 2	默认情况下处于未启用状态。 最多保留 10 年。
Azure 存储	默认为异地冗余。 可以选择配置区域冗余或本地冗余存储。	当 PITR 备份存储冗余设置为异地冗余时可用。 当 PITR 备份存储是区域冗余或本地冗余存储时不可用。	默认为异地冗余。 可以配置区域冗余或本地冗余存储。
将备份配置为不可变	不支持	不支持	不支持
在同一区域中还原新数据库	支持	受支持	支持
在另一区域中还原新数据库	不支持	任何 Azure 区域都支持	任何 Azure 区域都支持
在另一订阅中还原新数据库	支持	不支持 3	不支持 3
通过 Azure 门户还原	是	是	是
通过 PowerShell 还原	是	是	是
通过 Azure CLI 还原	是	是	是

^{1 对于需要大型数据库且必须确保业务连续性的业务关键型应用程序，请使用故障转移组。}

^{2 默认情况下，所有 PITR 备份都存储在异地冗余存储上，这意味着异地还原已默认启用。}

^{3 解决方法是还原到新服务器，并使用资源转移功能将服务器移到另一个订阅。}

从备份还原数据库

若要执行还原，请参阅从备份还原数据库。 可以参考下列示例尝试执行备份配置和还原操作。

操作	Azure 门户	Azure CLI	Azure PowerShell
更改备份保留	SQL 数据库 / SQL 托管实例	SQL 数据库 / SQL 托管实例	SQL 数据库 / SQL 托管实例
更改长期备份保留	SQL 数据库 / SQL 托管实例	SQL 数据库 / SQL 托管实例	SQL 数据库 / SQL 托管实例
从某个时间点还原数据库	SQL 数据库 / SQL 托管实例	SQL 数据库 / SQL 托管实例	SQL 数据库 / SQL 托管实例
还原已删除的数据库	SQL 数据库 / SQL 托管实例	SQL 数据库 / SQL 托管实例	SQL 数据库 / SQL 托管实例
从 Azure Blob 存储还原数据库			SQL 托管实例

自动备份计划

Azure SQL 托管实例通过创建完整备份、差异备份和事务日志备份，来自动管理备份。 此过程由内部计划管理。

初始备份

• 新数据库：在对数据库进行创建、还原或备份冗余更改后，立即计划第一次完整备份。 此备份通常在 30 分钟内即可完成，但大型数据库可能需要更长的时间。

• 还原的数据库：还原数据库的初始备份持续时间因数据库大小而异。 还原的数据库或数据库副本（通常较大）进行初始备份可能需要较长的时间。

计划的完整备份

• 每周计划：系统为整个实例设置每周完整备份时段。
• 完整备份时段：这是执行完整备份时的指定时段。 虽然系统的目标是在此时段内完成完整备份，但如有必要，备份可能会超出计划时间，直到完成。
• 自适应计划：备份算法以 CPU 使用情况和 I/O 吞吐量作为指标，评估备份时段对工作负载的影响，频率约每周一次。 可根据前一周的工作负载调整完整备份时段。
• 用户配置：请务必注意，用户无法修改或禁用备份计划。

备份存储消耗量

使用 SQL Server 备份和还原技术时，将数据库还原到某个时间点需要一个不间断的备份链。 该链由一个完整备份、一个可选的差异备份以及一个或多个事务日志备份组成。

Azure SQL 托管实例备份计划包括每周一次完整备份。 若要在整个保留期内提供 PITR，系统需要额外存储完整备份、差异备份和事务日志备份，且存储时间最多比配置的保留期长一周。

换言之，对于保留期内的任意时间点，必须有一个比保留期的最早时间更早的完整备份。 此外，从该完整备份到下一次完整备份，也必须有一个不间断的差异备份和事务日志备份链。

将自动删除不再需要为提供 PITR 功能而保留的备份。 由于差异备份和日志备份需要早期的完整备份才可恢复，因此所有这三种备份类型会在每周都一并清除一次。

对于包括 TDE 加密数据库在内的所有数据库，所有完整备份和差异备份都会经过压缩，从而减少备份存储压缩和成本。 平均备份压缩率为 3 到 4 倍。 但是，根据数据的性质以及数据库中是否启用了数据压缩，平均备份压缩率可能会显著降低或提高。

Azure SQL 托管实例按累积值形式计算使用的总备份存储。 每小时向 Azure 计费管道报告此值。 管道负责在每个月底聚合此每小时用量，以计算你的消耗量。 删除数据后，随着备份的过期以及删除，消耗量将减少。 删除所有备份后，PITR 不再可用，计费会停止。

微调备份存储消耗量

只要备份存储消耗量不超过数据库的最大数据大小，就不会对备份收费。 额外的备份存储消耗量取决于个人数据库的工作负载和最大大小。 考虑实施下面一些优化技术，以减少备份存储消耗量：

• 根据需要将数据备份保持期缩短至最小。
• 避免以超过需要的频率执行大型写入操作，例如索引重建。
• 对于大规模数据加载操作，请考虑使用聚集列存储索引并遵循相关的最佳做法。 另外请考虑减少非聚集索引的数量。
• 在常规用途服务层级中，预配数据存储的价格低于备份存储的价格。 如果额外备份存储成本一直较高，可以考虑增大数据存储，以便节省备份存储的费用。
• 在应用程序逻辑中使用 tempdb 而不是永久性表来存储临时结果或暂时性数据。
• 尽可能使用本地冗余备份存储（例如开发/测试环境）。

备份保留期

Azure SQL 托管实例提供短期备份保留和长期备份保留。 短期保留允许在数据库的保留期内执行 PITR。 长期保留为各种合规性要求提供备份。

短期保留

对于所有新的、还原的和复制的数据库，Azure SQL 托管实例默认保留足够的备份以实现过去 7 天的 PITR。 此配置可更改，范围为 1 到 35 天。 服务定期执行完整备份、差异备份和日志备份，以确保数据库可还原到为数据库或托管实例定义的保留期内的任何时间点。

创建实例时，可为 STR 指定备份存储冗余选项，之后再对其进行更改。 如果在创建实例后更改备份冗余选项，新备份将使用新的冗余选项。 使用之前的 STR 冗余选项创建的备份副本不会被移动或复制。 它们将保留在原始存储帐户中，直到保持期已过。 如备份存储消耗量中所述，为启用 PITR 而存储的备份可能早于保持期，以确保精准的数据还原。

如果删除数据库，系统会保留数据库的备份至特定的保留期，与为任何一个联机数据库的保留方式一样。 但是，对于已删除的数据库，保留期会从 1-35 天更新为 0-35 天，从而可以手动删除备份。 如果需要将备份保留至超过 35 天的最长短期保留期，可以启用长期保留。

长期保留 (LTR)

借助 SQL 托管实例，可以在 Azure Blob 存储中配置存储最长 10 年的完整 LTR 备份。 配置启用 LTR 策略后，完整备份将自动复制到不同的存储容器。

为了满足不同的合规性要求，可为每周、每月和/或每年完整备份选择不同的保留期。 频率取决于策略。 例如，设置 W=0, M=1, Y=0 将会每月创建一个 LTR 副本。 有关 LTR 的详细信息，请参阅长期保留。

Azure SQL 托管实例中的 LTR 备份存储冗余继承自 STR 在定义 LTR 策略时使用的备份存储冗余。 即使 STR 备份存储冗余将来发生更改，你也无法更改此选项。

存储消耗量取决于所选的频率和 LTR 备份的保留期。 可以使用 LTR 定价计算器来估算 LTR 存储成本。

备份存储成本

Azure SQL 托管实例按累积值形式计算所有备份文件的总可计费备份存储。 每小时向 Azure 计费管道报告此值。 管道在每个月底聚合此每小时用量，以获取你的备份存储消耗量。

如果删除数据库，备份存储消耗量将逐渐降低，因为较早的备份会过期并被删除。 由于差异备份和日志备份需要早期的完整备份才可恢复，因此所有这三种备份类型会在每周都一并清除一次。 删除所有备份后，计费会停止。

备份存储的价格不同。 它取决于选择的备份存储冗余选项和你所在的区域。 备份存储按每月消耗的 GB 数收费，所有备份的费率相同。

备份存储冗余在以下方面影响备份成本：

• Locally redundant price = published price
• Zone-redundant price = published price x 1.25
• Geo-redundant price = published price x 2

有关定价，请查看 Azure SQL 托管实例定价页面。

对于托管实例，可计费备份存储总大小在实例级别进行聚合，计算方式如下：

Total billable backup storage size = (total size of full backups + total size of differential backups + total size of log backups) - maximum instance data storage

根据使用的备份存储冗余率，按每个区域每月消耗的 GB 数计算备份存储（如果有）总费用。 备份存储消耗量取决于各个数据库和托管实例的工作负载及大小。 经过大量修改的数据库具有相对较大的差异备份和日志备份，因为这些备份的大小与数据更改量成比例。 因此，此类数据库的备份费用会更高。

举个简单的例子，假设数据库累积了 744 GB 的备份存储，并且此数量因数据库完全空闲会在整个月内保持恒定。 若要将此累积存储消耗量转换为每小时用量，可将此数量除以 744.0（每月 31 天 * 每天 24 小时）。 SQL 托管实例将以固定速费率向 Azure 计费管道报告数据库每小时使用了 1 GB 的 PITR 备份。 Azure 计费服务将聚合此消耗量，并显示整月的用量为 744 GB。 成本基于你所在区域的每月 GB 费率。

再提供一个示例。 假设同一空闲数据库的保留期在当月的中途从 7 天增加到了 14 天。 这种增长会导致总备份存储翻倍至 1,488 GB。 SQL 托管实例将报告第 1 到 372 小时（上半月）的用量为每小时 1 GB。 它会报告第 373 到 744 小时（下半月）的用量为每小时 2 GB。 此用量将聚合到每月 1,116 GB 的最终帐单中。 保留成本不会立即增加， 而是每日逐渐增加，因为备份会不断增长，直到达到最长 14 天的保留期。

实际的备份计费方案更加复杂。 由于数据库中的变化率取决于工作负载并且随时间变化，因此每个差异备份和日志备份的大小也各不相同。 备份存储的每小时消耗量会相应地波动。

每个差异备份还包含自上次完成完整备份以来在数据库中做出的所有更改。 因此，所有差异备份的总大小会在一周内逐渐增加。 然后，在一系列较旧的完整备份、差异备份和日志备份老化后，该大小会急剧下降。

例如，假设在完成完整备份后，紧接着运行一个繁重的写入活动，例如索引重新生成。 那么，会包含该索引重新生成操作做出的以下修改：

• 在重新生成期间创建的事务日志备份中所做的修改。
• 在下一个差异备份中所做的修改。
• 在下一次进行完整备份之前在每个差异备份中所做的修改。

为了减小所有差异备份的大小，如果上次完整备份的时间超过 24 小时，超过 750 GB 且等于 75% 的数据库大小的超大差异备份将提升为完整备份。

加密备份

如果使用 TDE 加密了数据库，则备份（包括 LTR 备份）会自动静态加密。 默认情况下，Azure SQL 中所有新的数据库都配置为启用 TDE。 有关 TDE 的详细信息，请参阅使用 SQL 托管实例进行透明数据加密。

备份完整性

所有类型的数据库备份都提供 CHECKSUM 选项，以便增加备份完整度。 Azure SQL 工程团队对自动化数据库备份的自动测试目前不适用于 Azure SQL 托管实例。 围绕工作负载，在 SQL 托管实例中的数据库上计划测试备份还原和 DBCC CHECKDB。

尽管系统未验证备份的完整性，但备份仍内置了保护，如果备份服务出现问题，会向 Azure 发出警报。 此外，如果备份出现问题（例如未执行完整备份、备份服务停滞、日志备份已脱离 SLA，或者备份硬件或软件损坏），Azure 会向你提供支持。

使用 Azure Policy 强制实施备份存储冗余

如果根据数据驻留要求，你需要将所有数据保留在单个 Azure 区域中，建议使用 Azure Policy 为 SQL 托管实例强制实施区域冗余或本地冗余备份。

Azure Policy 是一项服务，可用于创建、分配和管理将规则应用于 Azure 资源的策略。 Azure Policy 可帮助你确保这些资源始终符合公司标准和服务级别协议。 有关详细信息，请参阅 Azure Policy 概述。

内置备份存储冗余策略

若要在组织级别强制实施数据驻留要求，可以使用 Azure 门户或 Azure PowerShell 将策略分配到订阅。 例如，如果在订阅或资源组级别分配以下内置策略，则订阅中的用户将无法通过 Azure 门户或 Azure PowerShell 创建具有异地冗余备份存储的托管实例：SQL 托管实例应避免使用 GRS 备份冗余。

有关 SQL 托管实例内置策略定义的完整列表，请查看策略参考。

合规性

如果默认保留期不满足合规性要求，可以更改 PITR 保留期。 有关详细信息，请参阅更改 PITR 备份保留期。

后续步骤

• 业务连续性概述
• 使用 Azure 门户管理长期备份保留
• 使用自动数据库备份进行恢复