适用于：
Azure SQL 数据库Azure SQL 托管实例
本文概述了 Azure SQL 数据库和 Azure SQL 托管实例的长期保留（LTR）备份。 可以在 Azure SQL 数据库（包括超大规模服务层级）和 Azure SQL 托管实例的备份上配置长达 10 年的长期保留期。
若要开始使用长期保留备份功能，请参阅：
出于法规要求、符合性或其他商业目的，许多应用程序要求保留自动备份功能提供的过去1-35天的数据库备份。 长期备份保留（LTR）依赖于 Azure SQL 服务自动创建的完整数据库备份。 有关详细信息，请参阅 Azure SQL 数据库中的自动备份 或 Azure SQL 托管实例中的自动备份。
通过使用长期保留 (LTR) 功能，可以将指定的 SQL 数据库和 SQL 托管实例完整备份存储在冗余可配置的 Azure Blob 存储中长达 10 年。 然后，可将 LTR 备份还原为新数据库。 如果配置了 LTR 策略，则会将自动备份复制到不同的 Blob 中，以便长期存储，然后可以使用该 Blob 将数据库还原到特定的时间点。 复制过程是一个后台作业，对数据库工作负荷没有性能影响。 每个数据库的 LTR 策略还可以指定 LTR 备份的创建频率。
注意
目前无法将Azure SQL 数据库和Azure SQL 托管实例的备份配置为不可变。 LTR 备份不可修改，但可以通过 Azure 门户、Azure CLI、PowerShell 或 REST API 将其删除。
作为 Azure SQL 托管实例中的一种解决方法，可以采用 仅复制数据库备份 ，并将其作为不可变文件保留在自己的 Azure 存储帐户中。
若要实现 LTR，可以使用以下四个参数的组合定义策略：每周备份保留 (W)、每月备份保留 (M)、每年备份保留 (Y) 和年中的周 (WeekOfYear)。 如果指定 W，则每周会将一个备份复制到长期存储。 如果指定 M，则每月的第一个备份会复制到长期存储。 如果指定 Y，则会在 WeekOfYear 指定的周将一个备份复制到长期存储。 如果配置策略时指定的 WeekOfYear 在过去，则会在下一年创建第一个 LTR 备份。 每个备份都将按照创建 LTR 备份时配置的策略参数保留在长期存储中。
对 LTR 策略的更改仅适用于将来的备份。 例如，如果修改每周备份保留期（W）、每月备份保留期（M）或每年备份保留期（Y），则新的保留设置仅适用于新备份。 不会修改现有备份的保留期。 可以为 Azure SQL 数据库和 Azure SQL 托管实例中的每个数据库配置 LTR 策略。 如果打算在保留期到期之前删除旧的 LTR 备份，可以 手动删除备份。
注意
在 Azure SQL 数据库和 Azure SQL 托管实例中，首次为数据库启用 LTR 策略时，策略会指定每年保留期，则会将最新完整备份从时间点还原（PITR）复制到长期存储。
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 控制。 无法手动创建 LTR 备份，或手动控制备份创建时间。 配置 LTR 策略后，可能需要长达七天的时间，第一个 LTR 备份才会显示在可用备份列表中。
如果删除逻辑服务器或 SQL 托管实例，该服务器或托管实例上的所有数据库也会被删除。 无法还原已删除的逻辑服务器或 SQL 托管实例。 但是，如果为数据库配置了 LTR，则不会删除 LTR 备份，并且可用于将数据库还原到同一订阅中的其他服务器或托管实例，以达到 LTR 备份的某个时间点。
同样，如果删除数据库，则不会删除 LTR 备份，并在配置的保留期内保留。 这些备份可以还原到同一订阅中的同一服务器或不同服务器。
如果使用活动异地复制或故障转移组作为业务连续性解决方案，请为最终故障转移做好准备，并在主数据库或实例上配置与主数据库或实例相同的 LTR 策略。 LTR 存储成本不会增加，因为备份不是从辅助数据库生成的。 只有在辅助数据库成为主数据库后，才能创建备份，以确保在触发故障转移时不间断地生成 LTR 备份，而主数据库将移到辅助区域。
在发生导致故障转移的服务中断问题后恢复原始的主数据库时，该数据库将变成新的辅助数据库。 因此，在该数据库重新变成主数据库之前，备份创建操作不会在新的辅助数据库上恢复，并且现有的 LTR 策略不会生效。
可使用 Azure 门户及适用于 Azure SQL 数据库和 Azure SQL 托管实例的 PowerShell 来配置长期备份保留。 若要从 LTR 存储还原数据库，可以根据时间戳选择一个特定备份。 数据库可以还原到原始数据库所在的订阅中的任何现有服务器或托管实例。
在 LTR 保留期的最后七天内启动还原请求时，LTR 备份仅在还原作完成后删除，即使保留期已过期。
在 Azure SQL 托管实例中，您可以使用 SQL 代理作业来计划 仅复制数据库备份，并将其移动到您自己的存储帐户中，作为一种替代方法：
- 将备份保留 10 年以上。
- 将数据库的每日副本保留 35 天以上。
- 将数据库备份存储在不可变存储上。
提示
如果使用 LTR 备份来满足合规性或其他任务关键要求，请考虑进行定期恢复演练，以验证是否可以还原 LTR 备份，以及还原是否会导致预期的数据库状态。
数据库备份可保护数据免遭意外损坏或删除，因此数据库备份是任何业务连续性和灾难恢复策略不可或缺的组成部分。