自动备份

SQL 数据库自动创建数据库备份(保留 7 到 35 天),并使用 Azure 读取访问异地冗余存储 (RA-GRS),确保即使数据中心不可用也会保留这些备份。 这些备份是自动创建的,不收取额外的费用。 无需执行任何操作即可创建这些备份,还可更改备份保持期。 数据库备份是任何业务连续性和灾难恢复策略的基本组成部分,因为数据库备份可以保护数据免遭意外损坏或删除。 如果安全规则要求备份在较长时间(最长 10 年)内可用,可以配置长期保留.。

Note

本文介绍如何删除设备或服务中的个人数据,并且可为 GDPR 下的任务提供支持。 如需关于 GDPR 的常规信息,请参阅服务信任门户的 GDPR 部分

什么是 SQL 数据库备份?

SQL 数据库使用 SQL Server 技术创建完整差异事务日志备份,以便用于时间点还原 (PITR)。 一般每隔 5 - 10 分钟创建一次事务日志备份,每隔 12 小时创建一次差异备份,具体频率取决于计算大小和数据库活动量。 借助完整备份、差异备份和事务日志备份,可将数据库还原到托管数据库的同一服务器上的特定时间点。 备份存储在 RA-GRS 存储 blob 中,这些 blob 将复制到配对数据中心,以防止数据中心服务中断。 还原数据库时,服务会确定需要还原哪些完整、差异和事务日志备份。

可使用这些备份:

  • 在保留期内将数据库还原到某个时间点。 此操作会在与原始数据库相同的服务器中创建新数据库。
  • 将已删除的数据库还原到删除时的时间点或保留期内的任意时间点。 仅可在创建原始数据库所在的同一服务器中还原已删除的数据库。
  • 将数据库还原到其他地理区域。 在无法访问服务器和数据库的情况下,异地还原可帮助从地理位置灾难中恢复。 它会在全球任意位置的任意现有服务器中创建新数据库。
  • 如果为数据库配置了长期保留策略 (LTR),请从特定的长期备份还原数据库。 LTR 允许还原旧版本的数据库,以满足符合性请求或运行旧版本的应用程序。 有关详细信息,请参阅 长期保留
  • 若要执行还原,请参阅从备份还原数据库

Note

在 Azure 存储中,术语“复制”指将文件从一个位置复制到另一个位置。 SQL 数据库复制是指让多个辅助数据库与主数据库保持同步。

备份保留多长时间?

每个 SQL 数据库的默认备份保留期为 7 到 35 天,具体取决于购买模型和服务层。 可以在 Azure Logical Server 上更新数据库的备份保持期。 有关详细信息,请参阅更改备份保持期

如果删除了某个数据库,SQL 数据库以保存联机数据库的相同方式保存其备份。 例如,如果删除了保留期为 7 天的某个基本数据库,已保存 4 天的备份将继续保存 3 天。

如果需要备份保留时间超过最长的保持期,则可以修改备份属性,以向数据库添加一个或多个长期保持期。 有关详细信息,请参阅 长期保留

Important

如果删除了托管 SQL 数据库的 Azure SQL 服务器,则也会删除属于该服务器的所有弹性池和数据库,且不可恢复。 无法还原已删除的服务器。 但是,如果配置了长期保留,则不会删除具有 LTR 的数据库的备份,并且可以还原这些数据库。

默认备份保持期

基于 DTU 的购买模型

使用基于 DTU 的购买模型创建的数据库的默认保留期取决于服务层。

  • 基本服务层的保留期为 1 周。
  • 标准服务层的保留期为 5 周。
  • 高级服务层的保留期为 5 周。

基于 vCore 的购买模型

如果使用的是基于 vCore 的购买模型,则默认备份保持期为 7 天(适用于单一数据库、入池数据库)。 对于所有 Azure SQL 数据库(单一数据库、入池数据库),可以将备份保持期更改为最多 35 天

Warning

如果缩短当前保留期,早于新保留期的所有现有备份将不再可用。 如果延长当前保留期,SQL 数据库将保留现有备份,直至达到更长的保留期。

备份发生的频率

用于时间点还原的备份

