次の図に、この章で使用するラボのセットアップを示します。HANA システムレプリケーションを使用して、 HANA ホストを 2 台、 HANA を 3 台、 HANA を 4 台構成しました。

HANA システムデータベース用のデータベースユーザ「 SnapCenter 」が作成され、バックアップおよびリカバリ処理を実行するために必要な権限が付与されています（を参照） "SnapCenter を使用した SAP HANA のバックアップとリカバリ"）。HANA のユーザストアキーは、上記のデータベースユーザを使用して両方のホストで設定する必要があります。

SnapCenter で HANA システムのレプリケーションを設定するには、大まかに見て次の手順を実行する必要があります。

両方の HANA ホストに SnapCenter HANA プラグインをインストールすると、他の自動検出されたリソースと同じように、 HANA システムが SnapCenter リソースビューに表示されます。SnapCenter 4.6 以降では、追加の列に HANA システムレプリケーション（有効 / 無効、プライマリ / セカンダリ）のステータスが表示されます。

リソースをクリックすると、 SnapCenter は HANA システムの HANA ユーザストアキーを要求します。

追加の自動検出ステップが実行され、 SnapCenter にリソースの詳細が表示されます。SnapCenter 4.6 では、システムレプリケーションのステータスとセカンダリサーバがこのビューに表示されます。

2 つ目の HANA リソースに対して同じ手順を実行すると、自動検出プロセスが完了し、両方の HANA リソースが SnapCenter で構成されます。

HANA システムレプリケーションを有効にしたシステムでは、両方の HANA リソースを含む SnapCenter リソースグループを設定する必要があります。

Snapshot 名には、ホスト名、ポリシー、スケジュールなどを含めるカスタムの名前形式を使用することを推奨します。

リソースグループに両方の HANA ホストを追加する必要があります。

リソースグループにはポリシーとスケジュールが設定されます。

これでリソースグループの設定が終了し、バックアップを実行できるようになります。

リソースグループのバックアップ処理が実行されると、 SnapCenter はどのホストがプライマリであるかを識別し、プライマリホストでのみバックアップをトリガーします。つまり、プライマリホストのデータボリュームのみが Snapshot されます。この例では、 HANA 3 が現在のプライマリホストであり、このホストでバックアップが実行されています。

SnapCenter ジョブログには、識別処理と、現在のプライマリホスト HANA でのバックアップの実行が表示されます。

これで、プライマリ HANA リソースに Snapshot バックアップが作成されました。バックアップ名に含まれるホスト名は HANA - 3 と表示されます。

HANA のバックアップカタログにも同じ Snapshot バックアップが表示されます。

テイクオーバー処理が実行されると、それ以降の SnapCenter バックアップで元のセカンダリホスト（ Hana-4 ）がプライマリとして識別され、 Hana-4 でバックアップ処理が実行されるようになります。ここでも、新しいプライマリホスト（ HANA - 4 ）のデータボリュームのみが Snapshot されています。

SnapCenter ジョブログには、識別処理と、現在のプライマリホスト HANA でのバックアップの実行が表示されます。

これで、プライマリ HANA リソースに Snapshot バックアップが作成されました。バックアップ名に含まれているホスト名は、 HANA のホスト名です。

HANA のバックアップカタログにも同じ Snapshot バックアップが表示されます。

SnapCenter 4.6 では、ファイルベースのバックアップでブロック整合性チェック処理を実行する場合と同じロジックを使用します。SnapCenter は現在のプライマリ HANA ホストを識別し、このホストに対してファイルベースのバックアップを実行します。保持管理も両方のホスト間で実行されるため、現在プライマリになっているホストに関係なく、最も古いバックアップが削除されます。

テイクオーバー時に透過的なバックアップ処理を可能にし、現在プライマリホストになっている HANA ホストに依存しないようにするには、両方のホストのデータボリュームに SnapVault 関係を設定する必要があります。SnapCenter は、バックアップの実行ごとに、現在のプライマリホストに対して SnapVault 更新処理を実行します。

SnapVault ターゲットの保持管理は ONTAP by SnapCenter の外部で管理されるため、両方の HANA ホスト間で処理することはできません。そのため、テイクオーバー前に作成されたバックアップは、以前のセカンダリではバックアップ処理によって削除されません。これらのバックアップは、元のプライマリが再びプライマリになるまで保持されます。これらのバックアップによってログバックアップの保持管理がブロックされないように、 SnapVault ターゲットまたは HANA のバックアップカタログから手動で削除する必要があります。

SnapCenter 4.6 は、両方の HANA ホストで Snapshot バックアップ、ブロック整合性チェック処理、 HANA バックアップカタログのエントリ、ログバックアップ（無効になっていない場合）の保持を管理できるため、どちらのホストが現在プライマリであるかセカンダリであるかは関係ありません。削除処理が現在のプライマリホストとセカンダリホストのどちらで必要かに関係なく、定義された保持設定に基づいて HANA カタログのバックアップ（データとログ）とエントリが削除されます。つまり、テイクオーバー処理を実行した場合や、レプリケーションが反対方向に設定されている場合は、手動での操作は必要ありません。

SnapVault レプリケーションがデータ保護戦略の一部である場合は、特定のシナリオで手動による操作が必要です。詳細については、を参照してください [SnapVault Replication]。

次の図は、複数のテイクオーバーが実行され、両方のサイトに Snapshot バックアップが作成された場合のシナリオを示しています。現在のステータスでは、ホスト HA-3 がプライマリホスト、最新のバックアップは T4 であり、これはホスト HA-3 で作成されています。リストアおよびリカバリ処理を実行する必要がある場合、バックアップ T1 および T4 は SnapCenter のリストアとリカバリに使用できます。ホスト HA-4 （ T2 、 T3 ）で作成されたバックアップは、 SnapCenter を使用してリストアできません。リカバリのために、これらのバックアップを HANA のデータボリュームに手動でコピーする必要があります。

SnapCenter 4.6 リソースグループ構成のリストアおよびリカバリ操作は ' 自動検出されたシステム以外のレプリケーション設定と同じですリストアと自動リカバリのすべてのオプションを使用できます。詳細については、テクニカルレポートを参照してください "TR-4614 ：『 SAP HANA Backup and Recovery with SnapCenter 』"。

もう一方のホストで作成されたバックアップからのリストア処理については、を参照してください "他のホストで作成されたバックアップからのリストアとリカバリ"。