自动备份Automated backups

Azure SQL 数据库自动创建数据库备份,这些备份会进行保存,保存的时间长度为已配置的保留期。Azure SQL Database automatically creates the database backups that are kept for the duration of the configured retention period. Azure SQL 数据库使用 Azure 读取访问异地冗余存储 (RA-GRS) 来确保保留这些备份(即使数据中心不可用)。It uses Azure read-access geo-redundant storage (RA-GRS) to ensure the backups are preserved even if the datacenter is unavailable.

数据库备份是任何业务连续性和灾难恢复策略的基本组成部分,因为数据库备份可以保护数据免遭意外损坏或删除。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 time (up to 10 years), you can configure long-term retention on singleton databases and elastic database pools.

Note

本文介绍如何删除设备或服务中的个人数据,并且可为 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 to 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 determines 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 by using the Azure portal, Azure PowerShell, Azure CLI, or the REST API. 对于单一数据库和弹性数据库池,此操作会在与原始数据库相同的服务器中创建新数据库。For single databases and elastic database pools, this operation will create a new database on the same server as the original database. 在托管实例中,此操作可以创建数据库的一个副本,或者在同一订阅下创建相同或不同托管实例。In managed instance, this operation can create a copy of the database or the same or a different managed instance under the same subscription.
  • 将已删除的数据库还原到删除时间或保留期内的任意时间。Restore a deleted database to the time of deletion or anytime within the retention period. 仅可在创建原始数据库的同一逻辑服务器或托管实例上还原已删除的数据库。The deleted database can be restored only on the same logical server or managed instance where the original database was created.
  • 将数据库还原到其他地理区域。Restore a database to another geographic region. 在无法访问服务器和数据库的情况下,异地还原可用于从某个地理区域内发生的灾难中恢复。Geo-restore allows you to recover from a geographic disaster when you can't access your server and database. 它会在全球任意位置的任意现有服务器中创建新数据库。It creates a new database on any existing server, anywhere in the world.
  • 从特定的长期备份将数据库还原到单一数据库或弹性数据库池中(如果为数据库配置了长期保留策略 (LTR))。Restore a database from a specific long-term backup on a single database or elastic database pool, if the database is configured with a long-term retention policy (LTR). LTR 允许使用 Azure 门户Azure PowerShell 还原旧版本的数据库,以满足合规性请求或运行旧版本的应用程序。LTR allows you to restore an old version of the database by 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.

Note

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

可以使用以下示例尝试这其中的部分操作:You can try some of these operations by 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 a database from a point in time 单一数据库Single database 单一数据库Single database
托管实例Managed instance
还原已删除的数据库Restore a deleted database 单一数据库Single database 单一数据库Single database
托管实例Managed instance
从 Azure Blob 存储还原数据库Restore a 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 backups, differential backups, and transaction log backups. 完整数据库备份是每周创建的,差异数据库备份通常是每隔 12 小时创建的。Full database backups are created weekly, and differential database backups are generally created every 12 hours. 事务日志备份通常是每隔 5 到 10 分钟创建的。Transaction log backups are generally created every 5 to 10 minutes. 事务日志备份的频率取决于计算大小和数据库活动量。The frequency of transaction log backups is based on the compute size and the amount of database activity.

会在数据库创建后立即计划第一次完整备份。The first full backup is scheduled immediately after a database is created. 此备份通常可在 30 分钟内完成,但如果数据库较大,花费的时间可能更长。This backup usually completes within 30 minutes, but it can take longer when the database is large. 例如,对已还原的数据库或数据库副本执行初始备份可能需要更长时间。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 can't change or disable the backup jobs.

默认备份保持期Default backup retention period

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

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

长期保留Long-term retention

对于单一数据库和共用数据库,可以配置完整备份的长期保留 (LTR),使其在 Azure Blob 存储中最长保存 10 年。For single and pooled databases, you can configure long-term retention (LTR) of full backups for up to 10 years in Azure Blob storage. 如果启用 LTR 策略,每周完整备份将自动复制到不同的 RA-GRS 存储容器。If you enable LTR policy, the weekly full backups are automatically copied to a different RA-GRS storage container. 为了满足不同的合规性要求,可为每周、每月和/或每年备份选择不同的保留期。To meet various compliance requirements, 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 or periods. 可以使用 LTR 定价计算器来估算 LTR 存储成本。You can use the LTR pricing calculator to estimate the cost of LTR storage.

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

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

