Azure SQL 数据库中的自动备份
适用于：
Azure SQL 数据库
本文介绍 Azure SQL 数据库的自动备份功能。
若要更改备份设置，请参阅更改设置。 若要还原备份，请参阅使用自动数据库备份进行恢复。
什么是数据库备份？
数据库备份是任何业务连续性和灾难恢复策略的基本组成部分，因为数据库备份可以帮助保护数据免遭损坏或删除。 这些备份可在配置的保留期内将数据库还原到某个时间点。 如果数据保护规则要求备份在较长时间（最长 10 年）内可用，可以同时为单一数据库和共用数据库配置长期保留 (LTR)。
对于超大规模以外的服务层级，Azure SQL 数据库使用 SQL Server 引擎技术来备份和还原数据。 超大规模数据库基于存储快照使用备份和还原。 使用传统的 SQL Server 备份技术时，备份/还原较大数据库需要很长时间。 使用快照时，无论数据库大小如何，超大规模都能提供即时备份和快速还原功能。 若要了解详情，请参阅超大规模备份。
备份频率
Azure SQL 数据库：
事务日志备份的确切频率取决于计算大小和数据库活动量。 还原数据库时，服务会确定需要还原哪些完整备份、差异备份和事务日志备份。
超大规模体系结构不需要完整备份、差异备份或日志备份。 若要了解详情，请参阅超大规模备份。
备份存储冗余
存储冗余机制存储数据的多个副本，以便在计划内和计划外事件期间提供保护。 这些事件可能包括暂时性硬件故障、网络中断或断电，或大范围的自然灾害。
默认情况下，Azure SQL 数据库中的新数据库会将备份存储在复制到配对区域的异地冗余存储 Blob 中。 异地冗余有助于防止主要区域中的服务中断影响备份存储。 它还允许在发生区域服务中断的情况下还原其他区域中的数据库。
为确保备份保留在部署数据库的同一区域内，可以将备份存储冗余从默认的异地冗余存储更改为将数据保留在区域内的其他存储类型。 配置的备份存储冗余会应用于短期保留 (STR) 备份和 LTR 备份。 若要详细了解存储冗余，请参阅数据冗余。
可以在创建数据库时配置备份存储冗余，以后可以对其进行更新。 对现有数据库所做的更改仅应用于将来的备份。 更新现有数据库的备份存储冗余后，最多可能需要 48 小时才能应用所做的更改。
可为备份选择以下存储冗余之一：
本地冗余存储 (LRS)：在主要区域中的单个物理位置内同步复制备份三次。 LRS 是成本最低的存储选项，但我们不建议将其用于需要弹性应对区域服务中断或保证高数据持久性的应用程序。
区域冗余存储 (ZRS)：跨主要区域中的三个 Azure 可用性区域同步复制备份。 目前仅在特定区域中可用。
异地冗余存储 (GRS)：使用 LRS 在主要区域中的单个物理位置内同步复制备份三次。 然后，它将数据异步复制到配对次要区域中的单个物理位置三次。
结果为：
- 主要区域中有三个同步副本。
- 配对区域中有三个同步副本，它们是从主要区域异步复制到次要区域的。
警告
- 在将数据库更新为使用本地冗余或区域冗余存储后，将立即禁用异地还原。
- 这些存储冗余关系图都显示了具有多个可用性区域（多 az）的区域。 但是，某些区域仅提供单个可用性区域，不支持 ZRS。
- 只能在创建期间为超大规模数据库设置备份存储冗余。 预配资源后无法修改此设置。 若要更新现有超大规模数据库的备份存储冗余设置并尽量减少停机时间，请使用活动异地复制。 或者，可以使用数据库复制。 有关详细信息，请参阅超大规模备份和存储冗余。
备份使用情况
可以在以下方案中使用自动创建的备份：
使用 Azure 门户、Azure PowerShell、Azure CLI 或 REST API 将现有的数据库还原到在保留期内的某个时间点。 此操作会在原始数据库所在的同一服务器上创建一个新的数据库，但会使用不同的名称来避免覆盖原始数据库。
还原完成后，可以选择删除原始数据库，并将还原的数据库重命名为原始数据库名称。 或者，可以重命名原始数据库，而不是将其删除，然后将还原的数据库重命名为原始数据库名称。
将已删除的数据库还原到保留期内的某个时间点（包括删除时的时间点）。 仅可在创建原始数据库所在的同一服务器中还原已删除的数据库。 在删除数据库之前，服务会创建最终事务日志备份，以防任何数据丢失。
将数据库还原到其他地理区域。 在出现无法访问主要区域中的数据库或备份的区域性中断时，可以借助异地还原进行恢复。 它可在任意 Azure 区域中的任意现有服务器上创建新的数据库。
重要
异地还原仅适用于配置了异地冗余备份存储的数据库。 如果当前没有对数据库使用异地复制的备份，可以通过配置备份存储冗余对此进行更改。
如果数据库配置了 LTR 策略，请从单一数据库或共用数据库的特定长期备份还原数据库。 LTR 允许使用 Azure 门户、Azure CLI 或 Azure PowerShell 来还原旧版数据库，以满足合规性请求或运行旧版应用程序。 有关详细信息，请参阅 长期保留。
次要副本上的自动备份
现在，自动备份是从业务关键服务层级中的次要副本获取的。 由于数据是在每个节点上的 SQL Server 进程之间复制，因此备份服务从不可读的次要副本获取备份。 此设计可确保主要副本仍专用于主工作负载，并且可读次要副本专用于只读工作负载。 业务关键服务层级中的自动备份大多数时候都是从次要副本获取的。 如果次要副本上的自动备份失败，则备份服务将从主要副本获取备份。
次要副本上的自动备份：
- 默认情况下启用。
- 包含在服务层级价格中，无需支付额外费用。
- 提高业务关键服务层级的性能和可预测性。
注意
- 创建 Azure 支持票证以禁用实例的该功能。
还原功能和特性
下表汇总了时间点还原 (PITR)、异地还原和长期保留的功能和特性。
| 备份属性 | PITR | 异地还原 | LTR |
|---|---|---|---|
| SQL 备份类型 | 完整、差异、日志。 | PITR 备份的最新异地复制副本。 | 仅完整备份。 |
| 恢复点目标 (RPO) | 10 分钟，基于计算大小和数据库活动量。 | 最多 1 小时，基于异地复制。 1 | 一周（或用户策略）。 |
| 恢复时间目标 (RTO) | 还原所需的时间通常少于 12 小时，但可能需要更长时间，具体取决于大小和活动。 请参阅恢复。 | 还原所需的时间通常少于 12 小时，但可能需要更长时间，具体取决于大小和活动。 请参阅恢复。 | 还原所需的时间通常少于 12 小时，但可能需要更长时间，具体取决于大小和活动。 请参阅恢复。 |
| 保留 | 默认情况下为 7 天，可配置介于 1 到 35 天之间（基本数据库除外，这些数据库可配置为 1 到 7 天）。 | 默认启用，与源相同。2 | 默认情况下处于未启用状态。 最多保留 10 年。 |
| Azure 存储 | 默认为异地冗余。 可以选择配置区域冗余或本地冗余存储。 | 当 PITR 备份存储冗余设置为异地冗余时可用。 当 PITR 备份存储是区域冗余或本地冗余存储时不可用。 | 默认为异地冗余。 可以配置区域冗余或本地冗余存储。 |
| 将备份配置为不可变 | 不支持 | 不支持 | 不支持 |
| 在同一区域中还原新数据库 | 支持 | 受支持 | 支持 |
| 在另一区域中还原新数据库 | 不支持 | 任何 Azure 区域都支持 | 任何 Azure 区域都支持 |
| 在另一订阅中还原新数据库 | 不支持 | 不支持3 | 不支持3 |
| 通过 Azure 门户还原 | 是 | 是 | 是 |
| 通过 PowerShell 还原 | 是 | 是 | 是 |
| 通过 Azure CLI 还原 | 是 | 是 | 是 |
1 对于需要大型数据库且必须确保业务连续性的业务关键型应用程序，请使用故障转移组。
2 默认情况下，所有 PITR 备份都存储在异地冗余存储上，因此默认已启用异地还原。
3 解决方法是还原到新服务器，并使用资源转移功能将服务器移到另一个订阅，或者使用跨订阅数据库复制。
从备份还原数据库
若要执行还原，请参阅从备份还原数据库。 可以使用下列示例了解备份配置和还原操作。
| 操作 | Azure 门户 | Azure CLI | Azure PowerShell |
|---|---|---|---|
| 更改备份保留 | SQL 数据库 SQL 托管实例 |
SQL 数据库 SQL 托管实例 |
SQL 数据库 SQL 托管实例 |
| 更改长期备份保留 | SQL 数据库 SQL 托管实例 |
SQL 数据库 SQL 托管实例 |
SQL 数据库 SQL 托管实例 |
| 从某个时间点还原数据库 | SQL 数据库 SQL 托管实例 |
SQL 数据库 SQL 托管实例 |
SQL 数据库 SQL 托管实例 |
| 还原已删除的数据库 | SQL 数据库 SQL 托管实例 |
SQL 数据库 SQL 托管实例 |
SQL 数据库 SQL 托管实例 |
导出数据库
Azure 服务所做的自动备份不可直接下载或访问。 它们只能用于通过 Azure 进行还原操作。
导出 Azure SQL 数据库有其他选择。 如果需要为存档或移动到其他平台而导出数据库，可将数据库架构和数据导出到 BACPAC 文件。 BACPAC 文件是一个扩展名为 BACPAC 的 ZIP 文件，它包含来自数据库的元数据和数据。 可将 BACPAC 文件存储在 Azure Blob 存储中或本地位置的本地存储中，之后可导入回 Azure SQL 数据库、Azure SQL 托管实例或 SQL Server 实例。
还可以使用专用链接导入或导出 Azure SQL 数据库，或者导入或导出 Azure SQL数据库，而不允许 Azure 服务访问服务器。
备份计划
会在新的数据库创建或还原后立即计划第一次完整备份。 此备份通常可在 30 分钟内完成，但如果数据库较大，花费的时间可能更长。 例如，对已还原的数据库或数据库副本执行初始备份可能需要更长时间，该备份通常比新数据库还大。
在完成首次完整备份后，会自动计划和管理所有后续备份。 在平衡整体系统工作负荷时，SQL 数据库服务会确定所有数据库备份的确切时间。 无法更改备份作业的计划或禁用备份作业。
重要
- 对于新的、已还原的或复制的数据库，从初始完整备份之后创建了初始事务日志备份时开始，可以使用时间点还原功能。
- 超大规模数据库在创建后会立即受到保护，这与初始备份需要时间的其他数据库不同。 该保护是即时的，即使超大规模数据库是使用通过复制或还原获得的大量数据创建的。 若要了解详细信息，请参阅超大规模自动备份。
备份存储消耗量
使用 SQL Server 备份和还原技术时，将数据库还原到某个时间点需要一个不间断的备份链。 该链由一个完整备份、一个可选的差异备份以及一个或多个事务日志备份组成。
Azure SQL 数据库计划每周进行一次完整备份。 若要在整个保留期内提供 PITR，系统需要额外存储完整备份、差异备份和事务日志备份，且存储时间最多比配置的保留期长一周。
换言之，对于保留期内的任意时间点，必须有一个比保留期的最早时间更早的完整备份。 此外，从该完整备份到下一次完整备份，也必须有一个不间断的差异备份和事务日志备份链。
超大规模数据库使用不同的备份计划机制。 有关详细信息，请参阅超大规模备份计划。
将自动删除不再需要为提供 PITR 功能而保留的备份。 由于差异备份和日志备份需要早期的完整备份才可恢复，因此所有这三种备份类型会在每周都一并清除一次。
对于包括 TDE 加密数据库在内的所有数据库，所有完整备份和差异备份都会经过压缩，从而减少备份存储压缩和成本。 平均备份压缩率为 3 到 4 倍。 但是，根据数据的性质以及数据库中是否使用了数据压缩，可能会降低或提高。
重要
对于 TDE 加密的数据库，由于性能原因，不会压缩日志备份文件。 非 TDE 加密数据库的日志备份是压缩的。
Azure SQL 数据库按累积值形式计算使用的备份存储总量。 每小时向 Azure 计费管道报告此值。 管道负责在每个月底聚合此每小时用量，以计算你的消耗量。 删除数据后，随着备份的过期以及删除，消耗量将减少。 删除所有备份后，PITR 不再可用，计费会停止。
重要
即使已删除数据库，为了提供 PITR，仍会保留数据库的备份。 尽管删除再重新创建数据库可以节省存储和计算成本，但同时也会增加备份存储成本。 原因是每次删除数据库后，服务将为每个已删除的数据库保留备份。
监视消耗情况
对于 Azure SQL 数据库中的 vCore 数据库，每种类型的备份（完整备份、差异备份和日志备份）所使用的存储量采用单独的指标在数据库监视窗格上进行报告。 以下屏幕截图显示了如何监视单一数据库的备份存储消耗情况。
有关如何在超大规模中监视消耗的说明，请参阅监视超大规模备份消耗。
微调备份存储消耗量
只要备份存储消耗量不超过数据库的最大数据大小，就不会对备份收费。 额外的备份存储消耗量取决于个人数据库的工作负载和最大大小。 考虑实施下面一些优化技术，以减少备份存储消耗量：
- 根据需要将备份保留期缩短至最小。
- 避免以超过需要的频率执行大型写入操作，例如索引重建。
- 对于大规模数据加载操作，请考虑使用聚集列存储索引并遵循相关的最佳做法。 另外请考虑减少非聚集索引的数量。
- 在常规用途服务层级中，预配数据存储的价格低于备份存储的价格。 如果额外备份存储成本一直较高，可以考虑增大数据存储，以便节省备份存储的费用。
- 在应用程序逻辑中使用
tempdb而不是永久性表来存储临时结果或暂时性数据。 - 尽可能使用本地冗余备份存储（例如开发/测试环境）。
备份保留期
Azure SQL 数据库提供备份的短期保留和长期保留。 短期保留允许在数据库的保留期内执行 PITR。 长期保留为各种合规性要求提供备份。
短期保留
对于所有新的、还原和复制的数据库，Azure SQL 数据库会默认保留足以实现过去 7 天的 PITR 的备份量。 服务定期执行完整备份、差异备份和日志备份，以确保数据库可还原到为数据库定义的保留期内的任何时间点。
差异备份可以配置为每 12 小时进行一次或每 24 小时进行一次。 与 12 小时备份一次的频率相比，24 小时备份一次的差异备份频率可能会增加还原数据库所需的时间。 在 vCore 模型中，差异备份的默认频率是每 12 小时备份一次。 在 DTU 模型中，默认频率为每 24 小时备份一次。
创建数据库时，可为 STR 指定备份存储冗余选项，之后再对其进行更改。 如果在创建数据库后更改备份冗余选项，新备份将使用新的冗余选项。 使用之前的 STR 冗余选项创建的备份副本不会被移动或复制。 它们将保留在原始存储帐户中，直到保留期（1 到 35 天）已过。
可以在 1 到 35 天的范围内为每个活动数据库更改备份保留期，可配置为 1 到 7 天的基本数据库除外。 如备份存储消耗量中所述，为启用 PITR 而存储的备份可能早于保留期。 如果需要将备份保留至超过 35 天的最长短期保留期，可以启用长期保留。
如果删除数据库，系统会保留数据库的备份至特定的保留期，与为任何一个联机数据库的保留方式一样。 不能更改已删除数据库的备份保留期。
重要
如果删除服务器，则该服务器上的所有数据库也会被删除且无法恢复。 无法还原已删除的服务器。 但是，如果已经为数据库配置了长期保留，则不会删除 LTR 备份。 然后，可以使用这些备份将数据库还原到同一订阅中不同服务器上的 LTR 备份创建时间点。 若要了解详细信息，请查看还原长期备份。
长期保留
对于 SQL 数据库，可以配置完整长期保留 (LTR) 备份，使其在 Azure Blob 存储中最长保存 10 年。 配置启用 LTR 策略后，每周完整备份将自动复制到不同的存储容器。
为了满足不同的合规性要求，可为每周、每月和/或每年完整备份选择不同的保留期。 频率取决于策略。 例如，设置 W=0, M=1 将会每月创建一个 LTR 副本。 有关 LTR 的详细信息，请参阅长期保留。
更新现有数据库的备份存储冗余时，只会将更改应用到将来进行的后续备份，而不是现有备份。 数据库的所有现有 LTR 备份都将继续驻留在现有存储 Blob 中。 会根据配置的备份存储冗余复制新备份。
存储消耗量取决于所选的频率和 LTR 备份的保留期。 可以使用 LTR 定价计算器来估算 LTR 存储成本。
从 LTR 备份还原超大规模数据库时，“读取扩展”属性处于禁用状态。 若要在还原的数据库上启用读取扩展，请在数据库创建完后对其进行更新。 从 LTR 备份进行还原时，需要指定目标服务级别目标。
可以为从其他服务层级创建或迁移的超大规模数据库启用长期保留。 如果尝试为尚不支持的超大规模数据库启用 LTR，则会收到以下错误：“为此数据库启用长期备份保留时出现错误。 请联系 Microsoft 支持部门以启用长期备份保留。”在这种情况下，请联系 Azure 支持并创建支持票证来进行解决。
备份存储成本
备份存储的价格取决于购买模型（DTU 或 vCore）、选择的备份存储冗余选项以及区域。 备份存储按每月消耗的 GB 数收费，所有备份的费率相同。
备份存储冗余在以下方面影响备份成本：
Locally redundant price = published priceZone-redundant price = published price x 1.25Geo-redundant price = published price x 2
有关定价的信息，请参阅 Azure SQL 数据库定价页。
注意
Azure 发票仅显示已使用的超额备份存储，而不显示整个备份存储消耗量。 例如，在假设场景中，如果已预配 4 TB 的数据存储，则你会获得 4 TB 的免费备份存储空间。 如果你总共使用了 5.8 TB 备份存储空间，则 Azure 发票仅显示 1.8 TB，因为你只需为已使用的超额备份存储付费。
DTU 模型
在 DTU 模型中，对于数据库和弹性池，对于默认保留 7 天及以上的 PITR 备份存储，不需要额外付费。 PITR 备份存储的价格构成数据库或池价格的一部分。
重要
在 DTU 模型中，数据库和弹性池根据 LTR 备份实际消耗的存储对 LTR 备份存储收费。
vCore 模型
Azure SQL 数据库按累积值形式计算所有备份文件的总可计费备份存储量。 每小时向 Azure 计费管道报告此值。 管道在每个月底聚合此每小时用量，以获取你的备份存储消耗量。
如果删除数据库，备份存储消耗量将逐渐降低，因为较早的备份会过期并被删除。 由于差异备份和日志备份需要早期的完整备份才可恢复，因此所有这三种备份类型会在每周都一并清除一次。 删除所有备份后，计费会停止。
超大规模数据库的备份存储成本的计算方式不同。 有关详细信息，请参阅超大规模备份存储成本。
对于单一数据库，会提供与数据库最大数据存储大小 100% 相等的备份存储量，不收取额外的费用。 可使用以下公式来计算可计费的备份存储总用量：
Total billable backup storage size = (size of full backups + size of differential backups + size of log backups) - maximum data storage
对于弹性池，将会提供与最大数据存储相等的备份存储量作为池存储大小，不收取额外费用。 对于共用数据库，可计费备份存储总大小在池级别进行聚合，计算方式如下：
Total billable backup storage size = (total size of all full backups + total size of all differential backups + total size of all log backups) - maximum pool data storage
根据使用的备份存储冗余率，按每月消耗的 GB 数计算备份存储（如果有）总费用。 备份存储消耗量取决于各个数据库、弹性池以及托管实例的工作负荷和大小。 经过大量修改的数据库具有相对较大的差异备份和日志备份，因为这些备份的大小与数据更改量成比例。 因此，此类数据库的备份费用会更高。
举个简单的例子，假设数据库累积了 744 GB 的备份存储，并且此数量因数据库完全空闲会在整个月内保持恒定。 若要将此累积存储消耗量转换为每小时用量，可将此数量除以 744.0（每月 31 天 * 每天 24 小时）。 SQL 数据库将以固定费率向 Azure 计费管道报告数据库每小时使用了 1 GB 的 PITR 备份。 Azure 计费服务将聚合此消耗量，并显示整月的用量为 744 GB。 成本基于你所在区域的每月 GB 费率。
再提供一个示例。 假设同一空闲数据库的保留期在当月的中途从 7 天增加到了 14 天。 这种增长会导致总备份存储翻倍至 1,488 GB。 SQL 数据库将报告第 1 到 372 小时（上半月）的用量为每小时 1 GB。 它会报告第 373 到 744 小时（下半月）的用量为每小时 2 GB。 此用量将聚合到每月 1,116 GB 的最终帐单中。
实际的备份计费方案更加复杂。 由于数据库中的变化率取决于工作负载并且随时间变化，因此每个差异备份和日志备份的大小也各不相同。 备份存储的每小时消耗量会相应地波动。
每个差异备份还包含自上次完成完整备份以来在数据库中做出的所有更改。 因此，所有差异备份的总大小会在一周内逐渐增加。 然后，在一系列较旧的完整备份、差异备份和日志备份老化后，该大小会急剧下降。
例如，假设在完成完整备份后，紧接着运行一个繁重的写入活动，例如索引重新生成。 那么，会包含该索引重新生成操作做出的以下修改：
- 在重新生成期间创建的事务日志备份中所做的修改。
- 在下一个差异备份中所做的修改。
- 在下一次进行完整备份之前在每个差异备份中所做的修改。
如果在较大数据库中发生最后一种情况，当差异备份过大时，服务中的一项优化会导致创建完整备份而不是差异备份。 这会减少下一次完整备份之前的所有差异备份的大小。
如监视消耗情况中所述，可以监视每个备份类型（完整备份、差异备份、事务日志备份）随时间推移的总备份存储消耗量。
加密备份
如果使用 TDE 加密了数据库，则备份（包括 LTR 备份）会自动静态加密。 默认情况下，Azure SQL 中所有新的数据库都配置为启用 TDE。 有关 TDE 的详细信息，请参阅使用 SQL 数据库进行透明数据加密。
备份完整性
Azure SQL 工程团队持续不断地自动测试自动数据库备份的还原。 完成时间点还原后，数据库还会接受 DBCC CHECKDB 完整性检查。
在完整性检查期间发现的任何问题都将导致向工程团队发出警报。 有关详细信息，请参阅 SQL 数据库中的数据完整性。
所有类型的数据库备份都提供 CHECKSUM 选项，以便增加备份完整度。
合规性
将数据库从基于 DTU 的服务层级迁移到基于 vCore 的服务层级时，将保留 PITR 保留期以确保不会违反应用程序的数据恢复策略。 如果默认保留期不满足合规性要求，可以更改 PITR 保留期。 有关详细信息，请参阅更改 PITR 备份保留期。
注意
更改自动备份设置一文介绍如何删除设备或服务中的个人数据，并且可用于为 GDPR 下的义务提供支持。 有关 GDPR 的常规信息，请参阅 Microsoft 信任中心的 GDPR 部分和服务信任门户的 GDPR 部分。
使用 Azure Policy 强制实施备份存储冗余
如果根据数据驻留要求，你需要将所有数据保留在单个 Azure 区域中，则可能需要使用 Azure Policy 为 SQL 数据库强制实施区域冗余或本地冗余备份。
Azure Policy 是一项服务，可用于创建、分配和管理将规则应用于 Azure 资源的策略。 Azure Policy 可帮助你确保这些资源始终符合公司标准和服务级别协议。 有关详细信息，请参阅 Azure Policy 概述。
内置备份存储冗余策略
若要在组织级别强制实施数据驻留要求，可以使用 Azure 门户或 Azure PowerShell 将策略分配到订阅。
例如，如果启用策略“SQL 数据库应避免使用 GRS 备份冗余”，则不能使用默认存储创建数据库作为全局冗余存储，并且用户将无法使用 GRS，并会出现错误消息“在数据库创建或更新期间未能将备份存储帐户类型配置为 "Standard_RAGRS"”。
有关 SQL 数据库内置策略定义的完整列表，请查看策略参考。
重要
通过 T-SQL 创建数据库时，不会强制实施 Azure 策略。 若要在使用 T-SQL 创建数据库时指定数据驻留，请使用 LOCAL 或 ZONE 作为 CREATE DATABASE 语句中 BACKUP_STORAGE_REDUNDANCY 参数的输入。
相关内容
- 若要了解其他 SQL 数据库业务连续性解决方案，请参阅业务连续性概述。
- 若要更改备份设置，请参阅更改设置。
- 若要还原备份，请参阅使用备份进行恢复或使用 PowerShell 将数据库还原到某个时间点。
- 若要了解如何配置和管理 Azure Blob 存储中的自动备份的长期保留，并从这些备份进行还原，请参阅管理长期备份保留。
- 有关 Azure SQL 托管实例，请参阅 SQL 托管实例的自动备份。