你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn

从 Azure SQL 数据库中的备份还原数据库

适用于:Azure SQL 数据库

本文介绍从 Azure SQL 数据库中的备份中恢复任何数据库的步骤,包括超大规模数据库。 有关 Azure SQL 托管实例,请参阅从 Azure SQL 托管实例中的备份还原数据库

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

  • 在恢复到保持期内指定时间点的同一服务器上创建新数据库。
  • 在恢复到已删除数据库的删除时间的同一服务器上创建数据库。
  • 在恢复到最新备份时间的同一区域中的任一服务器上创建新数据库。
  • 在恢复到最近复制的备份点的其他任何区域中的任一服务器上创建新数据库。

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

重要

  • 还原期间无法覆盖现有数据库。
  • 数据库还原操作不会还原原始数据库的标记。

在 DTU 购买模型中使用“标准”或“高级”服务层级时,数据库还原可能会产生额外的存储费用。 如果还原的数据库的最大大小大于目标数据库的服务层级和服务目标提供的存储量,则会产生额外的费用。

有关额外存储定价的详细信息,请参阅 SQL 数据库定价页面。 如果实际使用的空间量小于附送的存储量,可以通过将数据库最大大小设置为附送的量,来避免产生额外的费用。

恢复时间

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

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

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

对于单个订阅,并行还原请求的数目存在以下限制。 这些限制适用于时间点还原、异地还原和从长期保留备份中还原的任意组合。

部署选项 处理的并发请求数最多为 # 提交的并发请求数最多为 #
单个数据库(每个订阅) 30 100
弹性池(每个池) 4 2,000

权限

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

  • 包含逻辑服务器的订阅或资源组中的参与者角色或 SQL Server 参与者角色的成员
  • 订阅或资源组所有者

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

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

时间点还原

可以将任何数据库还原到其保持期内的先前某个时间点。 还原请求可以指定要还原的数据库的任何服务层级或计算大小。 将数据库还原到弹性池时,请确保池中有足够的资源来容纳数据库。

还原在完成后会在原始数据库所在的服务器上创建新数据库。 还原的数据库将基于其服务层级和计算大小按标准费率计费。 在数据库还原完成之前,不会产生费用。

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

重要

  • 可以在同一台服务器上执行数据库的时间点还原。 当前不支持跨服务器、跨订阅和跨地区的时间点还原。 若要使用异地复制备份将数据库还原到其他区域,请参阅异地还原
  • 不能对异地辅助数据库执行时间点还原。 只能对主数据库执行此操作。
  • 超大规模数据库不支持 BackupFrequency 参数。
  • 数据库还原操作属于资源密集型操作,可能需要 S3 或更高的服务层级来还原(目标)数据库。 还原完成后,可以根据需要纵向缩减数据库或弹性池。
  • 数据库替换

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

  • 数据恢复

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

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

若要使用 Azure 门户将数据库恢复到某个时间点,请打开该数据库的概述页,并在工具栏上选择“还原”。 选择备份源,然后选择要从中创建新数据库的时间点备份点。

Screenshot of database restore options for SQL Database.

长期备份还原

若要对长期备份执行还原操作,可以使用 Azure 门户、Azure CLI、Azure PowerShell 或 REST API。 有关详细信息,请参阅还原长期备份。 长期保留不适用于超大规模数据库。

若要使用 Azure 门户 恢复长期备份,请转到逻辑服务器。 在“设置”下选择“备份”,然后在尝试还原的数据库的“可用 LTR 备份”下选择“管理”。

Screenshot of the Azure portal that shows available long-term retention backups.

已删除的数据库还原

使用 Azure 门户、Azure CLI、Azure PowerShell 和 REST API,可将已删除的数据库还原到同一服务器上的删除时间或更早的时间点。

重要

如果删除服务器,服务器的所有数据库和 PITR 备份也会一并删除。 无法还原已删除的服务器,并且无法从 PITR 备份还原已删除的数据库。 如果已为这些数据库配置 LTR 备份,可以使用这些备份将数据库还原到其他服务器。

若要使用 Azure 门户将已删除的数据库恢复到删除时间,请打开服务器的概述页,然后选择“删除的数据库”。 选择要还原的已删除数据库,然后输入要使用从备份还原的数据创建的新数据库的名称。

Screenshot of the Azure portal that shows how to restore a deleted database.

提示

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

异地还原

可以使用异地还原通过 Azure 门户、Azure CLI、Azure PowerShell 和 REST API 还原已删除的数据库。

重要

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

异地还原使用异地复制的备份作为源。 可在任何 Azure 区域的任何逻辑服务器上,从最新异地复制的备份中还原数据库。 即使服务中断导致数据库或整个区域无法访问,也依然能够请求异地还原。

当数据库因其托管区域发生事故而不可用时,异地还原是默认的恢复选项。 可将数据库还原到任何其他区域中的服务器。

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

Illustration of geo-restore.

在 Azure 门户中,新建一个单一数据库,然后选择可用的异地还原备份。 新建的数据库包含异地还原的备份数据。

若要通过 Azure 门户异地还原所选区域和服务器中的单一数据库,请执行以下步骤:

  1. 在“仪表板”中,选择“添加”>“创建 SQL 数据库”。 在“基本信息”选项卡上输入所需的信息。
  2. 选择“其他设置”。
  3. 对于“使用现有数据”,请选择“备份”。
  4. 从可用的异地还原备份列表中选择一个备份。

Screenshot of the Azure portal that shows options to create a database.

完成从备份创建数据库的过程。 在 Azure SQL 数据库中创建数据库时,该数据库包含已还原的异地还原备份。

异地还原注意事项

有关使用异地还原的详细信息,请参阅使用异地还原进行恢复

注意

有关从中断中还原的详细信息,请参阅 Azure SQL 数据库灾难恢复指南Azure SQL 数据库高可用性和灾难恢复清单

异地还原是 SQL 数据库中提供的最基本的灾难恢复解决方案。 它依赖于自动创建的异地复制备份,其恢复点目标 (RPO) 最长为 1 小时,估计的恢复时间目标 (RTO) 最长为 12 小时。 它不保证在发生区域性的服务中断后,目标区域可提供足够的容量来还原数据库,因为此时的需求可能会急剧上升。 如果应用程序使用相对较小的数据库,并且对业务不是很重要,则异地还原是合适的灾难恢复解决方案。

对于需要大型数据库且必须确保业务连续性的业务关键型应用程序,请使用故障转移组。 该功能提供的 RPO 和 RTO 要低得多,并且始终可以保证容量。

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

注意

如果计划使用异地还原作为灾难恢复解决方案,建议定期进行演练,以验证应用程序是否能够对丢失最近所做的数据修改以及恢复过程中的所有操作保持容忍态度。

后续步骤