Azure SQL 数据库长期保留Azure SQL Database long-term retention

出于法规要求、符合性或其他商业目的,许多应用程序要求保留 Azure SQL 数据库的自动备份功能提供的过去 7-35 天的数据库备份。Many applications have regulatory, compliance, or other business purposes that require you to retain database backups beyond the 7-35 days provided by Azure SQL Database automatic backups. 通过使用长期保留 (LTR) 功能,可以将指定的 SQL 数据库完整备份存储在可以进行读取访问异地冗余存储的 Azure Blob 存储中长达 10 年。By using the long-term retention (LTR) feature, you can store specified SQL database full backups in Azure Blob storage with read-access geo-redundant storage for up to 10 years. 然后,可以将任何备份还原为新数据库。You can then restore any backup as a new database. 有关 Azure 存储冗余的详细信息,请参阅 Azure 存储冗余For more information about Azure Storage redundancy, see Azure Storage redundancy.

可为单一数据库和共用数据库启用长期保留。Azure SQL 数据库托管实例的长期保留功能以受限公共预览版形式提供。Long time retention can be enabled for single and pooled databases, and is in limited public preview for Azure SQL Database managed instances.


可以使用 SQL 代理作业来安排仅复制数据库备份作为超过 35 天的 LTR 的替代方案。You can use SQL Agent jobs to schedule copy-only database backups as an alternative to LTR beyond 35 days.

SQL 数据库长期保留的工作原理How SQL Database long-term retention works

长期备份保留 (LTR) 利用自动创建的完整数据库备份来启用时间点还原 (PITR)。Long-term backup retention (LTR) leverages the full database backups that are automatically created to enable point-time restore (PITR). 如果配置了 LTR 策略,这些备份将复制到不同的 Blob 进行长期存储。If an LTR policy is configured, these backups are copied to different blobs for long-term storage. 复制是后台作业,不会对数据库工作负载造成性能影响。The copy is a background job that has no performance impact on the database workload. 每个 SQL 数据库的 LTR 策略还可以指定创建 LTR 备份的频率。The LTR policy for each SQL database can also specify how frequently the LTR backups are created.

若要实现 LTR,可以使用以下四个参数的组合定义策略:每周备份保留 (W)、每月备份保留 (M)、每年备份保留 (Y) 和年中的周 (WeekOfYear)。To enable LTR, you can define a policy using a combination of four parameters: weekly backup retention (W), monthly backup retention (M), yearly backup retention (Y), and week of year (WeekOfYear). 如果指定 W,则每周会将一个备份复制到长期存储。If you specify W, one backup every week will be copied to the long-term storage. 如果指定 M,则每月的第一个备份会复制到长期存储。If you specify M, the first backup of each month will be copied to the long-term storage. 如果指定 Y,则会在 WeekOfYear 指定的周将一个备份复制到长期存储。If you specify Y, one backup during the week specified by WeekOfYear will be copied to the long-term storage. 如果配置策略时指定的 WeekOfYear 在过去,则会在下一年创建第一个 LTR 备份。If the specified WeekOfYear is in the past when the policy is configured, the first LTR backup will be created in the following year. 每个备份都将按照创建 LTR 备份时配置的策略参数保留在长期存储中。Each backup will be kept in the long-term storage according to the policy parameters that are configured when the LTR backup is created.


对 LTR 策略所做的任何更改只应用到将来的备份。Any change to the LTR policy applies only to future backups. 例如,如果修改了每周备份保留 (W)、每月备份保留 (M) 或每年备份保留 (Y),则新的保留设置仅应用于新备份For example, if weekly backup retention (W), monthly backup retention (M), or yearly backup retention (Y) is modified, the new retention setting will only apply to new backups. 不会修改现有备份的保留期。The retention of existing backups will not be modified. 如果目的是在保留期到期之前删除旧的 LTR 备份,则需手动删除备份If your intention is to delete old LTR backups before their retention period expires, you will need to manually delete the backups.

LTR 策略的示例:Examples of the LTR policy:

  • W=0、M=0、Y=5、WeekOfYear=3W=0, M=0, Y=5, WeekOfYear=3

    每年的第 3 个完整备份将保留 5 年。The third full backup of each year will be kept for five years.

  • W=0、M=3、Y=0W=0, M=3, Y=0

    每月的第一个完整备份将保留 3 个月。The first full backup of each month will be kept for three months.

  • W=12、M=0、Y=0W=12, M=0, Y=0

    每个每周完整备份将保留 12 周。Each weekly full backup will be kept for 12 weeks.

  • W=6、M=12、Y=10、WeekOfYear=16W=6, M=12, Y=10, WeekOfYear=16

    每个每周完整备份将保留 6 周。Each weekly full backup will be kept for six weeks. 每月的第一个完整备份例外,该备份将保留 12 个月。Except first full backup of each month, which will be kept for 12 months. 每年的第 16 周创建的完整备份例外,该备份将保留 10 年。Except the full backup taken on 16th week of year, which will be kept for 10 years.

