自动备份Automated backups

SQL 数据库自动创建数据库备份(保留持续时间为配置的保留期),并使用 Azure 读取访问异地冗余存储 (RA-GRS),确保即使数据中心不可用也会保留这些备份。SQL Database automatically creates the database backups that are kept for the duration of the configured retention period, and uses Azure read-access geo-redundant storage (RA-GRS) to ensure that they are preserved even if the data center is unavailable. 这些备份是自动创建的。These backups are created automatically. 数据库备份是任何业务连续性和灾难恢复策略的基本组成部分,因为数据库备份可以保护数据免遭意外损坏或删除。Database backups are an essential part of any business continuity and disaster recovery strategy because they protect your data from accidental corruption or deletion. 如果安全规则要求备份在较长时间(最长 10 年)内可用,可以在单一数据库和弹性池中配置长期保留If your security rules require that your backups are available for an extended period of time (up to 10 years), you can configure a long-term retention on Singleton databases and Elastic pools.

备注

本文介绍如何删除设备或服务中的个人数据,并且可为 GDPR 下的任务提供支持。This article provides steps for how to delete personal data from the device or service and can be used to support your obligations under the GDPR. 如需关于 GDPR 的常规信息,请参阅服务信任门户的 GDPR 部分If you're looking for general info about GDPR, see the GDPR section of the Service Trust portal.

什么是 SQL 数据库备份?What is a SQL Database backup

SQL 数据库使用 SQL Server 技术,每周创建完整备份,每 12 小时创建差异备份,每 5-10 分钟创建事务日志备份SQL Database uses SQL Server technology to create full backups every week, differential backups every 12 hours, and transaction log backups every 5-10 minutes. 备份存储在 RA-GRS 存储 blob 中,这些 blob 将复制到配对数据中心,以防止数据中心服务中断。The backups are stored in RA-GRS storage blobs that are replicated to a paired data center for protection against a data center outage. 还原数据库时,服务会确定需要还原哪些完整、差异和事务日志备份。When you restore a database, the service figures out which full, differential, and transaction log backups need to be restored.

可使用这些备份:You can use these backups to:

  • 使用 Azure 门户、Azure PowerShell、Azure CLI 或 REST API 将现有的数据库还原到过去的某个时间点(在保留期内)。Restore an existing database to a point-in-time in the past within the retention period using the Azure portal, Azure PowerShell, Azure CLI, or REST API. 在单一数据库和弹性池中,此操作会在与原始数据库相同的服务器中创建新数据库。In Single database and Elastic pools, this operation will create a new database in the same server as the original database. 在“托管实例”中,此操作可以创建数据库的一个副本,或者创建在同一订阅下的相同或不同托管实例。In Managed Instance, this operation can create a copy of the database or same or different Managed Instance under the same subscription.
  • 将已删除的数据库还原到删除时的时间点或保留期内的任意时间。Restore a deleted database to the time it was deleted or anytime within the retention period. 仅可在创建原始数据库所在的同一逻辑服务器或托管实例中还原已删除的数据库。The deleted database can only be restored in the same logical server or Managed Instance where the original database was created.
  • 将数据库还原到其他地理区域Restore a database to another geographical region. 在无法访问服务器和数据库的情况下,异地还原可帮助从地理位置灾难中恢复。Geo-restore allows you to recover from a geographic disaster when you cannot access your server and database. 它会在全球任意位置的任意现有服务器中创建新数据库。It creates a new database in any existing server anywhere in the world.
  • 如果为数据库配置了长期保留策略 (LTR),请在单一数据库或弹性池中从特定的长期备份还原数据库Restore a database from a specific long-term backup on Single Database or Elastic Pool if the database has been configured with a long-term retention policy (LTR). LTR 允许使用 Azure 门户Azure PowerShell 还原旧版本的数据库,以满足符合性请求或运行旧版本的应用程序。LTR allows you to restore an old version of the database using the Azure portal or Azure PowerShell to satisfy a compliance request or to run an old version of the application. 有关详细信息,请参阅 长期保留For more information, see Long-term retention.
  • 若要执行还原,请参阅从备份还原数据库To perform a restore, see restore database from backups.

备注