SQL 数据库支持自助时间点还原 (PITR),可自动创建完整备份、差异备份和事务日志备份。 每周创建一次完整数据库备份,一般每隔 12 小时创建一次差异数据库备份,一般每隔 5 - 10 分钟创建一次事务日志备份,具体频率取决于计算大小和数据库活动量。 会在数据库创建后立即计划第一次完整备份。 完整备份通常可在 30 分钟内完成,但如果数据库很大,花费的时间可能更长。 例如,对已还原的数据库或数据库副本执行初始备份可能需要更长时间。 在完成首次完整备份后,在后台以静默方式自动计划和管理所有后续备份。 在平衡整体系统工作负荷时,SQL 数据库服务会确定所有数据库备份的确切时间。

PITR 备份是异地冗余的,受 Azure 存储跨区域复制的保护

有关详细信息,请参阅时间点还原

长期保留的备份

逻辑服务器中托管的 SQL 数据库提供了选项,用于在 Azure blob 存储中将完整备份的长期保留 (LTR) 配置为最多 10 年。 如果已启用 LTR 策略,每周完整备份将自动复制到不同的 RA-GRS 存储容器。 为了满足不同的符合性要求,可为每周、每月和/或每年备份选择不同的保留期。 存储消耗量取决于所选的备份频率和保留期。 可以使用 LTR 定价计算器来估算 LTR 存储成本。

与 PITR 一样,LTR 备份是异地冗余的,受 Azure 存储跨区域复制的保护。

有关详细信息,请参阅长期备份保留

备份是否已加密

如果使用 TDE 加密数据库,备份(包括 LTR 备份)会自动静态加密。 为 Azure SQL 数据库启用 TDE 时,也会加密备份。 默认情况下,所有新的 Azure SQL 数据库都配置为启用 TDE。 有关 TDE 的详细信息,请参阅使用 Azure SQL 数据库进行透明数据加密

Azure 如何确保备份完整性

Azure SQL 数据库工程团队持续不断地自动测试整个服务中数据库的自动数据库备份的还原。 还原后,数据库还会使用 DBCC CHECKDB 接收完整性检查。 在完整性检查期间发现的任何问题都将导致向工程团队发出警报。 有关 Azure SQL 数据库中数据完整性的详细信息,请参阅 Azure SQL 数据库中的数据完整性

自动备份如何影响符合性

将数据库从默认 PITR 保留期为 35 天的基于 DTU 的服务层迁移到基于 vCore 的服务层时,将保留 PITR 保留期以确保不会违反应用程序的数据恢复策略。 如果默认保留期不满足合规要求,可以使用 PowerShell 或 REST API 更改 PITR 保留期。 有关更多详细信息,请参阅更改备份保留期

Note

本文介绍如何删除设备或服务中的个人数据,并且可为 GDPR 下的任务提供支持。 如需关于 GDPR 的常规信息,请参阅服务信任门户的 GDPR 部分

如何更改 PITR 备份保持期

可以使用 PowerShell 或 REST API 更改默认 PITR 备份保持期。 支持的值包括:7、14、21、28 或 35 天。 以下示例演示如何将 PITR 保留期更改为 28 天。

Note

这些 API 只会影响 PITR 保留期。 如果为数据库配置了 LTR,LTR 不会受到影响。 有关如何更改 LTR 保留期的详细信息,请参阅长期保留

使用 PowerShell 更改 PITR 备份保留期

Set-AzureRmSqlDatabaseBackupShortTermRetentionPolicy -ResourceGroupName resourceGroup -ServerName testserver -DatabaseName testDatabase -RetentionDays 28

Important

从版本 4.7.0-preview 开始,AzureRM.Sql PowerShell 模块中已包含此 API。

使用 REST API 更改 PITR 保留期

示例请求

PUT https://management.chinacloudapi.cn/subscriptions/00000000-1111-2222-3333-444444444444/resourceGroups/resourceGroup/providers/Microsoft.Sql/servers/testserver/databases/testDatabase/backupShortTermRetentionPolicies/default?api-version=2017-10-01-preview

请求正文

{
  "properties":{  
      "retentionDays":28
   }
}

示例响应

状态代码:200

{
  "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
  }
}

有关详细信息,请参阅备份保留 REST API

后续步骤