备份存储消耗量Backup storage consumption

对于单一数据库,可使用以下公式来计算备份存储总用量:For single databases, this equation is used to calculate the total backup storage usage:

Total backup storage size = (size of full backups + size of differential backups + size of log backups) - database size

对于弹性数据库池,备份存储总大小将在池级别进行聚合,计算方式如下:For elastic database 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 storage

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

Azure SQL 数据库将保留期内的备份存储总量计算为累积值。Azure SQL Database computes 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. 备份的保留时间超过保留期后,计费将会停止。After backups become older than the retention period, billing stops.

Important

即使已删除数据库,也会保留数据库的备份,保留时间取决于指定的保留期。Backups of a database are retained for the specified retention period, even if the database has been dropped. 频繁删除并重新创建数据库可能会节省存储和计算成本,但可能会增加备份存储成本,因为每次删除一个数据库,Azure 就会将这个已删除数据库的备份保留指定的时间(至少 7 天)。While dropping and re-creating a database can frequently save on storage and compute costs, it might increase backup storage costs because Azure retains a backup for the specified retention period (which is 7 days at minimum) for each dropped database, every time it's 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 backup storage consumption for a single database. 此功能目前不适用于托管实例。This feature is currently unavailable for managed instances.

在 Azure 门户中监视数据库备份消耗量

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

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

  • 根据需要将备份保留期缩短至尽量最小。Reduce the backup retention period to the minimum possible for your needs.
  • 避免以超过需要的频率执行大型写入操作,例如索引重建。Avoid doing large write operations, like index rebuilds, more frequently than you need to.
  • 对于大型数据加载操作,考虑使用聚集列存储索引,减少非聚集索引的数目,并且在行计数大约为 100 万行的情况下,考虑使用批量加载操作。For large data load operations, consider using clustered columnstore indexes, reduce the number of non-clustered indexes, and consider bulk load operations with row count around 1 million.
  • 在常规用途服务层级中,预配数据存储的价格低于额外备份存储的价格。In the general purpose service tier, the provisioned data storage is less expensive than the price of the excess backup storage. 如果你的额外备份存储成本一直较高,可以考虑增大数据存储,以节省备份存储的费用。If you have continually high excess backup storage costs, you might consider increasing the data storage to save on the backup storage.
  • 在 ETL 逻辑中使用 TempDB 而不是永久性表来存储临时结果。Use TempDB instead of permanent tables in your ETL logic for storing temporary results. (仅适用于托管实例。)(Applicable only to managed instance.)
  • 对于不包含敏感数据的数据库(例如开发或测试数据库),请考虑禁用 TDE 加密。Consider turning off TDE encryption for databases that don't contain sensitive data (development or test databases, for example). 未加密数据库的备份通常使用较高的压缩比压缩。Backups for non-encrypted databases are typically compressed with a higher compression ratio.

Important

对于与分析相关的数据市场/数据仓库工作负荷,我们强烈建议使用聚集列存储索引,减少非聚集索引的数量,并在行计数大约为 100 万行的情况下考虑使用批量加载操作,以减少额外的备份存储消耗量。For analytical data mart \ data warehouse workloads, we strongly recommend that you use clustered columnstore indexes, reduce the number of non-clustered indexes, and consider bulk load operations with row count around 1 million to reduce excess backup storage consumption.

存储费用Storage costs

存储价格会根据你使用的是 DTU 模型还是 vCore 模型而有所不同。The price for storage varies depending on whether you're using the DTU model or the vCore model.

DTU 模型DTU model

如果使用的是 DTU 模型,则数据库和弹性数据库池不会产生额外的备份存储费用。There's no additional charge for backup storage for databases and elastic database pools if you're using the DTU model.

vCore 模型vCore model