在 Azure 存储中,术语“复制”指将文件从一个位置复制到另一个位置 。In Azure storage, the term replication refers to copying files from one location to another. SQL 数据库复制是指让多个辅助数据库与主数据库保持同步 。SQL's database replication refers to keeping multiple secondary databases synchronized with a primary database.

可以使用以下示例尝试这其中的部分操作:You can try some of these operations using the following examples:

Azure 门户The Azure portal Azure PowerShellAzure PowerShell
更改备份保留Change backup retention 单一数据库Single Database
托管实例Managed Instance
单一数据库Single Database
托管实例Managed Instance
更改长期备份保留Change Long-term backup retention 单一数据库Single database
托管实例 - 不可用Managed Instance - N/A
单一数据库Single Database
托管实例 - 不可用Managed Instance - N/A
从时间点还原数据库Restore database from point-in-time 单一数据库Single database 单一数据库Single database
托管实例Managed Instance
还原已删除的数据库Restore deleted database 单一数据库Single database 单一数据库Single database
托管实例Managed Instance
从 Azure Blob 存储还原数据库Restore database from Azure Blob Storage 单一数据库 - 不可用Single database - N/A
托管实例 - 不可用Managed Instance - N/A
单一数据库 - 不可用Single database - N/A
托管实例Managed Instance

备份频率Backup frequency

时间点还原Point-in-time restore

SQL 数据库支持自助时间点还原 (PITR),可自动创建完整备份、差异备份和事务日志备份。SQL Database supports self-service for point-in-time restore (PITR) by automatically creating full backup, differential backups, and transaction log backups. 每周创建一次完整数据库备份,一般每隔 12 小时创建一次差异数据库备份,一般每隔 5 - 10 分钟创建一次事务日志备份,具体频率取决于计算大小和数据库活动量。Full database backups are created weekly, differential database backups are generally created every 12 hours, and transaction log backups are generally created every 5 - 10 minutes, with the frequency based on the compute size and amount of database activity. 会在数据库创建后立即计划第一次完整备份。The first full backup is scheduled immediately after a database is created. 完整备份通常可在 30 分钟内完成,但如果数据库很大,花费的时间可能更长。It usually completes within 30 minutes, but it can take longer when the database is of a significant size. 例如,对已还原的数据库或数据库副本执行初始备份可能需要更长时间。For example, the initial backup can take longer on a restored database or a database copy. 在完成首次完整备份后,在后台以静默方式自动计划和管理所有后续备份。After the first full backup, all further backups are scheduled automatically and managed silently in the background. 在平衡整体系统工作负荷时,SQL 数据库服务会确定所有数据库备份的确切时间。The exact timing of all database backups is determined by the SQL Database service as it balances the overall system workload. 不能更改或禁用备份作业。You cannot change or disable the backup jobs.

PITR 备份通过异地冗余存储进行保护。The PITR backups are protected with geo-redundant storage. 有关详细信息,请参阅 Azure 存储冗余For more information, see Azure Storage redundancy.

有关详细信息,请参阅时间点还原For more information, see Point-in-time restore

长期保留Long-term retention

单一数据库和共用数据库提供选项,用于在 Azure Blob 存储中将完整备份的长期保留 (LTR) 配置为最多 10 年。Single and pooled databases offer the option of configuring long-term retention (LTR) of full backups for up to 10 years in Azure Blob storage. 如果已启用 LTR 策略,每周完整备份将自动复制到不同的 RA-GRS 存储容器。If LTR policy is enabled, the weekly full backups are automatically copied to a different RA-GRS storage container. 为了满足不同的符合性要求,可为每周、每月和/或每年备份选择不同的保留期。To meet different compliance requirement, you can select different retention periods for weekly, monthly and/or yearly backups. 存储消耗量取决于所选的备份频率和保留期。The storage consumption depends on the selected frequency of backups and the retention period(s). 可以使用 LTR 定价计算器来估算 LTR 存储成本。You can use the LTR pricing calculator to estimate the cost of LTR storage.

与 PITR 一样,LTR 备份通过异地冗余存储进行保护。Like PITR, the LTR backups are protected with geo-redundant storage. 有关详细信息,请参阅 Azure 存储冗余For more information, see Azure Storage redundancy.

