ビジネスアプリケーションの主要な指標として、次の 2 つがあります。

これらの要件は、使用するアプリケーションの種類とビジネスデータの性質によって定義されます。1 つの 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 をゼロにする必要がある場合は、プライマリストレージとバックアップストレージが失われた場合でも、データを同期的にレプリケートする必要があります。ただし、同期レプリケーションについては、 2 つの Azure リージョン間の距離などの技術的な制限があります。ほとんどの場合、同期レプリケーションは 100km を超えるレイテンシから受ける距離には適していないため、 Azure リージョン間でのデータレプリケーションには対応できません。

RPO を大きくすることが許容される場合は、長距離間で非同期レプリケーションを使用できます。この場合の RPO は、レプリケーションの頻度によって定義されます。

SAP HANA データベースの起動時間は、従来のデータベースよりもはるかに長くなります。これは、データベースが期待されるパフォーマンスを提供するためには、大量のデータをメモリにロードする必要があるためです。そのため、 RTO の大部分はデータベースの起動に必要な時間です。ストレージベースのレプリケーションに加えて、 HANA システムレプリケーションを事前ロードなしで実行する場合、ディザスタリカバリサイトにフェイルオーバーするためには、 SAP HANA データベースを起動する必要があります。

SAP HANA システムレプリケーションでは、データがプリロードされ、セカンダリホストで継続的に更新される動作モードが提供されます。このモードでは、 RTO の値が非常に低くなりますが、ソースシステムからのレプリケーションデータの受信にのみ使用される専用のサーバが必要になります。