创建 SQL Server 灾难恢复策略（DR），可以在数据库出现不一致时（例如遭受网络攻击或硬件故障），及时地执行 SQL Server 数据库恢复。它有助于减少数据丢失的情况，从而减少停机时间并保持业务连续性。
本文内容：
1. 为什么需要 SQL Server 灾难恢复策略？
2. SQL Server 灾难恢复策略的可选方案
3. 如何创建 SQL Server 灾难恢复策略
4. 如何评估 SQL Server 灾难恢复策略是否合适
5. SQL Sever 灾难恢复一体化解决方案
6. 提高整体效率的最佳实践
为什么需要 SQL Server 灾难恢复策略？
需要创建 SQL Server 灾难恢复策略的原因有很多。以下是主要的几条：
- 保护关键业务数据，例如客户记录或财务交易。
- 确保系统快速恢复在线，以避免运营中断。
- 满足医疗保健或金融等行业对数据保护的监管要求。
- 通过确保危机期间的数据可用性来建立信任。
SQL Server 灾难恢复策略的重要考量点：
- 恢复时间目标（RTO）：恢复前可接受的最大停机时间。例如，2 小时 RTO 意味着系统必须在 2 小时内恢复。
- 恢复点目标（RPO）：可接受的最大数据丢失量，以时间为单位。1 小时的 RPO 意味着您最多可以丢失 1 小时的数据。
- 恢复水平目标（RLO）：恢复的特异性，例如还原整个实例、数据库或特定表。
SQL Server 灾难恢复策略的可选方案
借助 SQL Server 的多项内置灾难恢复功能，用户可以获得满意的结果。
解决方案 1. 备份和恢复 SQL Server
本方案是所有 SQL Server 灾难恢复策略的基础，包括定期备份和灾后恢复。
关于备份，以下是可用的备份类型。可以使用它们来满足企业备份要求。
- 完整备份：覆盖整个数据库。
- 差异备份：捕获自上次完整备份以来的更改。
- 事务日志备份：备份自上次日志备份以来的所有事务，从而启用时间点恢复。
优点：易于实施、经济高效且得到普遍支持。
用例：非常适合非关键系统，或与其他灾难恢复解决方案一起作为辅助措施。
应用场景举例：一家小公司每天都会维护其客户数据库，并在需要时或在服务器中断的情况下进行恢复。
注意：还原大型数据库可能非常耗时。上次备份之后的数据可能会丢失。
解决方案 2. 尝试日志传送
利用日志传送（Log Shipping），用户可以自动备份主数据库中的事务日志，并将其恢复到单独服务器上的辅助数据库。以下是选择该方法的一些关键功能：
- 支持高可用性（HA）和灾难恢复 [DR]。
- 需要手动故障转移，这可能会增加 RTO。
- 需要一台监控服务器，用于跟踪操作。
优点：经济高效，在有限带宽下也能正常工作，并支持多个辅助数据库。
使用案例：适用于需要跨区域使用温备用服务器的企业。
应用场景举例：公司使用 Log shipping 来维护不同城市的辅助数据库，并在区域性故障期间手动切换到该数据库。
解决方案 3. 使用数据库镜像
数据库镜像指的是在单独的服务器上维护两个同步的数据库副本（主体和镜像）。事务从主体发送到镜像。可以在不同的模式下执行数据库镜像。
- 高安全模式（同步）：确保零数据丢失，但可能会降低性能。
- 高性能模式（异步）：提高性能，但有少量数据丢失的风险。
优点：为高可用性提供快速故障转移，并支持跨数据中心的灾难恢复。
使用案例：适用于需要在数据中心内进行同步复制的旧系统。
应用场景举例：一家金融公司使用异步镜像将交易数据库复制到远程站点。
注意：自 SQL Server 2012 以来不经常使用，被 Always On 可用性取代。每个数据库只能有一个镜像。
解决方案 4. 使用 SQL Server 复制
它将数据和数据库对象复制并分发到另一个数据库，使它们保持同步。可以使用 SQL Server 中的复制功能：
- 事务复制：接近于实时地复制事务。
- 合并复制：允许脱机更改和以后的同步。
- 快照复制：在特定时间点复制数据。
优点：灵活分配数据，支持报告，并可用于灾难恢复。
使用案例：非常适合需要数据进行报告或冗余的场景，例如卸载只读查询。
应用场景举例：零售连锁店将销售数据复制到报表服务器，将其用作灾难恢复备用方案。
注意：不是灾难恢复的首选方案，管理复杂，并且可能无法保证零数据丢失。
解决方案 5. 用于灾难恢复的始终在线可用性（Always On Availability）
SQL Server 2012 中引入的高级 HA 和 DR 解决方案，取代了数据库镜像。它最多支持 8 个具有同步或异步复制的辅助副本。
- 自动故障转移
- 用于负载平衡的可读次要副本
- 用于跨站点灾难恢复的多子网集群
优点：强大、灵活，同时支持 HA 和 DR。可读辅助数据库可减少主服务器负载。
使用案例：非常适合需要自动故障转移和多功能存储容量的任务关键型应用程序。
应用场景举例：一家全球电子商务平台使用 Availability Groups 跨大洲复制其订单数据库，确保在区域性中断期间的正常运行时间。
解决方案 6. Always On 故障转移集群实例
通过跨多个节点（通常在单个数据中心内）对 SQL Server 实例进行集群，提供实例级高可用性。该方法带有不同的内置功能，帮助用户满足期望。
- 使用 Windows Server 故障转移群集 （WSFC） 进行自动故障转移。
- 需要共享存储，例如存储区域网络（SAN）。
优点：确保实例级故障的零数据丢失，并与其他灾难恢复解决方案集成。
用例：最适合数据中心内的 HA，通常与 Log Shipping 等 DR 解决方案配合使用。
应用场景举例：医院使用该方案来确保其患者数据库在服务器维护期间保持可用。
如何创建 SQL Server 灾难恢复策略
用户可以根据最佳行业实践，一步步地创建并实施强大的 SQL Server 灾难恢复方案。
第 1 步 - 确定指标：根据业务需求和设定的预算定义 RTO、RPO 和 RLO。
第 2 步 - 评估灾难可能性：评估1-3年的风险，并相应地优先考虑各种情况。
第 3 步 - 选择备份和恢复策略：经常安排备份并测试恢复过程以验证备份完整性。
第 4 步 - 实施 HA/DR 解决方案：选择满足要求的解决方案。
第 5 步 - 记录和测试：经常记录并执行灾难恢复演习以防止失败。
如何评估 SQL Server 灾难恢复策略是否合适
- RTO/RPO 需求：低 RTO/RPO（例如，<1 小时）需要可用性组或 FCI；更高的 RTO/RPO 适合日志传送。
- 预算：适用于Availability Groups 的企业版成本高昂；日志传送和备份更实惠。
- 复杂性：Availability Groups 和 FCI 需要高级技能；备份和日志传送更简单。
- 地理需求：跨站点 DR 需要 Availability Groups 或日志传送；单站点 HA 适合 FCI。
- 应用需求：可读辅助数据库（Availability Groups）适用于报告密集型应用程序。
SQL Sever 灾难恢复一体化解决方案
从上文可以明显看出，使用手动选项会延迟问题的解决，并且还可能再次造成数据丢失。
因此，专业人士始终推荐更高级的 SQL Server 数据库恢复解决方案，而不是使用手动选项，以节省时间和精力，同时也能获得成功的结果。将数据库从严重损坏的状态，顺利地直接恢复到 SQL Server、CSV 文件或 SQL 脚本中，同时保证数据完整性。
鸿萌在数据备份领域深耕多年，为各类型的企业和组织提供符合需要的灾备及灾难恢复解决方案。
提高整体效率的最佳实践
遵循以下做法，可以保护企业数据免受不必要的错误和网络攻击。
- 定期测试：每季度进行一次 DR 演练，以确保故障转移和恢复过程正常工作。
- 全面的文档：在 DR 计划中包括系统详细信息、恢复步骤和 SLA。
- 员工培训：对 DBA 和 IT 人员进行故障转移过程和工具（如 DBCC CHECKDB）的培训，以进行损坏检查。
- 监控和警报：使用 SQL Server Agent 或第三方工具监控备份和复制状态。
- 分层保护：将备份与 HA/DR 解决方案相结合，以实现最大的弹性。
- 云注意事项：探索云服务，以实现可扩展性和存储多功能性。
结论
SQL Server 灾难恢复对于保护业务数据和确保中断期间的连续性至关重要。通过遵循备份和还原、日志传送、Always On 可用性组和云集成等解决方案，企业可以根据需要构建强大的灾难恢复策略。
同时，除了手动设置之外，还可以选择更为专业的第三方 SQL Server 数据库恢复方案来进行恢复。