Azure SQL Database 地域还原

原文地址：https://azure.microsoft.com/blog/2014/09/13/azure-sql-database-geo-restore/

本文是Azure SQL Database业务连续性/灾难恢复(BCDR)功能系列文章的延续，文中将重点介绍地域还原。在上一篇关于标准地域复制的文章中，讨论了如何将各种业务连续性功能映射到服务层。我们通过下表快速回顾一下相关知识。

什么是地域还原？

地域还原可从地域冗余备份还原数据库以创建新的数据库。用户可以在任意Azure区域的任意服务器上创建该数据库。由于使用地域冗余备份作为来源，所以即便因中断导致数据库无法访问，仍然可以用来恢复数据库。您可以免费为各服务层自动启用地域还原。

地域还原详细说明

地域还原与时间点还原采用的技术相同，只有一点重要区别。它会从地域复制 Blob 存储(RA-GRS)的最新日备份副本还原数据库。该服务会为每个活动数据库创建一个备份链，其中包括每周完整备份、每日差异备份以及每 5 分钟保存一次的事务日志。其中，还会将最新完整备份和差异备份复制到 Blob 存储。由于这些 Blob 经过地域复制处理，因而可确保即使主要地区发生大规模故障也可提供每日备份。图 1 对该流程进行了阐释。

图 1. 地理复制–复制到存储容器的每周备份和每日备份。

如果某一地区的大规模故障导致您的数据库应用程序不可用，可以通过地域还原利用最新的每日备份将数据库还原到其他任一地区的服务器。因为每日复制一次备份，因此最多仅会丢失 24 小时的数据(RPO)。图 2 对恢复流程进行了阐释。

图 2.  从最后的每日备份还原数据库。

地域还原的使用方法

您可以在受影响的服务器上，使用Azure管理门户的Backups选项卡调用地域还原。此选项卡提供了该服务器上所有数据库的所有可用备份的列表，并会显示每个数据库的最后备份时间。选择用来还原的备份后，可以为新的数据库提供名称并指定目标服务器，目标服务器可位于任何区域。一经确认，还原请求将被加入队列，以便在目标区域中进行处理。图3-5对相关步骤进行了阐释。

图3. 选择包含要恢复的数据库的降级服务器

图 4. 选择要从备份列表中恢复的数据库

图 4. 指定用于还原数据库的服务器

图 5. 监控正在还原的数据库的状态

与标准和活动地域复制一样，地域还原也可通过REST API、PowerShell及 Azure管理门户进行管理和调用。Azure管理门户十分适合对少量数据库进行临时地域还原。REST API或PowerShell可用于为恢复多个数据库编写脚本，或者与自定义管理脚本或应用程序集成。您可以阅读有关Azure SQL Database REST API和Azure SQL Database Recovery PowerShell API的详细信息。

如果不小心触发了还原操作，而后希望取消还原操作，只需连接目标主数据库并丢弃还原的数据库即可实现。注意，只要启动还原进程就会显示其数据库记录。因此，无需等待还原完成即可丢弃。这样，就能避免造成任何计费影响。

影响恢复时间的因素

恢复时间受多种因素的影响：数据库大小、数据库性能水平，以及目标地区处理的并发还原请求数量。如果某个地区长期中断，其他地区可能需要处理大量地域还原请求。如有必要，该服务会限制还原操作占用的资源，从而确保该区域的现有工作负载不会受到负面影响。如果包含大量请求，可能会延长该区域数据库的恢复时间。

虽然所有服务层都提供地域还原功能，但这是SQL Database中提供的最基本的DR解决方案（最长的 RPO 和 RTO）。对于最大大小为2 GB的基本数据库，地域还原会提供RTO为 24 小时的合理 DR 解决方案。对于标准或高级数据库，如果希望大大缩短恢复时间，或者降低数据丢失几率，应考虑使用标准或活动地域复制。这两种地域复制恢复方案的RPO 和 RTO大大降低，因为它们只需要故障转移到持续复制的辅助服务器。

DR演练

证实生产数据库受到充分保护以便抵御灾难往往是一项合规要求。由于可以随时使用地域还原，您可以开展定期 DR 演练，以便确认基于此恢复选项的 DR 程序是否有效。

小结

地域还原、标准地域复制和活动地域复制的组合为您提供了大量选项，从而实现满足应用程序和业务需求的业务连续性解决方案。除前面讨论的成本和 SLO 区别以外，您选择的方案还定义了哪些业务连续性场景是受支持的。下表对这些区别进行了总结：

我们鼓励大家尝试执行地域还原，确定其在BCDR策略中可能占据的位置。我们将一如既往地仔细聆听大家的反馈意见，请告诉我们您的想法。

您可以在这篇文章中阅读有关Azure SQL Database备份和还原的详细信息。