从 Azure SQL 托管实例中的备份还原数据库

适用于:Azure SQL 托管实例

本文分步介绍如何在 Azure SQL 托管实例中使用备份恢复数据库。 有关 Azure SQL 数据库,请参阅从 Azure SQL 数据库中的备份还原数据库

概述

自动数据库备份有助于保护数据库,使其免受用户和应用程序错误、数据库意外删除和长时间中断的影响。 此内置的功能适用于所有服务层级和计算大小。 以下选项适用于通过自动备份进行的数据库恢复:

  • 在恢复到保持期内指定时间点的同一托管实例上创建新数据库。
  • 在恢复到保持期内指定时间点的同一托管实例或其他托管实例上创建新数据库。
  • 在恢复到已删除数据库的删除时间的同一托管实例或其他托管实例上创建数据库。
  • 在恢复到最新备份点的同一订阅或同一租户和同一区域内其他订阅中的任何托管实例上创建新数据库。

如果你已配置长期保留 (LTR),则还可以从任何实例上的任何长期保留备份创建新数据库。

重要

还原期间无法覆盖现有数据库。

恢复时间

多个因素影响通过自动数据库备份还原数据库所需的恢复时间:

  • 数据库的大小
  • 数据库的计算大小
  • 所涉及的事务日志数
  • 需要重新播放以恢复到还原点的活动数量
  • 还原到不同区域时的网络带宽
  • 目标区域中处理的并行还原请求数

对于较大或非常活跃的数据库,还原可能要花费几个小时。 某个区域发生故障的时间较长可能会导致大量要求进行灾难恢复的异地还原请求。 存在很多请求时,单个数据库的恢复时间可能会增加。 大部分数据库还原操作可在 12 小时内完成。

提示

对于 Azure SQL 托管实例,系统更新优先于正在进行的数据库还原。 如果有 SQL 托管实例的系统更新,则所有挂起的还原都将暂停,但在此更新被应用后就会立即恢复。 此系统行为可能会延长还原时间,并且对长时间运行的还原可能影响特别大。

为了实现可预测的数据库还原时间,请考虑配置维护时段,以便在特定的日期和时间计划系统更新。 另请考虑在计划维护时段外运行数据库还原。

权限

若要使用自动备份进行恢复,你必须是:

  • 订阅中 SQL Server 参与者角色或 SQL 托管实例参与者角色(具体取决于恢复目标)的成员
  • 订阅所有者

有关详细信息,请参阅 Azure RBAC:内置角色

可以使用 Azure 门户、PowerShell 或 REST API 进行恢复。 不能使用 Transact-SQL。

时间点还原

可以将数据库还原到先前时间点。 该请求可以指定还原的数据库的任何服务层级或计算大小。 确保你要将数据库还原到其中的实例上有足够的资源。

还原完成后,它会在目标实例上新建数据库,无论它是同一实例还是其他实例。 还原的数据库将基于其服务层级和计算大小按标准费率计费。 在数据库还原完成之前,不会产生费用。

通常,为恢复目的将数据库还原到较早点。 可将还原的数据库视为原始数据库的替代数据库,或使用它作为数据源来更新原始数据库。

重要

不能对异地辅助数据库执行时间点还原。 只能对主数据库执行此操作。

  • 数据库替换

    若要用还原的数据库替换原始数据库,则应指定原始数据库的计算大小和服务层级。 然后,可以使用 T-SQL 中的 ALTER DATABASE 命令来重命名原始数据库,并为还原的数据库指定原有的名称。

  • 数据恢复

    如果你打算从还原的数据库检索数据以从用户或应用程序错误中恢复,则需要编写并运行一个数据恢复脚本,用于从还原的数据库提取数据并将其应用到原始数据库。 尽管还原操作可能需要很长时间才能完成,但在整个还原过程中,你都可以在数据库列表中看到正在还原的数据库。

    如果在还原期间删除数据库,则会取消还原操作。 不会对未完成还原的数据库收费。

若要使用 Azure 门户将 SQL 托管实例中的数据库恢复到某个时间点,可以在门户中转到相应的数据库并选择“还原”。 或者,可以打开目标 SQL 托管实例概述页,然后在工具栏上选择“+ 新建数据库”,以打开“创建 Azure SQL 托管数据库”页。

屏幕截图:Azure 门户中的“SQL 托管实例概述”窗格,已选择添加新数据库。

在“基本信息”选项卡上提供目标托管实例详细信息,并从“数据源”选项卡中选择一种备份类型。

Azure 门户的屏幕截图,其中显示了“创建 Azure SQL 托管数据库”页面的“数据源”选项卡,其中选择了时间点还原。

有关更多详细信息,请查看时间点还原一文。

已删除的数据库还原

在同一实例或非源实例上,可以将已删除的数据库还原到删除时间点或更早的时间点。 目标实例可以与源实例位于同一订阅,也可以位于不同订阅。 通过从备份创建新数据库来还原已删除的数据库。

重要

