业务应用程序有两个关键指标：

这些要求是根据所使用的应用程序类型和业务数据的性质来定义的。如果您要在一个 Azure 区域防止出现故障，则 RPO 和 RTO 可能会有所不同。如果您正在准备应对灾难，例如丢失完整的 Azure 区域，则它们可能也会有所不同。评估用于定义 RPO 和 RTO 的业务要求非常重要，因为这些要求会对可用的技术选项产生重大影响。

SAP HANA 基础架构（例如虚拟机，网络和存储）必须具有冗余组件，以确保不会出现单点故障。MS Azure 可为不同的基础架构组件提供冗余。

为了在计算和应用程序端提供高可用性，可以使用 SAP HANA 多主机系统配置备用 SAP HANA 主机以实现内置的高可用性。如果服务器或 SAP HANA 服务发生故障， SAP HANA 服务将故障转移到备用主机，从而导致应用程序停机。

如果在服务器或应用程序发生故障时无法接受应用程序停机，您也可以使用 SAP HANA 系统复制作为高可用性解决方案，以便在极短的时间内实现故障转移。SAP 客户使用 HANA 系统复制不仅可以解决计划外故障的高可用性问题，还可以最大限度地减少计划内操作（例如 HANA 软件升级）的停机时间。

逻辑损坏可能是由软件错误，人为错误或破坏引起的。遗憾的是，使用标准高可用性和灾难恢复解决方案往往无法解决逻辑损坏问题。因此，根据发生逻辑损坏的层，应用程序，文件系统或存储，有时无法满足 RTO 和 RPO 要求。

最糟糕的情况是 SAP 应用程序中的逻辑损坏。SAP 应用程序通常在不同应用程序相互通信并交换数据的环境中运行。因此，不建议使用还原和恢复发生逻辑损坏的 SAP 系统。将系统还原到损坏发生前的某个时间点会导致数据丢失，因此 RPO 会大于零。此外， SAP 环境将不再同步，需要额外的后处理。

更好的方法是尝试通过在单独的修复系统中分析问题来修复系统中的逻辑错误，而不是还原 SAP 系统。根发生原因分析需要业务流程和应用程序所有者的参与。在这种情况下，您可以根据发生逻辑损坏之前存储的数据创建修复系统（生产系统的克隆）。在修复系统中，可以将所需数据导出并导入到生产系统中。通过这种方法，无需停止生产系统，在最佳情况下，不会丢失任何数据，也不会丢失一小部分数据。

创建备份，以便从不同的时间点数据集进行还原和恢复。通常，这些备份会保留几天到几周。

根据损坏的类型，无论是否丢失数据，都可以执行还原和恢复。如果 RPO 必须为零，即使主存储和备份存储丢失，备份也必须与同步数据复制结合使用。

用于还原和恢复的 RTO 由所需还原时间，恢复时间（包括数据库启动）以及将数据加载到内存中来定义。对于大型数据库和传统备份方法， RTO 可能很容易需要几个小时，这可能是不可接受的。要使 RTO 值非常低，必须将备份与热备用解决方案结合使用，其中包括将数据预加载到内存中。

相反，备份解决方案必须解决逻辑损坏问题，因为数据复制解决方案无法涵盖所有类型的逻辑损坏。

RPO 主要确定您应使用的数据复制方法。如果 RPO 必须为零，即使主存储和备份存储丢失，也必须同步复制数据。但是，同步复制存在技术限制，例如两个 Azure 区域之间的距离。在大多数情况下，由于延迟，同步复制不适用于 100 公里以上的距离，因此，这不是 Azure 区域之间数据复制的选项。

如果可以接受更大的 RPO ，则可以在远距离使用异步复制。在这种情况下， RPO 由复制频率定义。

SAP HANA 数据库的启动时间比传统数据库的启动时间长得多，因为在数据库提供预期性能之前，必须将大量数据加载到内存中。因此， RTO 的很大一部分是启动数据库所需的时间。对于任何基于存储的复制以及不预加载数据的 HANA 系统复制，在故障转移到灾难恢复站点时，必须启动 SAP HANA 数据库。

SAP HANA 系统复制提供了一种操作模式，在该模式下，数据会在二级主机上进行预加载并持续更新。此模式启用的 RTO 值非常低，但它还需要一个专用服务器，该服务器仅用于从源系统接收复制数据。