你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
长期保留 - Azure SQL 数据库和 Azure SQL 托管实例
适用于： 
Azure SQL 数据库 Azure SQL 托管实例
本文概述了Azure SQL 数据库和Azure SQL 托管实例备份的长期保留。 可以为 Azure SQL 数据库（包括超大规模服务层级）和 Azure SQL 托管实例启用长达10年的保留。
首先要配置长期保留，请参阅配置 Azure SQL 数据库 LTR 和配置 Azure SQL 托管实例 LTR。
长期保留的工作原理
出于法规要求、符合性或其他商业目的，许多应用程序要求保留自动备份功能提供的过去1-35天的数据库备份。 长期备份保留（LTR）依赖于 Azure SQL 服务自动创建的完整数据库备份。 有关详细信息，请参阅 Azure SQL 数据库或 Azure SQL 托管实例中的自动备份。
通过使用长期保留 (LTR) 功能，可以将指定的 SQL 数据库和 SQL 托管实例完整备份存储在冗余可配置的 Azure Blob 存储中长达 10 年。 然后，可将 LTR 备份还原为新数据库。 如果配置了 LTR 策略，则会将自动备份复制到不同的 Blob 中，以便长期存储，然后可以使用该 Blob 将数据库还原到特定的时间点。 复制是后台作业，不会对数据库工作负载造成性能影响。 SQL 数据库中每个数据库的 LTR 策略还可以指定创建 LTR 备份的频率。
注意
若要实现 LTR，可以使用以下四个参数的组合定义策略：每周备份保留 (W)、每月备份保留 (M)、每年备份保留 (Y) 和年中的周 (WeekOfYear)。 如果指定 W，则每周会将一个备份复制到长期存储。 如果指定 M，则每月的第一个备份会复制到长期存储。 如果指定 Y，则会在 WeekOfYear 指定的周将一个备份复制到长期存储。 如果配置策略时指定的 WeekOfYear 在过去，则会在下一年创建第一个 LTR 备份。 每个备份都将按照创建 LTR 备份时配置的策略参数保留在长期存储中。
对 LTR 策略进行的任何更改都只适用于将来的备份。 例如，如果修改了每周备份保留 (W)、每月备份保留 (M) 或每年备份保留 (Y)，则新的保留设置仅应用于新备份。 不会修改现有备份的保留期。 如果目的是在保留期到期之前删除旧的 LTR 备份，则需手动删除备份。
LTR 策略示例：
W=0, M=0, Y=5, WeekOfYear=3每年的第 3 个完整备份将保留 5 年。
W=0, M=3, Y=0每月的第一个完整备份将保留 3 个月。
W=12, M=0, Y=0每个每周完整备份将保留 12 周。
W=6, M=12, Y=10, WeekOfYear=20每个每周完整备份将保留 6 周。 每月的第一个完整备份例外，该备份将保留 12 个月。 每年的第 20 周创建的完整备份例外，该备份将保留 10 年。
下表说明了以下策略的长期备份的节奏和到期：
W=12 weeks（84 天）、M=12 months（365 天）、Y=10 years（3650 天）、WeekOfYear=20（5 月 13 日之后的一周）
以下日期在 ISO 8601 (YYYY-MM-DD) 中。
| PITR 备份到 LTR | 过期日期 W | 过期日期 M | 过期日期 Y |
|---|---|---|---|
| 2018-03-07 | 2019-03-02 | ||
| 2018-03-14 | 2018-06-06 | ||
| 2018-03-21 | 2018-06-13 | ||
| 2018-03-28 | 2018-06-20 | ||
| 2018-04-04 | 2019-03-30 | ||
| 2018-04-11 | 2018-07-04 | ||
| 2018-04-18 | 2018-07-11 | ||
| 2018-04-25 | 2018-07-18 | ||
| 2018-05-02 | 2019-04-27 | ||
| 2018-05-09 | 2018-08-01 | ||
| 2018-05-16 | 2028-05-13 | ||
| 2018-05-23 | 2018-08-15 | ||
| 2018-05-30 | 2018-08-22 | ||
| 2018-06-06 | 2019-06-01 | ||
| 2018-06-13 | 2018-09-05 | ||
| 2018-06-20 | 2018-09-12 | ||
| 2018-06-27 | 2018-09-19 | ||
| 2018-07-04 | 2019-06-29 | ||
| 2018-07-11 | 2018-10-03 | ||
| 2018-07-18 | 2018-10-10 | ||
| 2018-07-25 | 2018-10-17 | ||
| 2018-08-01 | 2019-07-27 | ||
| 2018-08-08 | 2018-10-31 | ||
| 2018-08-15 | 2018-11-07 | ||
| 2018-08-22 | 2018-11-14 | ||
| 2018-08-29 | 2018-11-21 |
如果你修改上述策略并设置 W=0（不进行每周备份），则服务仅保留每月备份和每年备份。 在 LTR 策略下不会存储任何每周备份。 保留这些备份所需的存储量会相应减少。
重要
各 LTR 备份的时间均由 Azure SQL 数据库控制。 无法手动创建 LTR 备份，或手动控制备份创建时间。 配置 LTR 策略后，最多可能需要 7 天才能在可用备份列表中显示首个 LTR 备份。
如果删除逻辑服务器或托管实例，则该服务器或该托管实例上所有的数据库也会删除，且无法恢复。 无法还原已删除的服务器或托管实例。 但是，如果为数据库或托管实例配置了 LTR，则不会删除 LTR 备份，并且可以使用它们在同一订阅的另一个服务器或托管实例上将数据库还原到执行 LTR 备份的时间点。
同样，如果删除数据库，LTR 备份不会删除，并且会在配置的保留期内保留。 这些备份可以还原到同一订阅中的同一服务器或不同服务器。
异地复制和长期备份保留
如果使用活动异地复制或故障转移组作为业务连续性解决方案，应准备好最终故障转移，并在辅助数据库中配置相同的 LTR 策略。 LTR 存储成本不会增大，因为备份不是从辅助数据库生成的。 仅当辅助数据库变为主数据库时，才会创建备份。 这样可以确保在触发故障转移以及在主数据库转移到次要区域时，不间断地生成 LTR 备份。
注意
在发生导致故障转移的服务中断问题后恢复原始的主数据库时，该数据库将变成新的辅助数据库。 因此，在该数据库重新变成主数据库之前，备份创建操作不会恢复，并且现有的 LTR 策略不会生效。
配置长期备份保留
可使用 Azure 门户及适用于 Azure SQL 数据库和 Azure SQL 托管实例的 PowerShell 来配置长期备份保留。 若要从 LTR 存储还原数据库，可以根据时间戳选择一个特定备份。 数据库可以还原到原始数据库所在的订阅中的任何现有服务器或托管实例。
若要了解如何使用 Azure 门户或 PowerShell 配置长期保留或从 SQL 数据库的备份还原数据库，请参阅管理 Azure SQL 数据库长期备份保留。
若要了解如何使用 Azure 门户或 PowerShell 配置长期保留或从 SQL 托管实例的备份还原数据库，请参阅管理 Azure SQL 托管实例长期备份保留。
当在 LTR 保留期的最后 7 天内启动还原请求时，Azure 将自动延长所有备份的到期日期 7 天，以防止 LTR 备份在还原期间过期。
注意
如果使用 LTR 备份来满足合规性或其他任务关键型要求，请考虑进行定期恢复演练，以验证是否可以还原 LTR 备份，以及还原结果是否符合预期的数据库状态。
相关内容
数据库备份可保护数据免遭意外损坏或删除，因此数据库备份是任何业务连续性和灾难恢复策略不可或缺的组成部分。
有关配置和管理 LTR 备份的教程，请访问：