无法还原已删除的托管实例。 如果删除托管实例,也会删除其所有数据库,并且无法还原到删除时间或更早的时间点。 如果配置了长期保留 (LTR),则仍可将数据库从删除的实例还原到另一个实例,并还原到 LTR 备份的时间点。

若要使用 Azure 门户恢复数据库,请打开托管实例的概述页,然后选择“备份”。 选择显示“已删除”备份,然后选择要恢复的已删除备份旁的“还原”,以打开“创建 Azure SQL 托管数据库”页。 在“基本信息”选项卡中提供目标托管实例的详细信息,在“数据源”选项卡中提供源托管实例的详细信息。在“其他设置”选项卡中配置保留设置。

屏幕截图:Azure 门户的 SQL 托管实例的备份页面,显示已删除的数据库并选择“还原”操作。

提示

最近删除的数据库可能需要几分钟的时间才会出现在 Azure 门户的“删除的数据库”页上,当你要使用命令行显示删除的数据库时也会出现这种情况。

异地还原

重要

  • 异地还原仅适用于配置了异地冗余备份存储的托管实例。 如果当前没有对数据库使用异地复制的备份,可以通过配置备份存储冗余对此进行更改。
  • 只能对驻留在同一订阅中的托管实例执行异地还原。

当数据库因其托管区域发生事故而不可用时,异地还原是默认的恢复选项。 可以将数据库还原到任何其他区域的实例中。 可在任何 Azure 区域中的任何托管实例上通过最新异地复制的备份还原数据库。 异地还原使用异地复制的备份作为源。 即使服务中断导致数据库或数据中心无法访问,也依然能够请求异地还原。

在创建备份后,将其异地复制到其他区域中的 Azure Blob 时会出现延迟。 因此,还原的数据库可能比原始数据库晚最多一个小时。 下图演示了如何从另一区域中的最后一个可用备份还原数据库。

插图显示跨区域还原数据库来进行异地还原。

在 Azure 门户中,可以将异地复制的备份还原到现有实例中,也可以新建托管实例并选择可用的异地还原备份。 新建的数据库包含异地还原的备份数据。

若要还原到现有实例,请按照时间点还原中的步骤操作,并确保选择适当的源实例和目标实例以将数据库还原到预期实例。

若要使用 Azure 门户异地还原到新实例,请执行以下步骤:

  1. 转到新的 Azure SQL 托管实例。
  2. 选择“新建数据库”。
  3. 输入数据库名称。
  4. 在“数据源”下,选择适当的备份类型,然后输入数据源的详细信息。
  5. 从可用的异地还原备份列表中选择一个备份。

完成创建实例数据库的过程后,它将包含还原的异地还原备份。

异地还原注意事项

异地还原是 Azure SQL 托管实例中提供的最基本的灾难恢复解决方案。 它依赖于次要(配对)区域中自动创建的异地复制的备份。 下面是异地还原的一些注意事项:

  • 恢复点目标 (RPO) 最多为 1 小时。
  • 还原过程(恢复时间目标 - RTO)通常不会超过 12 小时,不过可能会根据数据库大小而有所不同,因此还原可能会超出此时间范围。
  • 次要(配对)区域是主要区域的 AZzure 存储设置。 无法更改次要区域。
  • 由于填充新数据时存在滞后时间,因此新创建/还原的数据库在其他区域中可能不会立即显示为可还原。 如果客户看不到新数据库的备份,则应预计等待期最长为 24 小时。

必须承认,对于拥有相对较小的数据库且对业务并非非常重要的应用程序而言,异地还原是合适的灾难恢复解决方案。 对于需要大型数据库且必须确保业务连续性的业务关键型应用程序,请使用故障转移组。 该功能提供的 RPO 和 RTO 要低得多,并且始终可以保证容量。

有关业务连续性选项的详细信息,请参阅业务连续性概述

限制

使用备份和 Azure SQL 托管实例时,请考虑以下限制:

  • 数据库的异地还原只能对与源 SQL 托管实例相同的订阅中的实例执行。
  • 默认情况下,Azure SQL 托管实例数据库使用 TDE 进行加密。 当源数据库使用客户管理的密钥 (CMK) 作为 TDE 保护程序时,若要将数据库还原到源 SQL 托管实例以外的实例,目标实例必须有权访问 Azure Key Vault 中用于加密源数据库的同一密钥,或者你在执行备份之前必须在源数据库上禁用 TDE 加密。
  • 只能使用 sys.dm_exec_requestssys.dm_operation_status 动态管理视图来跟踪还原过程的进度。
  • 恢复点目标 (RPO) 最多为 1 小时。
  • 恢复时间目标 (RTO) 大约为 12 小时,但可能根据数据库大小而有所不同,并且活动可能会超出此时间范围。
  • 无法更改次要(配对)区域。
  • 由于填充新数据时存在滞后时间,因此新创建/还原的数据库在其他区域中可能不会立即显示为可还原。 新数据库的备份可能需要长达 24 小时才能可见。