适用于：
Azure SQL 数据库Fabric SQL 数据库
本文概述了Azure SQL 数据库的业务连续性和灾难恢复功能，介绍了从中断事件中恢复的选项和建议，这些事件可能导致数据丢失或导致数据库和应用程序不可用。 了解对一些情况的处理方式，包括用户或应用程序错误影响数据完整性、Azure 可用性区域或区域发生服务中断，或者应用程序需要维护。
概述
Azure SQL 数据库中的业务连续性是指通过提供可用性、高可用性和灾难恢复，使企业能够继续在中断时继续运营的机制、策略和过程。
大多数情况下，SQL 数据库会处理云环境中可能发生的中断事件，让应用程序和业务流程保持运行状态。 然而，在一些破坏性事件中，缓解措施可能需要一些时间，例如：
- 用户意外删除或更新了表中的某行。
- 恶意攻击者成功删除了数据或数据库。
- 灾难性自然灾害事件导致数据中心或可用性区域或区域瘫痪。
- 配置更改、软件 bug 或硬件故障导致的罕见数据中心、可用性区域或区域范围的中断。
有关最大化可用性并实现更高业务连续性的规范性建议，请参阅：
高可用性
Azure SQL 数据库具有核心复原和可靠性承诺，可防范软件或硬件故障。 自动化数据库备份，以保护数据免受损坏或意外删除。 作为平台即服务（PaaS），Azure SQL 数据库服务以现成的功能提供可用性，行业领先的可用性 SLA 为 99.99%。
若要在 Azure 云环境中实现高可用性，请启用 区域冗余。 通过区域冗余，数据库或弹性池使用 Azure 可用性区域 来确保对区域性故障的复原能力。
- 许多 Azure 区域可提供可用性区域，这些区域是一个区域内的独立数据中心组，具有独立的电源、冷却和网络基础结构。
- 可用性区域旨在当一个区域出现中断时，在其余区域提供区域服务、容量和高可用性。
通过启用区域冗余，数据库或弹性池可从区域性硬件和软件故障中复原，对应用程序来说恢复过程是透明的。 启用高可用性后，Azure SQL 数据库服务可提供 99.995% 的高可用性 SLA。
灾难恢复
若要跨区域实现更高的可用性和冗余，可以启用灾难恢复功能，以便从灾难性区域故障中快速恢复数据库。 Azure SQL 数据库灾难恢复选项：
- 通过活动异地复制功能，可以为主数据库创建在任何区域的持续同步的可读辅助数据库。
- 除了在主数据库和辅助数据库之间提供连续同步之外，故障转移组还允许您将逻辑服务器上的部分或全部数据库复制并故障转移到另一个区域的辅助逻辑服务器上。 故障转移组可提供保持不变的读写和只读侦听器端点，因此无需在故障转移后更新应用程序连接字符串。
- 异地还原允许当您无法访问主区域的数据库时，通过在任何 Azure 区域的现有服务器上创建新数据库，从地理复制备份中恢复，从而应对区域性中断。
下表比较了主动异地复制和故障转移组，这是用于 Azure SQL 数据库的两个灾难恢复选项：
| 活动异地复制 | 故障转移组 | |
|---|---|---|
| 主数据库和辅助数据库之间的连续数据同步 | 是 | 是 |
| 同时故障转移多个数据库 | 否 | 是 |
| 故障转移后连接字符串保持不变 | 否 | 是 |
| 支持读取缩放 | 是 | 是 |
| 多个副本 | 是 | 否 |
| 可以与主服务器位于同一区域 | 是 | 否 |
RTO 和 RPO
制定业务连续性计划时，请了解应用程序在中断事件发生后完全恢复之前的最大可接受时间。 量化灾难恢复业务需求的两种常见方法是：
- 恢复时间目标（RTO）：应用程序在计划外中断事件后完全恢复所需的时间。
- 恢复点目标（RPO）：可以从计划外中断事件中容忍的数据丢失的时间量。
下表比较了每个业务连续性选项的 RPO 和 RTO：
| 业务连续性选项 | RTO（故障时间） | RPO（数据丢失） |
|---|---|---|
| 高可用性 （使用区域冗余） |
通常不到30秒 | 0 |
| 灾难恢复 （将故障转移组与客户管理的故障转移策略或活动异地复制配合使用） |
通常不到60秒 | 等于或大于 0 （取决于在中断事件之前尚未复制的数据更改） |
| 灾难恢复 （使用异地还原） |
通常取决于 Azure 存储复制的情况，为分钟或小时。 | 通常为分钟或小时，具体取决于数据库备份的大小 |
可提供业务连续性的功能
从数据库角度看，主要有四种潜在的中断场景。 下表列出了可用于缓解潜在业务中断方案的SQL 数据库业务连续性功能：
| 业务中断场景 | 业务连续性功能 |
|---|---|
| 影响数据库节点的本地硬件或软件故障。 | 为了缓解本地硬件和软件故障，Azure SQL 数据库包括 一个可用性体系结构，该体系结构可保证从这些故障中自动恢复，并提供高达 99.99% 可用性 SLA。 |
| 通常由应用程序 bug 或人为失误导致的数据损坏或删除。 此类故障特定于应用程序，通常无法通过数据库服务检测到。 | 为了防止企业丢失数据，SQL 数据库每周自动创建完整数据库备份，每 12 小时或 24 小时自动创建差异数据库备份，每隔 5 - 10 分钟自动创建事务日志备份。 默认情况下，所有服务层级的备份都会在异地冗余存储中存储 7 天。 对于时间点还原，所有服务层级（“基本”层级除外）都支持可配置的备份保留期，最长为 35 天。 如果服务器尚未删除或者已配置长期保留 (LTR)，可将已删除的数据库还原到删除时的时间点。 |
| 罕见的数据中心或可用性区域中断，可能是由自然灾害事件、配置更改、软件 bug 或硬件故障引起的。 | 若要缓解数据中心或可用性区域级别的中断，请为数据库或弹性池启用区域冗余，以使用 Azure 可用性区域，并在 Azure 区域中的多个物理区域中提供冗余。 启用区域冗余可确保数据库或弹性池以高达 99.995% 的高可用性 SLA 从区域性故障中复原。 |
| 罕见 的区域中断 会影响所有可用性区域及其构成的数据中心，可能是由灾难性自然灾害事件引起的。 | 若要减少区域范围的中断风险，请使用以下选项之一启用灾难恢复： - 连续数据同步选项，如故障转移组（推荐）或活动异地复制，这样您可以在次要区域中创建副本以进行故障转移。 将备份存储冗余选项配置为异地冗余备份存储，以使用异地还原功能。 |
为区域中断做准备
无论使用哪种业务连续性功能，都必须在另一个区域中准备辅助数据库。 如果准备不当，在进行故障转移或恢复后，需要花更多时间让应用程序联机，还可能需要进行故障排除，进而延迟 RTO。 请按照为区域中断准备辅助数据库的清单进行操作。
恢复同一 Azure 区域内的数据库
可以使用自动数据库备份将数据库还原到过去的某个时间点。 可以通过这种方式从人为错误导致的数据损坏中恢复。 时间点还原（PITR）允许在同一服务器上创建新数据库，该数据库表示损坏事件之前的数据状态。 有关恢复时间，请参阅 RTO 和 RPO。
如果应用程序时间点还原支持的最大备份保留期不够，可以通过配置长期保留（LTR）策略来延长备份保留期。 有关详细信息，请参阅 长期保留。
在停机时间最短的情况下升级应用程序
有时，应用程序由于维护（例如应用程序升级）而必须脱机。 可以使用 SQL 数据库活动异地复制来管理云应用程序的滚动升级。 如果出现问题，异地复制还可以提供恢复路径。
使用备用副本节省成本
如果次要副本仅用于灾难恢复 (DR)，并且没有任何读取或写入工作负载，则可以通过在配置新的活动异地复制关系时指定备用数据库来节省许可成本。
有关详细信息，请参阅免许可证备用副本。