* PostgreSQLデータベースのバックアップ、復元、および回復。* PostgreSQLデータベースは、pg_dumpを使用した論理バックアップ、pg_basbackupまたは下位レベルのOSバックアップコマンドを使用した物理オンラインバックアップ、ストレージレベルの整合性のあるスナップショットなど、多くのバックアップ方法をサポートしています。この解決策 は、PostgreSQLデータベースデータおよびスタンバイサイトでのWALボリュームのバックアップ、リストア、およびリカバリに、ネットアップの整合グループスナップショットを使用します。ネットアップの整合性グループボリュームのSnapshotは、ストレージに書き込まれる時点でのI/Oシーケンスを検証し、データベースデータファイルの整合性を保護します。

* EC2コンピューティングインスタンス。*このテストと検証では、PostgreSQLデータベースコンピューティングインスタンスにAWS EC2 t2.xlargeインスタンスタイプを使用しました。データベースワークロード向けに最適化されているため、導入環境ではPostgreSQLのコンピューティングインスタンスとしてM5タイプEC2インスタンスを使用することを推奨します。スタンバイコンピューティングインスタンスは、FSX HAクラスタ用に展開されたパッシブ（スタンバイ）ファイルシステムと同じゾーンに常に配置する必要があります。

* FSXストレージHAクラスタのシングルゾーンまたはマルチゾーン展開。*このテストと検証では、FSX HAクラスタを単一のAWSアベイラビリティゾーンに導入しました。本番環境では、FSX HAペアを2つの異なるアベイラビリティゾーンに導入することを推奨します。ビジネス継続性のためのディザスタリカバリスタンバイHAペアは、プライマリとスタンバイの間に特定の距離が必要な場合、別のリージョンに設定できます。FSX HAクラスタは、アクティブ/パッシブファイルシステムのペアで同期ミラーされるHAペアで、ストレージレベルの冗長性を提供するために割り当てられます。

* PostgreSQLデータとログの配置。*一般的なPostgreSQL環境では、データファイルとログファイルに同じルートディレクトリまたはボリュームを共有しています。テストと検証では、PostgreSQLのデータを分離し、パフォーマンスのために2つのボリュームにログを作成しました。データディレクトリ内のソフトリンクは、PostgreSQL WALログとアーカイブされたWALログをホストするログディレクトリまたはボリュームを指すために使用されます。

* PostgreSQLサービスの起動遅延タイマー。*この解決策 は、NFSマウントボリュームを使用してPostgreSQLデータベースファイルとWALログファイルを保存します。データベース・ホストの再起動中に、ボリュームがマウントされていない状態でPostgreSQLサービスが起動を試みることがあります。その結果、データベースサービスの起動に失敗します。PostgreSQLデータベースを正しく起動するには、10～15秒のタイマー遅延が必要です。

ビジネス継続性のためのRPO / RTO。 DRのプライマリからスタンバイへのFSXデータレプリケーションは非同期に基づいているため、RPOはSnapshotバックアップとSnapMirrorレプリケーションの頻度に依存します。SnapshotコピーとSnapMirrorレプリケーションの頻度を高くすると、RPOが短縮されます。そのため、災害時のデータ損失と、ストレージコストの増加というバランスを取ることができます。これまでのところ、RPOではSnapshotコピーとSnapMirrorレプリケーションをわずか5分間隔で実装できると判断しており、一般にRTOでは、DRスタンバイサイトでPostgreSQLを1分以内にリカバリできます。

データベースのバックアップ。 PostgreSQLデータベースを実装した後、またはオンプレミスのデータセンターからAWS FSXストレージに移行した後、データは保護のためにFSX HAペアで自動的に同期されます。災害発生時に、複製されたスタンバイサイトによってデータがさらに保護されます。長期のバックアップ保持やデータ保護を実現するために、組み込みのPostgreSQL pg_basbackupユーティリティを使用して、S3 BLOBストレージに移植可能なフルデータベースバックアップを実行することを推奨します。