有关详细信息,请参阅长期备份保留For more information, see Long-term backup retention.

备份存储消耗量Backup storage consumption

对于单一数据库,备份存储总用量的计算方式如下:For single databases, the total backup storage usage is calculated as follows:
Total backup storage size = (size of full backups + size of differential backups + size of log backups) - database sizeTotal backup storage size = (size of full backups + size of differential backups + size of log backups) - database size.

对于弹性池,备份存储总大小将在池级别聚合,计算方式如下:For elastic pools, the total backup storage size is aggregated at the pool level and is calculated as follows:
Total backup storage size = (total size of all full backups + total size of all differential backups + total size of all log backups) - allocated pool data storageTotal backup storage size = (total size of all full backups + total size of all differential backups + total size of all log backups) - allocated pool data storage.

超过保留期的备份将根据其时间戳自动予以清除。Backups that are older than the retention period are automatically purged based on their timestamp. 由于差异备份和日志备份需要早期的完整备份才可供使用,因此它们将在每周区块中一并清除。Because the differential backups and log backups require an earlier full backup to be useful, they are purged together in weekly chunks.

Azure SQL 数据库将保留期内的备份存储总量计算为累积值。Azure SQL Database will compute your total in-retention backup storage as a cumulative value. 此值每隔一小时报告给 Azure 计费管道,该管道负责聚合此每小时用量,以便在每月底计算消耗量。Every hour, this value is reported to the Azure billing pipeline which is responsible for aggregating this hourly usage to calculate your consumption at the end of each month. 删除数据库后,消耗量会随着备份的陈旧而降低。After the database is dropped, consumption decreases as backups age. 备份超过保留期后,计费将会停止。Once the backups become older than the retention period, the billing stops.

重要

即使已删除数据库,也会保留数据库的备份,保留时间取决于指定的保留期。Backups of a database are retained for the specified retention period, even if the database has been dropped. 频繁删除并重新创建数据库可能会节省存储和计算成本,但可能会增加备份存储成本,因为每次删除一个数据库,我们都会将备份保留指定的时间(即保留期,至少 7 天)。While dropping and recreating a database frequently may save on storage and compute costs, it may increase backup storage costs as we retain a backup for the specified retention period (which is 7 days at minimum) for each dropped database, every time its dropped.

监视消耗情况Monitor consumption

每种类型的备份(完整备份、差异备份和日志备份)在数据库监视边栏选项卡上作为单独的指标进行报告。Each type of backup (full, differential and log) is reported on the database monitoring blade as a separate metric. 下图显示了如何监视单一数据库的备份存储消耗情况。The following diagram shows how to monitor the backups storage consumption for a single database. 此功能目前不适用于托管实例。This feature is currently unavailable for managed instances.

在 Azure 门户的数据库监视边栏选项卡上监视数据库备份消耗量

微调备份存储消耗量Fine tune the backup storage consumption

额外的备份存储消耗量取决于各个数据库的工作负荷和大小。The excess backup storage consumption will depend on the workload and size of the individual databases. 可以考虑实施下面一些优化技术,以进一步减少备份存储消耗量:You can consider implementing some of the following tuning techniques to further reduce your backup storage consumption:

  • 根据需要将备份保留期缩短至尽量最小。Reduce the backup retention period to the minimum possible for your needs.
  • 避免以超过需要的频率执行大型写入操作,例如索引重建。Avoid performing large write operations more frequently than needed, such as index rebuilds.
  • 对于大型数据加载操作,考虑使用聚集列存储索引,减少非聚集索引的数目,涉及到大约 100 万行时,考虑使用批量加载操作。For large data load operations consider using clustered columnstore indexes, reduce number of non-clustered indexes, and also consider bulk load operations with row count around one million.
  • 在“常规用途”服务层中,预配数据存储的成本低于额外消耗备份存储的成本,因此,持续产生较高额外备份存储成本的客户可以考虑增大数据存储,以节省备份存储的费用。In General Purpose service tier, the provisioned data storage is less expensive than the price of the excess backup storage due to which customers with continuously high excess backup storage costs may consider increasing the data storage in order to save on the backup storage.
  • 在 ETL 逻辑中使用 TempDB 来存储临时结果,而不要使用永久性表(仅适用于托管实例)。Use TempDB in your ETL logic for storing temporary results, instead of permanent tables (applicable to managed instance only).
  • 对于不包含敏感数据的数据库(例如开发或测试数据库),请考虑禁用 TDE 加密。Consider turning off TDE encryption for databases that do not contain sensitive data (development or test databases, for instance). 未加密数据库的备份通常使用较高的压缩比压缩。Backups for non-encrypted databases are typically compressed with a higher compression ratio.

