你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
自动备份 - Azure SQL 数据库和 Azure SQL 托管实例
适用于：
Azure SQL 数据库 Azure SQL 托管实例
注意
本文介绍如何删除设备或服务中的个人数据，并且可用于为 GDPR 下的义务提供支持。 有关 GDPR 的常规信息，请参阅 Microsoft 信任中心的 GDPR 部分和服务信任门户的 GDPR 部分。
什么是数据库备份？
数据库备份是任何业务连续性和灾难恢复策略的基本组成部分，因为数据库备份可以保护数据免遭损坏或删除。 这些备份可在配置的保留期内将数据库还原到某个时间点。 如果数据保护规则要求备份在较长时间（最长 10 年）内可用，可以同时为单一数据库和共用数据库配置长期保留。
备份和还原概要
Azure SQL 托管实例中的数据库和 Azure SQL 数据库中的非超大规模数据库使用 SQL Server 引擎技术备份和还原数据。 超大规模数据库具有独特的体系结构，利用不同的技术进行备份和还原。 有关详细信息，请参阅超大规模备份和存储冗余。
备份频率
Azure SQL 数据库和 Azure SQL 托管实例都使用 SQL Server 技术，每周创建完整备份，每 12-24 小时创建差异备份，每 5 到 10 分钟创建事务日志备份。 事务日志备份的频率取决于计算大小和数据库活动量。
还原数据库时，服务会确定需要还原哪些完整备份、差异备份和事务日志备份。
超大规模数据库使用快照备份技术。
备份存储冗余
默认情况下，Azure SQL 数据库和 Azure SQL 托管实例将数据存储在复制到配对区域的异地冗余存储 Blob 中。 异地冗余有助于防止影响主区域备份存储的中断，并且你可在发生灾难时将服务器还原到其他区域。
配置备份存储冗余的选项提供了在本地冗余、区域冗余和异地冗余存储 blob 之间进行选择的灵活性。 若要确保数据位于部署托管实例或 Azure SQL 数据库中的数据库的同一区域中，可以更改默认的异地冗余备份存储冗余，并为备份配置本地冗余或区域冗余存储 blob。 Azure 存储冗余机制会存储数据的多个副本，以防范各种计划内和计划外的事件，包括暂时性的硬件故障、网络中断或断电、大范围自然灾害等。 配置的备份存储冗余同时应用于短期备份保留设置和长期保留备份，前者用于时间点还原 (PITR)，后者用于长期备份 (LTR)。
对于 Azure SQL 数据库，可以在创建数据库时配置备份存储冗余，也可以针对现有数据库更新备份存储冗余；对现有数据库所做的更改仅适用于将来的备份。 更新现有数据库的备份存储冗余后，最多可能需要 48 小时才能应用所做的更改。 在将数据库更新为使用本地或区域冗余存储时，将立即禁用异地还原。 对于超大规模数据库，所选的存储冗余选项将用于数据库的生存期，以同时实现数据存储冗余和备份存储冗余。 有关详细信息，请参阅超大规模备份和存储冗余。
重要
区域冗余存储目前仅在特定区域中可用。
备份使用情况
可使用这些备份：
- 现有数据库的时间点还原 - 通过使用 Azure 门户、Azure PowerShell、Azure CLI 或 REST API，将现有的数据库还原到过去的某个时间点。 对于 SQL 数据库，此操作会在与原始数据库相同的服务器上创建新的数据库，但会使用不同的名称，以避免覆盖原始数据库。 还原完成后，可删除原始数据库。 另外，可以重命名还原的数据库，然后使其具有原始数据库的名称。 同样，对于 SQL 托管实例，此操作可以在同一订阅和同一区域中的相同或不同的托管实例上创建数据库地副本。
- 删除的数据库的时间点还原 - 将已删除的数据库还原到删除时间或者还原到保留期内的任意时间点。 仅可在创建原始数据库所在的同一服务器或托管实例上还原已删除的数据库。 删除数据库时，该服务会在删除前执行最终事务日志备份，以防止任何数据丢失。
- 异地还原 - 将数据库还原到其他地理区域。 在无法访问主要区域中的数据库和备份时，异地还原可帮助从地理位置灾难中恢复。 它可在任何 Azure 区域中的任意现有服务器或托管实例上创建新的数据库。
重要
异地还原仅适用于配置了异地冗余备份存储的 Azure SQL 数据库中的数据库或托管实例。 如果当前没有对数据库使用异地复制的备份，可以通过配置备份存储冗余对此进行更改。
- 从长期备份保留 - 如果为数据库配置了长期保留策略 (LTR)，可从单一数据库或共用数据库的某个特定长期备份来还原数据库。 LTR 允许使用 Azure 门户、Azure CLI 或 Azure PowerShell 来还原旧版数据库，以满足合规性请求或运行旧版应用程序。 有关详细信息，请参阅 长期保留。
注意
在 Azure 存储中，术语“复制”指将 blob 从一个位置复制到另一个位置。 在 SQL 中，“数据库复制”指用于让多个辅助数据库与主数据库保持同步的各种技术。
还原 Azure SQL 数据库和 Azure SQL 托管实例的功能和特性
下表总结了时间点还原 (PITR)、异地还原和长期保留备份的功能和特性。
| 备份属性 | 时间点还原 (PITR) | 异地还原 | 长期备份还原 |
|---|---|---|---|
| SQL 备份类型 | 完整、差异、日志 | PITR 备份的复制副本 | 仅完整备份 |
| 恢复点目标 (RPO) | 5-10 分钟，基于计算大小和数据库活动量。 | 最多 1 小时，基于异地复制。* | 一周（或用户策略）。 |
| 恢复时间目标 (RTO) | 还原所用时间通常在 12 小时以内，但可能需要更长时间，具体取决于大小和活动。 请参阅恢复。 | 还原所用时间通常在 12 小时以内，但可能需要更长时间，具体取决于大小和活动。 请参阅恢复。 | 还原所用时间通常在 12 小时以内，但可能需要更长时间，具体取决于大小和活动。 请参阅恢复。 |
| 保留 | 默认为 7 天，最多 35 天 | 默认启用，与源相同。** | 默认情况下未启用，最长保留 10 年。 |
| Azure 存储 | 默认为异地冗余。 可以选择配置区域或本地冗余存储。 | 当 PITR 备份存储冗余设置为异地冗余时可用。 当 PITR 备份存储是区域或本地冗余存储时不可用。 | 默认为异地冗余。 可以配置区域或本地冗余存储。 |
| 用于在同一区域新建数据库 | 支持 | 支持 | 支持 |
| 用于在另一个区域新建数据库 | 不支持 | 任何 Azure 区域都支持 | 任何 Azure 区域都支持 |
| 用于在另一个订阅中新建数据库 | 不支持 | 不支持*** | 不支持*** |
| 通过 Azure 门户还原 | 是 | 是 | 是 |
| 通过 PowerShell 还原 | 是 | 是 | 是 |
| 通过 Azure CLI 还原 | 是 | 是 | 是 |
* 对于需要大型数据库且必须确保业务连续性的业务关键型应用程序，请使用自动故障转移组。
** 在默认情况下，所有 PITR 备份都存储在异地冗余存储中。 因此，默认情况下会启用异地还原。
*** 解决方法是还原到新服务器，并使用 Resource Move 将服务器移到另一个订阅。
从备份还原数据库
若要执行还原，请参阅从备份还原数据库。 可以参考下列示例尝试执行备份配置和还原操作：
| 操作 | 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 托管实例 |
备份计划
会在新的数据库创建或还原后立即计划第一次完整备份。 此备份通常可在 30 分钟内完成，但如果数据库较大，花费的时间可能更长。 例如，对已还原的数据库或数据库副本执行初始备份可能需要更长时间，该备份通常比新数据库还大。 在完成首次完整备份后，会自动计划和管理所有后续备份。 在平衡整体系统工作负荷时，SQL 数据库或 SQL 托管实例服务会确定所有数据库备份的确切时间。 不能更改备份作业的计划或者禁用备份作业。 超大规模使用不同的备份计划机制，请参阅超大规模备份计划，了解更多详细信息。
重要
对于新的、还原的或复制的数据库，从初始完整备份之后创建了初始事务日志备份时开始，可以使用时间点还原功能。
备份存储消耗量
如果使用 SQL Server 备份和还原技术，将数据库还原到某个时间点需要一个不间断的备份链，其中包括一个完整备份、可选的一个差异备份以及一个或多个事务日志备份。 Azure SQL 数据库和 Azure SQL 托管实例备份计划包括每周执行一次完整备份。 因此，要在整个保留期内提供 PITR，系统需要额外存储完整备份、差异备份和事务日志备份，且存储时间最多比配置的保留期长一周。
换句话说，对于保留期内的任何时间点，都需要具有早于保留期最早时间的完整备份，以及从该完整备份到下一次完整备份期前的差异备份和事务日志备份的不间断备份链。 超大规模数据库使用不同的备份计划机制，有关详细信息，请参阅超大规模备份计划，有关如何监视存储成本的更多详细信息，请参阅超大规模备份存储成本。
注意
要提供 PITR，额外备份的存储时间最多比配置的保留期长一周。 备份存储按与所有备份相同的费率收费。
将自动删除不再需要为提供 PITR 功能而保留的备份。 由于差异备份和日志备份需要早期的完整备份才可恢复，因此所有这三种备份类型会在每周都一并清除一次。
对于包括 TDE 加密数据库在内的所有数据库，将压缩备份，以减少未来的备份存储压缩需要和成本。 平均备份压缩率为 3-4 倍，但是，根据数据的性质以及数据库中是否启用了数据压缩，平均备份压缩率可能会显著降低或提高。
Azure SQL 数据库和 Azure SQL 托管实例按累积值形式计算使用的总备份存储量。 此值每隔一小时就会报告给 Azure 计费管道，该管道负责聚合此每小时用量，以便在每月底计算消耗量。 删除数据后，随着备份的过期以及删除，消耗量将减少。 删除所有备份后，PITR 不再可用，计费会停止。
重要
即使已删除数据库，为了提供 PITR，仍会保留数据库的备份。 删除和重建数据库可能会节省存储和计算成本，但可能会增加备份存储成本，因为该服务在每次删除数据库都时会保留每个已删除数据库的备份。
监视消耗情况
对于 Azure SQL 数据库中的 vCore 数据库，每种类型的备份（完整备份、差异备份和日志备份）所使用的存储量采用单独的指标在数据库监视窗格上进行报告。 下图显示了如何监视单一数据库的备份存储消耗情况。 此功能目前不适用于托管实例。
有关如何在超大规模中监视消耗的说明，请参阅超大规模监视备份消耗
微调备份存储消耗量
只要备份存储消耗量不超过数据库的最大数据大小，就不会对备份收费。 额外的备份存储消耗量取决于各个数据库的工作负荷和最大大小。 考虑实施下面一些优化技术，以减少备份存储消耗量：
- 将备份保留期减少到所需的最小值。
- 避免以超过需要的频率执行大型写入操作，例如索引重建。
- 对于大规模数据加载操作，请考虑使用聚集列存储索引以及下列相关最佳做法，和/或减少非聚集索引的数目。
- 在常规用途服务层级中，预配数据存储的价格低于备份存储的价格。 如果额外备份存储成本一直较高，可以考虑增大数据存储，以便节省备份存储的费用。
- 在应用程序逻辑中使用 TempDB 而不是永久性表来存储临时结果和/或暂时性数据。
- 尽可能使用本地冗余备份存储（例如开发/测试环境）
备份保留期
Azure SQL 数据库和 Azure SQL 托管实例同时提供短期和长期备份保留。 短期保留备份允许具有数据库保留期的时间点还原 (PITR)，而长期保留则为各种合规性要求提供备份。
短期保留
对于所有新的、还原和复制的数据库，Azure SQL 数据库和 Azure SQL 托管实例会默认保留足以实现过去七天的 PITR 的备份量。 定期执行完整备份、差异备份和日志备份，以确保数据库可还原到为数据库或托管实例定义的保留期内的任何时间点。 此外，对于 Azure SQL 数据库，差异备份可配置为 12 小时或 24 小时频率。
注意
24 小时差异备份频率可能会增加还原数据库所需的时间。
除了基本层数据库之外，可以按每个活动数据库更改备份保持期，更改幅度可为 1-35 天。 如备份存储消耗量中所述，为启用 PITR 而存储的备份可能早于保留期。 仅对于 Azure SQL 托管实例，在 0-35 天范围内删除了数据库后，可以设置 PITR 备份保留率。
注意
超大规模数据库的 1-35 天短期备份保留目前仅提供预览版。 若要了解更多信息，请参阅在超大规模中管理备份保留。
如果删除数据库，系统会保留数据库的备份至特定的保留期，与为任何一个联机数据库的保留方式一样。 不能更改已删除的数据库的备份保留期。
重要
如果删除服务器或托管实例，则该服务器或该托管实例上所有的数据库也会删除，且无法恢复。 无法还原已删除的服务器或托管实例。 但是，如果为数据库或托管实例配置了长期保留 (LTR)，则不会删除长期保留备份，并且可以使用它在同一订阅的另一个服务器或托管实例上将数据库还原到执行长期保留备份的时间点。
出于 PITR 目的，过去 1-35 天内的备份保留有时称为短期备份保留。 如果需要将备份保留至超过 35 天的最长短期保留期，可以启用长期保留。
长期保留
对于 SQL 数据库 SQL 托管实例，可以配置完整备份的长期保留 (LTR)，使其在 Azure Blob 存储中最长保存 10 年。 配置启用 LTR 策略后，每周完整备份将自动复制到不同的存储容器。 为了满足不同的合规性要求，可为每周、每月和/或每年完整备份选择不同的保留期。 存储消耗量取决于所选的频率和 LTR 备份的保留期。 可以使用 LTR 定价计算器来估算 LTR 存储成本。
重要
更新现有 Azure SQL 数据库的备份存储冗余，只适用于为数据库执行的未来备份。 数据库的所有现有 LTR 备份都将继续驻留在现有存储 blob 中，新备份将存储在请求的存储 blob 类型上。
有关 LTR 的详细信息，请参阅长期备份保留。
备份存储成本
备份存储的价格取决于购买模型（DTU 或 vCore）、选择的备份存储冗余选项以及区域。 备份存储按每月使用的 GB 数计费，有关定价的信息，请参阅 Azure SQL 数据库定价页和 Azure SQL 托管实例定价页。
有关购买模型的更多信息，请参阅在 vCore 和 DTU 购买模型之间进行选择。
注意
Azure 发票仅显示已使用的超额备份存储，而不显示整个备份存储消耗量。 例如，在假设场景中，如果已预配 4 TB 的数据存储，则会获得 4 TB 的可用备份存储空间。 如果使用的备份存储空间总数为 5.8 TB，Azure 发票将仅显示 1.8 TB，因为只对使用的超额备份存储收费。
DTU 模型
在 DTU 模型中，数据库和弹性池不会产生额外的备份存储费用。 备份存储的价格构成数据库或池价格的一部分。
vCore 模型
对于 SQL 数据库中的单一数据库，会提供与数据库最大数据存储大小 100% 相等的备份存储量，不收取额外的费用。 对于弹性池和托管实例，会分别提供与池的最大数据存储量或最大实例存储大小 100% 相等的备份存储量，不收取额外的费用。
对于单一数据库，可使用以下公式来计算可计费的备份存储总用量：
Total billable backup storage size = (size of full backups + size of differential backups + size of log backups) – maximum data storage
对于共用数据库，可计费的备份存储总大小在池级别进行聚合，计算方式如下：
Total billable backup storage size = (total size of all full backups + total size of all differential backups + total size of all log backups) - maximum pool data storage
对于托管实例，可计费备份存储总大小在实例级别进行聚合，计算方式如下：
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/月进行收费。 备份存储消耗量取决于各个数据库、弹性池以及托管实例的工作负荷和大小。 经过大量修改的数据库具有相对较大的差异备份和日志备份，因为这些备份的大小与数据更改量成比例。 因此，此类数据库的备份费用会更高。
有关用于计算超大规模数据库备份存储成本的公式，请参阅超大规模备份存储成本。
Azure SQL 数据库和 Azure SQL 托管实例按累积值形式计算所有备份文件的总可计费备份存储量。 此值每隔一小时就会报告给 Azure 计费管道，该管道聚合此每小时用量，以便在每月底获取备份存储消耗量。 如果删除数据库，备份存储消耗量将逐渐降低，因为较早的备份会过期并被删除。 由于差异备份和日志备份需要早期的完整备份才可恢复，因此所有这三种备份类型会在每周都一并清除一次。 当所有备份都被删除后，计费会停止。
举一个简化的示例，假设数据库累积了 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 的最终帐单中。
实际的备份计费方案更加复杂。 由于数据库中的变化率取决于工作负荷，并且会随时间而改变，因此每个差异备份和日志备份的大小也会随之改变，从而导致每小时备份存储消耗量出现相应波动。 此外，每个差异备份都包含自上次完整备份后数据库中的所有更改，因此，所有差异备份的总大小会在一周过程中逐渐增加，然后在早期的完整备份、差异备份和日志备份过期后急剧减少。例如，如果在完整备份完成后立即运行量较大的写入活动（如索引重新生成），则因重新生成索引所发生的修改将包含在重建期间获取的事务日志备份、下一个差异备份以及下一次完全备份发生之前执行的每个差异备份中。 如果在较大数据库中发生后一种情况，如果差异备份过大，则服务中的一项优化会导致创建完整备份而不是差异备份。 这会减少下一次完整备份之前的所有差异备份的大小。
如监视消耗情况中所述，可以监视每个备份类型（完整备份、差异备份、事务日志备份）随时间推移的总备份存储消耗量。
备份存储冗余
备份存储冗余按以下方式影响备份成本：
- 本地冗余价格 = x
- 区域冗余价格 = 1.25x
- 异地冗余价格 = 2x
有关备份存储定价的详细信息，请访问 Azure SQL 数据库定价页和 Azure SQL 托管实例定价页。
重要
只能在创建数据库期间为超大规模实例设置备份存储冗余。 预配资源后将无法修改此设置。 数据库复制过程可用于更新现有超大规模数据库的备份存储冗余设置。 有关详细信息，请参阅超大规模备份和存储冗余。
监视成本
若要了解备份存储成本，请转至 Azure 门户中的“成本管理 + 计费”，选择“成本管理”，然后选择“成本分析” 。 选择所需的订阅作为“范围”，然后筛选所需的时间段和服务，如下所示：
- 为“服务名称”添加筛选器。
- 在下拉列表中为单个数据库或弹性数据库池选择“SQL 数据库”，或为托管实例选择“SQL 托管实例”。
- 为“计量子类别”添加另一个筛选器。
- 要监视 PITR 备份成本，请在下拉列表中为单个数据库或弹性数据库池选择“单一/弹性池 PITR 备份存储”，或为托管实例选择“托管实例 PITR 备份存储”。 只有存在消耗时才会显示计量结果。
- 要监视 PITR 备份成本，请在下拉列表中为单个数据库或弹性数据库池选择“PITR 备份存储”，或为托管实例选择“SQL 托管实例 - LTR 备份存储”。 只有存在消耗时才会显示计量结果。
“存储”和“计算”子类别可能也会引起你的兴趣，但它们实际上与备份存储不相关。
重要
计量仅对当前正在使用的计数器可见。 如果某个计数器不可用，则可能当前未使用该类别。 例如，对于未部署托管实例的客户，将不会显示托管实例计数器。 同样，对于不消耗存储的资源，存储计数器也不可见。 例如，如果没有 PITR 或 LTR 备份存储消耗，则不会显示这些计量结果。
有关详细信息，请参阅 Azure SQL 数据库成本管理。
加密备份
如果使用 TDE 加密了数据库，则备份（包括 LTR 备份）会自动静态加密。 默认情况下，Azure SQL 中所有新的数据库都配置为启用 TDE。 有关 TDE 的详细信息，请参阅使用 SQL 数据库和 SQL 托管实例进行透明数据加密。
备份完整性
Azure SQL 工程团队持续不断地自动测试自动数据库备份的还原。 （此测试目前在 SQL 托管实例中不可用。你应该针对 SQL 托管实例中的数据库计划 DBCC CHECKDB，根据你的工作负载来进行计划。）
完成时间点还原后，数据库还会接受 DBCC CHECKDB 完整性检查。
在完整性检查期间发现的任何问题都将导致向工程团队发出警报。 有关详细信息，请参阅 SQL 数据库中的数据完整性。
所有类型的数据库备份都提供 CHECKSUM 选项，以便增加备份完整度。
合规性
将数据库从基于 DTU 的服务层级迁移到基于 vCore 的服务层级时，将保留 PITR 保留期以确保不会违反应用程序的数据恢复策略。 如果默认保留期不满足合规性要求，可以更改 PITR 保留期。 有关详细信息，请参阅更改 PITR 备份保留期。
注意
本文介绍如何删除设备或服务中的个人数据，并且可用于为 GDPR 下的义务提供支持。 有关 GDPR 的常规信息，请参阅 Microsoft 信任中心的 GDPR 部分和服务信任门户的 GDPR 部分。
更改短期保留策略
可以使用 Azure 门户、PowerShell 或 REST API 更改默认 PITR 备份保留期和差异备份频率。 以下示例演示如何将 PITR 保留期更改为 28 天，以及将差异备份更改为 24 小时间隔。
警告
如果缩短当前的保留期，则无法还原到早于新保留期的时间点。 会删除新保留期内不再需要为提供 PITR 而保留的备份。 如果延长当前的保留期，则无法立即在新的保留期内获得恢复到旧时间点的能力。 随着时间推移，你将获得这一能力，因为系统开始将备份保留更长时间。
注意
这些 API 只影响 PITR 保留期。 如果为数据库配置了 LTR，LTR 不会受到影响。 有关如何更改 LTR 保留期的信息，请参阅长期保留。
使用 Azure 门户更改短期保留策略
若要通过使用 Azure 门户更改活动数据库的 PITR 备份保留期或差异备份频率，请转到具有要更改保留期的数据库的服务器或托管实例。 在左窗格中选择“备份”，然后选择“保留策略”选项卡。选择想要为其更改 PITR 备份保留期的数据库。 然后，从操作栏中选择“配置保留期”。
使用 Azure CLI 更改短期保留策略
为 Azure CLI 准备环境。
在 Azure Cloud Shell 中使用 Bash 环境。 有关详细信息，请参阅 Azure Cloud Shell 快速入门 - Bash。
如需在本地运行 CLI 参考命令，请安装 Azure CLI。 如果在 Windows 或 macOS 上运行，请考虑在 Docker 容器中运行 Azure CLI。 有关详细信息，请参阅如何在 Docker 容器中运行 Azure CLI。
如果使用的是本地安装，请使用 az login 命令登录到 Azure CLI。 若要完成身份验证过程，请遵循终端中显示的步骤。 有关其他登录选项，请参阅登录 Azure CLI。
出现提示时，请在首次使用时安装 Azure CLI 扩展。 有关扩展详细信息，请参阅使用 Azure CLI 的扩展。
运行 az version 以查找安装的版本和依赖库。 若要升级到最新版本，请运行 az upgrade。
使用以下示例更改活动 Azure SQL 数据库的 PITR 备份保留期和差异备份频率。
# Set new PITR differential backup frequency on an active individual database
# Valid backup retention must be between 1 and 35 days
# Valid differential backup frequency must be ether 12 or 24
az sql db str-policy set \
--resource-group myresourcegroup \
--server myserver \
--name mydb \
--retention-days 28 \
--diffbackup-hours 24
使用 PowerShell 更改短期保留策略
注意
本文使用 Azure Az PowerShell 模块，这是与 Azure 交互时推荐使用的 PowerShell 模块。 若要开始使用 Az PowerShell 模块，请参阅安装 Azure PowerShell。 若要了解如何迁移到 Az PowerShell 模块，请参阅 将 Azure PowerShell 从 AzureRM 迁移到 Az。
重要
PowerShell AzureRM 模块仍受 SQL 数据库和 SQL 托管实例的支持，但所有未来的开发都是针对 Az.Sql 模块的。 有关详细信息，请参阅 AzureRM.Sql。 Az 模块和 AzureRm 模块中的命令参数大体上是相同的。
若要更改活动 Azure SQL 数据库的 PITR 备份保留或差异备份频率，请使用以下 PowerShell 示例。
# SET new PITR backup retention period on an active individual database
# Valid backup retention must be between 1 and 35 days
Set-AzSqlDatabaseBackupShortTermRetentionPolicy -ResourceGroupName resourceGroup -ServerName testserver -DatabaseName testDatabase -RetentionDays 28
# SET new PITR differential backup frequency on an active individual database
# Valid differential backup frequency must be ether 12 or 24.
Set-AzSqlDatabaseBackupShortTermRetentionPolicy -ResourceGroupName resourceGroup -ServerName testserver -DatabaseName testDatabase -RetentionDays 28 -DiffBackupIntervalInHours 24
使用 REST API 更改短期保留策略
以下请求将保留期更新为 28 天，还将差异备份频率设置为 24 小时。
示例请求
PUT https://management.azure.com/subscriptions/00000000-1111-2222-3333-444444444444/resourceGroups/resourceGroup/providers/Microsoft.Sql/servers/testserver/databases/testDatabase/backupShortTermRetentionPolicies/default?api-version=2021-02-01-preview
请求正文
{
"properties":{
"retentionDays":28,
"diffBackupIntervalInHours":24
}
}
示例响应：
{
"id": "/subscriptions/00000000-1111-2222-3333-444444444444/providers/Microsoft.Sql/resourceGroups/resourceGroup/servers/testserver/databases/testDatabase/backupShortTermRetentionPolicies/default",
"name": "default",
"type": "Microsoft.Sql/resourceGroups/servers/databases/backupShortTermRetentionPolicies",
"properties": {
"retentionDays": 28,
"diffBackupIntervalInHours":24
}
}
有关详细信息，请参阅备份保持期 REST API。
超大规模备份和存储冗余
Azure SQL 数据库中的超大规模数据库使用具有高度可缩放的存储和计算性能层的独特体系结构。
超大规模备份是基于快照的，几乎是即时的。 生成的日志被存储在备份保持期的长期 Azure 存储中。 超大规模体系结构不使用完整数据库备份或日志备份，因此本文前面部分介绍的备份频率、存储成本、计划、存储和冗余以及还原功能不适用。
超大规模备份和还原性能
存储和计算分离使超大规模能够将备份和还原操作推送到存储层，以减少主要计算副本的处理负担。 因此，数据库备份不会影响主计算节点的性能。
由于使用了存储快照，无论数据大小如何，超大规模数据库的备份和还原操作都能快速完成。 数据库可以还原到数据库备份保留期内的任意时间点。 时点恢复 (PITR) 是通过还原到文件快照来实现的，因此规模不像数据操作那样大。 还原同一 Azure 区域内的超大规模数据库是一项时间恒定的操作，即使是若干 TB 的数据库也能在数分钟内还原，而无需几个小时甚至几天。 通过还原现有备份或复制数据库创建新数据库的过程也利用了此功能：创建数据库副本用于开发或测试目的，即使是数 TB 的数据库，也能在数分钟内创建完成（在使用相同存储类型时在同一区域内）。
超大规模备份保留
超大规模数据库的默认短期备份保留 (STR) 为 7 天；目前不支持长期保留 (LTR) 策略。
注意
超大规模数据库长达 35 天的短期备份保留目前仅提供预览版。
超大规模备份计划
对于超大规模数据库，没有传统的完整、差异和事务日志备份。 但拍摄了数据文件的定期存储快照。 生成的事务日志会按原样保留，时长为配置的保留期。 还原时，相关事务日志记录会应用于已还原的存储快照，这会得到事务一致的数据库，且自保留期中指定的时间点起没有任何数据丢失。
超大规模备份存储成本
超大规模备份存储成本取决于区域和备份存储冗余。 还取决于工作负载类型。 写入密集型的工作负载更可能频繁更改数据页面，从而导致存储快照更大。 此类工作负载还会生成更多事务日志，从而增加整体备份成本。 备份存储按每月使用的 GB 数计费，有关定价的信息，请参阅 Azure SQL 数据库定价页。
对于超大规模，可计费备份存储的计算方式如下：
Total billable backup storage size = (Data backup storage size + Log backup storage size)
数据存储大小不属于可计费备份，因为它已作为分配的数据库存储计费。
已删除的超大规模数据库会产生备份成本，以便恢复至删除前的某个时间点。 对于已删除的超大规模数据库，可计费备份存储的计算方式如下：
Total billable backup storage size for deleted Hyperscale database = (Data storage size + Data backup size + Log backup storage size) * (remaining backup retention period after deletion/configured backup retention period)
数据存储大小包含在公式中，因为分配的数据库存储不会因已删除的数据库单独计费。 对于已删除的数据库，数据会在删除后存储，以便在配置的备份保留期内进行恢复。 已删除的数据库的可计费备份存储在删除后会不断逐渐减少。 它变为零表示不再保留备份且不再可能进行恢复。 但如果是永久删除且不再需要备份，可以在删除数据库之前减少保留，以降低成本。
超大规模监视备份消耗
在超大规模中，通过 Azure Monitor 指标报告数据备份存储大小（快照备份大小）、数据存储大小（数据库大小）和日志备份存储大小（事务日志备份大小）。
若要在 Azure 门户中查看备份和数据存储指标，请执行以下步骤：
- 转到要监视其备份和数据存储指标的超大规模数据库。
- 在“监视”部分中选择“指标”页。
- 从“指标”下拉列表中，选择“数据备份存储”和“日志备份存储”指标，以及相应的聚合规则。
减少备份存储消耗
超大规模数据库的备份存储消耗取决于保留期、区域选择、备份存储冗余和工作负载类型。 请考虑使用以下优化技术来减少超大规模数据库的备份存储消耗：
- 将备份保留期减少到所需的最小值。
- 避免频繁执行不必要的大型写入操作（如索引维护）。 若要了解有关索引维护的建议，请参阅优化索引维护以提高查询性能并减少资源消耗。
- 对于大型数据加载操作，请考虑在适当时使用数据压缩。
- 在应用程序逻辑中使用
tempdb而不是永久性表来存储临时结果和/或暂时性数据。 - 不需要异地还原功能时（例如开发/测试环境），请使用本地冗余或区域冗余备份存储。
超大规模存储冗余同时适用于数据存储和备份存储
超大规模支持可配置的存储冗余。 在创建超大规模数据库时，可以选择首选的存储类型：读取访问异地冗余存储 (RA-GRS)、区域冗余存储 (ZRS) 或本地冗余存储 (LRS) Azure 标准存储。 所选存储冗余选项将在数据库的整个生存期内使用，以同时实现数据存储冗余和备份存储冗余。
在创建超大规模数据库时，请仔细考虑存储冗余
只能在创建数据库期间为超大规模数据库设置备份存储冗余。 预配资源后将无法修改此设置。 只有在为备份存储冗余选择了异地冗余存储 (RA-GRS) 时，异地还原才可用。 数据库复制过程可用于更新现有超大规模数据库的存储冗余设置。 将数据库复制到其他存储类型，将是一个数据大小的操作。 在配置备份存储冗余中查找示例代码。
重要
区域冗余存储目前仅在特定区域中可用。
将超大规模数据库还原到其他区域
如果在执行灾难恢复操作或演练、重新定位期间或者出于任何其他原因，需要将 Azure SQL 数据库中的某个超大规模数据库还原到其他位置（而不是其当前所在位置），主要方法是执行数据库的异地还原。 异地还原所涉及的步骤与将 SQL 数据库中任何其他数据库还原到其他区域的步骤完全相同：
- 如果目标区域中没有适当的服务器，请在其中创建一个服务器。 此服务器应该由原始（源）服务器的同一个订阅拥有。
- 请遵照有关从自动备份还原 Azure SQL 数据库中数据库的页面上的异地还原部分中的说明操作。
注意
由于源与目标位于不同的区域，因此数据库无法像在非异地还原方案中一样与源数据库共享快照存储，而非异地还原可以快速完成，无论数据库大小如何。 异地还原超大规模数据库属于一种与数据大小相关的操作，即使目标位于异地复制存储的配对区域中。 因此，异地还原需要的时间与所要还原的数据库的大小成正比。 如果目标位于配对区域中，数据传输将会位于某个区域内，这将会比跨区域数据传输快得多，但它仍将是与数据大小相关的操作。
如果你愿意，也可以将数据库复制到不同的区域。 了解用于超大规模的数据库复制。
配置备份存储冗余
可以在创建数据库时配置 Azure SQL 数据库中的数据库的备份存储冗余，也可以针对现有数据库更新备份存储冗余；对现有数据库所做的更改仅适用于将来的备份。 默认值为异地冗余存储。 有关本地冗余、区域冗余和异地冗余备份存储的定价差异，请访问托管实例定价页。 超大规模数据库的存储冗余是唯一的：有关详细信息，请参阅超大规模备份和存储冗余。
对于 Azure SQL 托管实例，在实例级别设置备份存储冗余，并应用于所有所属托管数据库。 它可以在创建实例时进行配置，也可以针对现有实例进行更新；备份存储冗余更改将触发每个数据库的新完整备份，并且更改将应用于所有未来的备份。 默认存储冗余类型是异地冗余 (RA-GRS)。
使用 Azure 门户配置备份存储冗余
使用 Azure CLI 配置备份存储冗余
若要在创建新数据库时配置备份存储冗余，可以使用 az sql db create 命令指定 --backup-storage-redundancy 参数。 可能值为 Geo、Zone 和 Local。 默认情况下，Azure SQL 数据库中的所有数据库均使用异地冗余存储进行备份。 如果使用本地或区域冗余备份存储创建或更新数据库，则会禁用异地还原。
下面的示例在具有本地备份冗余的常规用途服务层中创建数据库：
az sql db create \
--resource-group myresourcegroup \
--server myserver \
--name mydb \
--tier GeneralPurpose \
--backup-storage-redundancy Local
在创建超大规模数据库时，请仔细考虑 --backup-storage-redundancy 的配置选项。 对于超大规模数据库，存储冗余只能在数据库创建过程中指定。 所选的存储冗余选项将用于数据库的生存期，以同时实现数据存储冗余和备份存储冗余。 有关详细信息，请参阅超大规模备份和存储冗余。
现有超大规模数据库可以使用数据库复制或时间点还原迁移到不同的存储冗余：本部分中复制超大规模数据库的示例代码如下。
下面的示例在具有区域冗余的超大规模服务层中创建数据库：
az sql db create \
--resource-group myresourcegroup \
--server myserver \
--name mydb \
--tier Hyperscale \
--backup-storage-redundancy Zone
有关详细信息，请参阅 az sql db create 和 az sql db update。
除了超大规模数据库和基本层数据库之外，可以使用 --backup-storage-redundancy 参数和 az sql db update 命令更新现有数据库的备份存储冗余设置。 在数据库上应用更改可能需要 48 小时。 从异地冗余备份存储切换到本地或区域冗余存储会禁用异地还原。
下面的示例代码将备份存储冗余更改为 Local。
az sql db update \
--resource-group myresourcegroup \
--server myserver \
--name mydb \
--backup-storage-redundancy Local
不能直接更新超大规模数据库的备份存储冗余。 但是，可以将数据库复制命令与 --backup-storage-redundancy 参数一起使用，以实现更改。 下面的示例使用第 5 代硬件和两个 vCore 将超大规模数据库复制到新数据库。 新数据库的备份冗余设置为 Zone。
az sql db copy \
--resource-group myresourcegroup \
--server myserver
--name myHSdb
--dest-resource-group mydestresourcegroup
--dest-server destdb
--dest-name myHSdb
--service-objective HS_Gen5_2
--read-replicas 0
--backup-storage-redundancy Zone
有关语法详细信息，请参阅 az sql db copy。 有关数据库复制的概述，请访问复制 Azure SQL 数据库中数据库的事务一致性副本。
使用 PowerShell 配置备份存储冗余
若要在创建新数据库时配置备份存储冗余，可以使用 New-AzSqlDatabase cmdlet 指定 -BackupStorageRedundancy 参数。 可能值为 Geo、Zone 和 Local。 默认情况下，Azure SQL 数据库中的所有数据库均使用异地冗余存储进行备份。 如果使用本地或区域冗余备份存储创建数据库，则会禁用异地还原。
下面的示例在具有本地备份冗余的常规用途服务层中创建数据库：
# Create a new database with geo-redundant backup storage.
New-AzSqlDatabase -ResourceGroupName "ResourceGroup01" -ServerName "Server01" -DatabaseName "Database03" -Edition "GeneralPurpose" -Vcore 2 -ComputeGeneration "Gen5" -BackupStorageRedundancy Local
在创建超大规模数据库时，请仔细考虑 --backup-storage-redundancy 的配置选项。 对于超大规模数据库，存储冗余只能在数据库创建过程中指定。 所选的存储冗余选项将用于数据库的生存期，以同时实现数据存储冗余和备份存储冗余。 有关详细信息，请参阅超大规模备份和存储冗余。
现有数据库可以使用数据库复制或时间点还原迁移到不同的存储冗余：本部分中复制超大规模数据库的示例代码如下。
下面的示例在具有区域冗余的超大规模服务层中创建数据库：
# Create a new database with geo-redundant backup storage.
New-AzSqlDatabase -ResourceGroupName "ResourceGroup01" -ServerName "Server01" -DatabaseName "Database03" -Edition "Hyperscale" -Vcore 2 -ComputeGeneration "Gen5" -BackupStorageRedundancy Zone
有关语法详细信息，请访问 New-AzSqlDatabase。
除了超大规模数据库和基本层数据库之外，可以将 -BackupStorageRedundancy 参数与 Set-AzSqlDatabase cmdlet 一起使用来更新现有数据库的备份存储冗余设置。 可能的值为异地、区域和本地。 在数据库上应用更改可能需要 48 小时。 从异地冗余备份存储切换到本地或区域冗余存储会禁用异地还原。
下面的示例代码将备份存储冗余更改为 Local。
# Change the backup storage redundancy for Database01 to zone-redundant.
Set-AzSqlDatabase -ResourceGroupName "ResourceGroup01" -DatabaseName "Database01" -ServerName "Server01" -BackupStorageRedundancy Local
有关详细信息，请访问 Set-AzSqlDatabase
不能更新现有超大规模数据库的备份存储冗余。 但是，可以使用数据库复制命令创建数据库的副本，并使用 -BackupStorageRedundancy 参数更新备份存储冗余。 下面的示例使用第 5 代硬件和两个 vCore 将超大规模数据库复制到新数据库。 新数据库的备份冗余设置为 Zone。
# Change the backup storage redundancy for Database01 to zone-redundant.
New-AzSqlDatabaseCopy -ResourceGroupName "ResourceGroup01" -ServerName "Server01" -DatabaseName "HSSourceDB" -CopyResourceGroupName "DestResourceGroup" -CopyServerName "DestServer" -CopyDatabaseName "HSDestDB" -Vcore 2 -ComputeGeneration "Gen5" -ComputeModel Provisioned -BackupStorageRedundancy Zone
有关语法详细信息，请访问 New-AzSqlDatabaseCopy。
有关数据库复制的概述，请访问复制 Azure SQL 数据库中数据库的事务一致性副本。
注意
若要将 -BackupStorageRedundancy 参数与数据库还原、数据库复制或创建辅助操作一起使用，请使用 Azure PowerShell 版本 Az.Sql 2.11.0。
使用 Azure Policy 强制实施备份存储冗余
如果根据数据驻留要求，你需要将所有数据保留在单个 Azure 区域中，你可能希望使用 Azure Policy 为 SQL 数据库或托管实例强制实施区域冗余或本地冗余备份。 Azure Policy 是一项服务，可用于创建、分配和管理将规则应用于 Azure 资源的策略。 Azure Policy 可帮助你确保这些资源始终符合公司标准和服务级别协议。 有关详细信息，请参阅 Azure Policy 概述。
内置备份存储冗余策略
添加了以下新的内置策略，你可以在订阅或资源组级别分配这些策略，以阻止创建具有异地冗余备份存储的新数据库或实例。
此处提供了 SQL 数据库和托管实例内置策略定义的完整列表。
若要在组织级别强制实施数据驻留要求，可以将这些策略分配到订阅。 在订阅级别分配这些策略后，指定订阅中的用户将无法通过 Azure 门户或 Azure PowerShell 创建具有异地冗余备份存储的数据库或托管实例。
重要
通过 T-SQL 创建数据库时，不会强制实施 Azure 策略。 若要在使用 T-SQL 创建数据库时强制数据驻留，请使用“LOCAL”或“ZONE”作为 CREATE DATABASE 语句中 BACKUP_STORAGE_REDUNDANCY 参数的输入。
了解如何使用 Azure 门户或 Azure PowerShell 分配策略
后续步骤
- 数据库备份是任何业务连续性和灾难恢复策略的基本组成部分，因为数据库备份可以保护数据免遭意外损坏或删除。 若要了解其他 SQL 数据库业务连续性解决方案，请参阅业务连续性概述。
- 有关如何使用 Azure 门户配置和管理 Azure Blob 存储中的自动备份的长期保留，并从这些备份进行还原的信息，请参阅使用 Azure 门户管理长期备份保留。
- 有关如何使用 PowerShell 配置和管理 Azure Blob 存储中的自动备份的长期保留，并从这些备份进行还原的信息，请参阅使用 PowerShell 管理长期备份保留。
- 获取有关如何使用 Azure 门户将数据库还原到某个时间点的详细信息。
- 获取有关如何使用 PowerShell 将数据库还原到某个时间点的详细信息。
- 若要详细了解有关 Azure SQL 托管实例上的备份存储消耗量，请参阅托管实例上的备份存储消耗量说明。
- 若要了解如何优化 Azure SQL 托管实例的备份存储保留和成本，请参阅优化托管实例的备份存储成本。