下表说明了以下策略的长期备份的节奏和到期:The following table illustrates the cadence and expiration of the long-term backups for the following policy:

W=12 周(84 天)、M=12 个月(365 天)、Y=10 年(3650 天)、WeekOfYear=15(4 月 15 日后的周)W=12 weeks (84 days), M=12 months (365 days), Y=10 years (3650 days), WeekOfYear=15 (week after April 15)

ltr 示例

如果修改以上策略并设置 W=0(无每周备份),则备份副本的节奏将更改,如上表中突出显示的日期所示。If you modify the above policy and set W=0 (no weekly backups), the cadence of backup copies will change as shown in the above table by the highlighted dates. 保留这些备份所需的存储量将相应减少。The storage amount needed to keep these backups would reduce accordingly.


单个 LTR 备份的时间由 Azure SQL 数据库控制。The timing of the individual LTR backups is controlled by Azure SQL Database. 无法手动创建 LTR 备份,或控制备份创建时间。You cannot manually create a LTR backup or control the timing of the backup creation. 配置 LTR 策略后,最多可能需要 7 天才能在可用备份列表中显示第一个 LTR 备份。After configuring an LTR policy, it may take up to 7 days before the first LTR backup will show up on the list of available backups.

异地复制和长期备份保留Geo-replication and long-term backup retention

如果使用活动异地复制或故障转移组作为业务连续性解决方案,应准备好最终故障转移,并在异地辅助数据库中配置相同的 LTR 策略。If you are using active geo-replication or failover groups as your business continuity solution, you should prepare for eventual failovers and configure the same LTR policy on the geo-secondary database. LTR 存储成本不会增大,因为备份不是从辅助数据库生成的。Your LTR storage cost will not increase as backups are not generated from the secondaries. 仅当辅助数据库变为主数据库时,才会创建备份。Only when the secondary becomes primary the backups will be created. 这样可以确保在触发故障转移以及在主数据库转移到次要区域时,不间断地生成 LTR 备份。It ensures non-interrupted generation of the LTR backups when the failover is triggered and the primary moves to the secondary region.


在发生导致故障转移的服务中断问题后恢复原始的主数据库时,该数据库将变成新的辅助数据库。When the original primary database recovers from an outage that caused the failover, it will become a new secondary. 因此,在该数据库重新变成主数据库之前,备份创建操作不会恢复,并且现有的 LTR 策略不会生效。Therefore, the backup creation will not resume and the existing LTR policy will not take effect until it becomes the primary again.

托管实例支持Managed Instance support

在 Azure SQL 数据库托管实例中使用长期备份保留有以下限制:Using long-term backup retention with an Azure SQL Database managed instances has the following limitations:

  • 受限公共预览版 - 此预览版仅适用于 EA 订阅和云解决方案提供商订阅,并受到有限可用性的限制。Limited public preview - This preview is only available to EA and CSP subscriptions and is subject to limited availability.
  • 仅限 PowerShell - 目前不支持 Azure 门户。PowerShell only - There is currently no Azure portal support. 必须使用 PowerShell 启用 LTR。LTR must be enabled using PowerShell.

若要请求注册,请创建 Azure 支持票证To request enrollment, create an Azure support ticket.

配置长期备份保留Configure long-term backup retention

若要了解如何使用 Azure 门户或 PowerShell 配置长期保留,请参阅管理 Azure SQL 数据库长期备份保留To learn how to configure long-term retention using the Azure portal or PowerShell, see Manage Azure SQL Database long-term backup retention.

从 LTR 备份还原数据库Restore database from LTR backup

若要从 LTR 存储还原数据库,可以根据时间戳选择一个特定备份。To restore a database from the LTR storage, you can select a specific backup based on its timestamp. 数据库可以还原到原始数据库所在的订阅中的任何现有服务器。The database can be restored to any existing server under the same subscription as the original database. 若要了解如何使用 Azure 门户或 PowerShell 从 LTR 备份还原数据库,请参阅管理 Azure SQL 数据库长期备份保留To learn how to restore your database from an LTR backup, using the Azure portal, or PowerShell, see Manage Azure SQL Database long-term backup retention.

后续步骤Next steps

数据库备份可保护数据免遭意外损坏或删除,因此数据库备份是任何业务连续性和灾难恢复策略不可或缺的组成部分。Because database backups protect data from accidental corruption or deletion, they're an essential part of any business continuity and disaster recovery strategy. 若要了解其他 SQL 数据库业务连续性解决方案,请参阅业务连续性概述To learn about the other SQL Database business-continuity solutions, see Business continuity overview.