重要

对于分析、数据市场/数据仓库工作负荷,强烈建议使用聚集列存储索引,减少非聚集索引的数量,并在涉及到大约 100 万行时考虑使用批量加载操作,以减少额外的备份存储消耗量。For analytical, data mart \ data warehouse workloads it is strongly recommended to use clustered columnstore indexes, reduce the number of non-clustered indexes, and also consider bulk load operations with row count around one million to reduce the excess backup storage consumption.

存储费用Storage costs

如果使用 DTU 模型或 vCore 模型,存储的价格会有所不同。The price for storage varies if you're using the DTU model or the vCore model.

DTU 模型DTU Model

使用 DTU 模型的数据库和弹性池不会产生额外的备份存储费用。There is no additional charge for backup storage for databases and elastic pools using the DTU model.

vCore 模型vCore model

对于单一数据库,提供与 100% 数据库大小相等的最小备份存储量,不收取额外的费用。For single databases, a minimum backup storage amount equal to 100% of database size is provided at no extra charge. 对于弹性池和托管实例,分别提供与根据池或实例大小分配的数据存储的 100% 相等的最小备份存储量,且不额外收费。For elastic pools and managed instances, a minimum backup storage amount equal to 100% of the allocated data storage for the pool or instance size, respectively, is provided at no extra charge. 超出此部分的其他备份存储用量将以 GB 为单位每月进行收费。Additional consumption of backup storage will be charged in GB/month. 此额外用量将取决于各个数据库的工作负荷和大小。This additional consumption will depend on the workload and size of the individual databases.

Azure SQL 数据库将保留期内的备份存储总量计算为累积值。Azure SQL DB will compute your total in-retention backup storage as a cumulative value. 此值每隔一小时报告给 Azure 计费管道,该管道负责聚合此每小时用量,以便在每月底计算消耗量。Every hour, this value is reported to the Azure billing pipeline which is responsible for aggregating this hourly usage to get your consumption at the end of each month. 删除数据库后,消耗量会随着备份的陈旧而减少。After the database is dropped, we decrease the consumption as the backups age. 备份超过保留期后,计费将会停止。Once they become older than the retention period, the billing stops. 由于所有日志备份和差异备份将按整个保留期保留,因此,经过重度修改的数据库会产生更高的备份费用。Because all the log backups and differential backups are retained for the full retention period, databases that are heavily modified will have higher backup charges.

假设数据库累积了 744 GB 的备份存储,此数量在整个月内将保持恒定。Let's assume the database has accumulated 744 GB of backup storage and this amount stays constant throughout an entire month. 若要将此累积存储消耗量转换为每小时用量,可将此数量除以 744.0(每月 31 天 * 每天 24 小时)。To convert this cumulative storage consumption to an hourly usage, we divide it by 744.0 (31 days per month * 24 hours per day). 因此,SQL 数据库将报告数据库每小时使用 1 GB 的 PITR 备份。Thus, SQL DB will report the database consumed 1 GB of PITR backup each hour. Azure 计费服务将聚合此数量,显示整月用量为 744 GB,并根据所在区域的每 GB 价格按每月费率显示成本。Azure billing will aggregate this and show a usage of 744 GB for the entire month and the cost based on the $/GB/mo rate in your region.

下面是一个更复杂的示例。Now, a more complex example. 假设数据库的保留期在当月的中途增加到了 14 天,(此项假设)会导致备份存储总量翻倍至 1488 GB。Suppose the database has its retention increased to 14 days in the middle of the month and this (hypothetically) results in the total backup storage doubling to 1488 GB. SQL 数据库将报告第 1-372 小时的用量为 1 GB,然后报告第 373-744 小时的用量为 2 GB。SQL DB would report 1 GB of usage for hours 1-372, and then report the usage as 2 GB for hours 373-744. 此数量将聚合到每月 1116 GB 的最终帐单中。This would be aggregated to be a final bill of 1116 GB/mo.