对于单一数据库,会提供与 100% 数据库大小相等的最小备份存储量,不收取额外的费用。For single databases, a minimum backup storage amount equal to 100 percent of the database size is provided at no extra charge. 对于弹性数据库池和托管实例,会分别提供与根据池或实例大小分配的数据存储的 100% 相等的最小备份存储量,不收取额外的费用。For elastic database pools and managed instances, a minimum backup storage amount equal to 100 percent 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 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 get your consumption at the end of each month. 删除数据库后,消耗量会随着备份的陈旧而减少。After the database is dropped, we decrease the consumption as the backups age. 备份的保留时间超过保留期后,计费将会停止。After backups become older than the retention period, billing stops. 由于所有日志备份和差异备份的保留时间为整个保留期,因此,经过重度修改的数据库会产生更高的备份费用。Because all log backups and differential backups are retained for the full retention period, heavily modified databases will have higher backup charges.

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

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

备份保留Backup retention

所有 Azure SQL 数据库(单一数据库、共用数据库和托管实例数据库)的默认备份保留期为 7 天。All Azure SQL databases (single, pooled, and managed instance databases) have a default backup retention period of 7 days. 将备份保留期更改为最长 35 天。You can change the backup retention period to as long as 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's 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.

Important

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

加密备份Encrypted backups

如果使用 TDE 加密了数据库,则备份(包括 LTR 备份)会自动静态加密。If your database is encrypted with TDE, 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 database pools. (无法在托管实例中进行这种测试。)完成时间点还原后,数据库还会接受 DBCC CHECKDB 完整性检查。(This testing isn't available in managed instance.) Upon point-in-time restore, databases also receive DBCC CHECKDB integrity checks.

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

在完整性检查期间发现的任何问题都将导致向工程团队发出警报。Any issues found during the integrity check will result in an alert to the engineering team. 有关详细信息,请参阅 Azure SQL 数据库中的数据完整性For more information, 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 isn't compromised. 如果默认保留期不满足合规要求,可以使用 PowerShell 或 REST API 更改 PITR 保留期。If the default retention doesn't meet your compliance requirements, you can change the PITR retention period by using PowerShell or the REST API. 有关详细信息,请参阅更改 PITR 备份保留期For more information, see Change the PITR backup retention period.

Note

本文介绍如何删除设备或服务中的个人数据,并且可为 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 the PITR backup retention period

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

Warning

如果缩短当前保留期,那么保留时间已超过新保留期的所有现有备份将不再可用。If you reduce the current retention period, all existing backups that are 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 end of the longer retention period is reached.

Note

这些 API 只影响 PITR 保留期。These APIs will affect only the PITR retention period. 如果为数据库配置了 LTR,LTR 不会受到影响。If you configured LTR for your database, it won't be affected. 有关如何更改 LTR 保留期的信息,请参阅长期保留For information about how to change LTR retention periods, see Long-term retention.

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

若要使用 Azure 门户更改 PITR 备份保留期,请转到要在门户中更改其保留期的服务器对象。To change the PITR backup retention period by using the Azure portal, go to the server object whose retention period you want to change in the portal. 然后根据要修改的服务器对象选择相应的选项。Then select the appropriate option based on the server object you're modifying.

对单一 Azure SQL 数据库的 PITR 备份保留期更改是在服务器级别进行的。Changes to PITR backup retention for single Azure SQL databases are done at the server level. 在服务器级别做出的更改将应用到该服务器上的数据库。Changes made at the server level apply to databases on the server. 若要从 Azure 门户更改 Azure SQL 数据库服务器的 PITR 保留期,请转到服务器概述边栏选项卡。To change PITR retention for an Azure SQL Database server from the Azure portal, go to the server overview blade. 在左侧窗格中选择“管理备份”,然后在屏幕顶部选择“配置保留期”: Select Manage Backups in the left pane, and then select Configure retention at the top of the screen:

更改 PITR 保留期,服务器级别

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

Note

本文进行了更新,以便使用新的 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.

Important

PowerShell AzureRM 模块仍受 Azure SQL 数据库的支持,但所有未来的开发都是针对 Az.Sql 模块进行的。The PowerShell AzureRM module is still supported by Azure SQL Database, but all future development is for the Az.Sql module. 有关详细信息,请参阅 AzureRM.SqlFor more information, see AzureRM.Sql. Az 模块和 AzureRm 模块中的命令参数大体上是相同的。The arguments for the commands in the Az module are substantially identical to those in the AzureRm modules.

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

使用 REST API 更改 PITR 备份保留期Change the PITR backup retention period by using the 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