介绍恢复时间目标和恢复点目标
了解恢复时间目标和恢复点目标对于高可用性和灾难恢复 (HADR) 计划至关重要，因为它们是任何可用性解决方案的基础。
恢复时间目标
恢复时间目标 (RTO) 是指在出现中断或发生问题后，可用于恢复资源的最长时间。 如果该过程所用的时间比 RTO 长，可能会造成一些后果，如罚款、工作无法完成等。 可以为整个解决方案（包括所有资源）以及单个组件（如 SQL Server 实例和数据库）指定 RTO。
恢复点目标
恢复点目标 (RPO) 是指数据库应该恢复到的时间点，相当于企业愿意接受的最大数据丢失量。 例如，假设一个包含 SQL Server 的 IaaS VM 在上午 10:00 出现中断，而 SQL Server 实例中数据库的 RPO 为 15 分钟。 无论使用什么功能或技术来恢复该实例及其数据库，预期最多丢失 15 分钟的数据。 这意味着数据库可以还原到上午 9:45 或更晚的时间，以确保实现满足 RPO 规定的最小数据丢失量或零数据丢失。 可能存在一些决定是否可实现 RPO 的因素。
定义恢复时间目标和恢复点目标
RTO 和 RPO 受企业要求驱动，但也基于各种技术因素和其他因素，如管理员（不只是 DBA）的技能和能力。 虽然企业可能希望实现零停机时间或零数据丢失，但由于各种原因，这并不现实也不可能实现。 在确定解决方案的 RTO 和 RPO 时，所有参与方之间应该进行开诚布公的讨论。
对于 RTO 和 RPO，一个重要方面是了解停机的代价。 如果定义了相应的数字以及“停机”或“不可用”事件对企业造成的总体影响，那么定义解决方案就会更加容易。 例如，如果企业无法处理某些业务时每小时可能损失 1 万美元或可能被政府机构罚款，那么这是一种可帮助定义 RTO 和 RPO 的可衡量方法。 解决方案支出应与停机时长或成本成正比。 如果 HADR 解决方案的成本为 X 美元，但在问题发生时，你最终只受到几秒钟的影响，而不是几小时或几天，那么它已经收回了成本。
从非业务的角度来看，应在组件级别（例如 SQL Server）以及为整个应用体系结构定义 RTO。 从中断中恢复的能力取决于其最薄弱的环节。 例如，如果 SQL Server 及其数据库可以在 5 分钟内恢复，但应用程序服务器需要 20 分钟才能恢复，则总体 RTO 为 20 分钟，而不是 5 分钟。 SQL Server 环境的 RTO 仍可以是 5 分钟，它仍然不会改变总体恢复时间。
RPO 专门处理数据，直接影响所有 HADR 解决方案的设计以及管理策略和过程。 使用的功能必须同时支持所定义的 RTO 和 RPO。 例如，如果计划每隔 30 分钟进行一次事务日志备份，但 RPO 为 15 分钟，则数据库只能恢复到可用的最近一次事务日志备份，最差的情况是 30 分钟前。 这个时间假设不存在任何其他问题，备份已经过测试且已知其是完好的。 虽然很难测试为环境中的每个数据库生成的每个备份，但备份只是文件系统上的文件。 如果连最低限度的定期还原也不进行，就无法保证它们是否完好。 在备份过程中运行检查可以给你带来一定的信心。
所用的特定功能（如 Always On 可用性组 (AG) 或 Always On 故障转移群集实例 (FCI)）也会影响 RTO 和 RPO。 根据功能的配置方式，IaaS 或 PaaS 解决方案不一定会自动故障转移到另一个位置，这可能导致故障时间延长。 通过定义 RTO 和 RPO，可以在知道容许的时间和数据丢失量的情况下设计支持该要求的技术解决方案。 如果这些都不现实，则必须相应地调整 RTO 和 RPO。 例如，如果所需 RTO 为 2 小时，但将备份复制到目标服务器以完成还原需要 3 小时，则无法满足 RTO。 确定 RTO 和 RPO 时，必须考虑这些类型的因素。
对于 HA 和 DR，都应定义 RTO 和 RPO。 HA 是一种更加本地化的事件，可以更轻松地实现恢复。 高可用性的一个示例是，AG 会自动从 Azure 区域中的一个副本故障转移到另一个副本。 这可能需要几秒钟时间，并且届时你需要确保应用程序在故障转移后可以连接。 SQL Server 的故障时间很短。 根据解决方案或系统的重要性，本地 RTO 或 RPO 可能为几分钟。
DR 类似于建立一个全新的数据中心。 解决这个难题需要完成多个环节；SQL Server 只是其中一环。 恢复所有内容可能需要数小时或更长时间。 这就是 RTO 和 RPO 为何相互独立的原因。 即使许多用于 HA 和 DR 的技术和功能都相同，所需的工作和时间也可能不一样。
应定期或根据需要记录并修改所有 RTO 和 RPO。 记录后，就可以考虑对体系结构使用哪些技术和功能。