备份保留Backup retention

所有 Azure SQL 数据库(单一数据库、共用数据库和托管实例数据库)的默认备份保留期为 7 天。All Azure SQL databases (single, pooled, and managed instance databases) have a default backup retention period of seven days. 可以将备份保留期更改为最多 35 天You can change backup retention period up to 35 days.

如果删除了某个数据库,SQL 数据库以保存联机数据库的相同方式保存其备份。If you delete a database, SQL Database will keep the backups in the same way it would for an online database. 例如,如果删除了保留期为 7 天的某个基本数据库,已保存 4 天的备份将继续保存 3 天。For example, if you delete a Basic database that has a retention period of seven days, a backup that is four days old is saved for three more days.

如果需要备份保留时间超过最长的保持期,则可以修改备份属性,以向数据库添加一个或多个长期保持期。If you need to keep the backups for longer than the maximum retention period, you can modify the backup properties to add one or more long-term retention periods to your database. 有关详细信息,请参阅 长期保留For more information, see Long-term retention.

重要

如果删除了托管 SQL 数据库的 Azure SQL 服务器,则也会删除属于该服务器的所有弹性池和数据库,且不可恢复。If you delete the Azure SQL server that hosts SQL databases, all elastic pools and databases that belong to the server are also deleted and cannot be recovered. 无法还原已删除的服务器。You cannot restore a deleted server. 但是,如果配置了长期保留,则不会删除具有 LTR 的数据库的备份,并且可以还原这些数据库。But if you configured long-term retention, the backups for the databases with LTR will not be deleted and these databases can be restored.

加密备份Encrypted backups

如果使用 TDE 加密数据库,备份(包括 LTR 备份)会自动静态加密。If your database is encrypted with TDE, the backups are automatically encrypted at rest, including LTR backups. 为 Azure SQL 数据库启用 TDE 时,也会加密备份。When TDE is enabled for an Azure SQL database, backups are also encrypted. 默认情况下,所有新的 Azure SQL 数据库都配置为启用 TDE。All new Azure SQL databases are configured with TDE enabled by default. 有关 TDE 的详细信息,请参阅使用 Azure SQL 数据库进行透明数据加密For more information on TDE, see Transparent Data Encryption with Azure SQL Database.

备份完整性Backup integrity

Azure SQL 数据库工程团队持续不断地自动测试放置在逻辑服务器和弹性池(这在托管实例中不可用)中的数据库的自动数据库备份的还原。On an ongoing basis, the Azure SQL Database engineering team automatically tests the restore of automated database backups of databases placed in Logical servers and Elastic pools (this is not available in Managed Instance). 进行时间点还原后,数据库还会进行使用 DBCC CHECKDB 的完整性检查。Upon point-in-time restore, databases also receive integrity checks using DBCC CHECKDB.

在迁移完成后,托管实例会通过 CHECKSUM 对使用本机 RESTORE 命令或数据迁移服务还原的数据库进行自动初始备份。Managed Instance takes automatic initial backup with CHECKSUM of the databases restored using native RESTORE command or Data Migration Service once the migration is completed.

在完整性检查期间发现的任何问题都将导致向工程团队发出警报。Any issues found during the integrity check will result in an alert to the engineering team. 有关 Azure SQL 数据库中数据完整性的详细信息,请参阅 Azure SQL 数据库中的数据完整性For more information about data integrity in Azure SQL Database, see Data Integrity in Azure SQL Database.

合规性Compliance

将数据库从基于 DTU 的服务层级迁移到基于 vCore 的服务层级时,将保留 PITR 保留期以确保不会违反应用程序的数据恢复策略。When you migrate your database from a DTU-based service tier to a vCore-based service tier, the PITR retention is preserved to ensure that your application's data recovery policy is not compromised. 如果默认保留期不满足合规要求,可以使用 PowerShell 或 REST API 更改 PITR 保留期。If the default retention doesn't meet your compliance requirements, you can change the PITR retention period using PowerShell or REST API. 有关详细信息,请参阅更改备份保持期For more information, see Change Backup Retention Period.

备注

本文介绍如何删除设备或服务中的个人数据,并且可为 GDPR 下的任务提供支持。This article provides steps for how to delete personal data from the device or service and can be used to support your obligations under the GDPR. 如需关于 GDPR 的常规信息,请参阅服务信任门户的 GDPR 部分If you're looking for general info about GDPR, see the GDPR section of the Service Trust portal.

更改 PITR 备份保留期Change PITR backup retention period

可以使用 Azure 门户、PowerShell 或 REST API 更改默认 PITR 备份保持期。You can change the default PITR backup retention period using the Azure portal, PowerShell, or the REST API. 以下示例演示如何将 PITR 保留期更改为 28 天。The following examples illustrate how to change PITR retention to 28 days.

警告

如果缩短当前保留期,早于新保留期的所有现有备份将不再可用。If you reduce the current retention period, all existing backups older than the new retention period are no longer available. 如果延长当前保留期,SQL 数据库将保留现有备份,直至达到更长的保留期。If you increase the current retention period, SQL Database will keep the existing backups until the longer retention period is reached.

备注

这些 API 将只影响 PITR 保留期。These APIs will only impact the PITR retention period. 如果为数据库配置了 LTR,LTR 不会受到影响。If you configured LTR for your database, it will not be impacted. 有关如何更改 LTR 保持期的详细信息,请参阅长期保留For more information about how to change the LTR retention period(s), see Long-term retention.

使用 Azure 门户更改 PITR 备份保留期Change PITR backup retention period using Azure portal

若要使用 Azure 门户更改 PITR 备份保留期,请导航到要在门户中更改其保留期的服务器对象,然后根据要修改的服务器对象选择适当的选项。To change the PITR backup retention period using the Azure portal, navigate to the server object whose retention period you wish to change within the portal and then select the appropriate option based on which server object you're modifying.

在服务器级别更改单个 Azure SQL 数据库的 PITR 备份保留期。Change of PITR backup retention for single Azure SQL Databases is performed at the server level. 在服务器级别所做的更改适用于该服务器上的数据库。Change made at the server level applies to databases on that server. 若要从 Azure 门户更改 Azure SQL 数据库服务器的 PITR,请导航到“服务器概述”边栏选项卡,单击导航菜单上的“管理备份”,然后单击导航栏上的“配置保留期”。To change PITR for Azure SQL Database server from Azure portal, navigate to the server overview blade, click on Manage Backups on the navigation menu, and then click on Configure retention at the navigation bar.

更改 PITR Azure 门户

使用 PowerShell 更改 PITR 备份保留期Change PITR backup retention period using PowerShell

备注

本文进行了更新,以便使用新的 Azure PowerShell Az 模块。This article has been updated to use the new Azure PowerShell Az module. 你仍然可以使用 AzureRM 模块,至少在 2020 年 12 月之前,它将继续接收 bug 修补程序。You can still use the AzureRM module, which will continue to receive bug fixes until at least December 2020. 若要详细了解新的 Az 模块和 AzureRM 兼容性,请参阅新 Azure Powershell Az 模块简介To learn more about the new Az module and AzureRM compatibility, see Introducing the new Azure PowerShell Az module. 有关 Az 模块安装说明,请参阅安装 Azure PowerShellFor Az module installation instructions, see Install Azure PowerShell.

重要

PowerShell Azure 资源管理器模块仍受 Azure SQL 数据库的支持,但所有未来的开发都是针对 Az.Sql 模块的。The PowerShell Azure Resource Manager module is still supported by Azure SQL Database, but all future development is for the Az.Sql module. 若要了解这些 cmdlet,请参阅 AzureRM.SqlFor these cmdlets, see AzureRM.Sql. Az 模块和 AzureRm 模块中的命令参数大体上是相同的。The arguments for the commands in the Az module and in the AzureRm modules are substantially identical.

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

使用 REST API 更改 PITR 保留期Change PITR retention period using REST API

示例请求Sample Request

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

请求正文Request Body

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

示例响应Sample Response

状态代码:200Status code: 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 APIFor more information, see Backup Retention REST API.

后续步骤Next steps