バックアップを使用してデータを保護する

ドキュメントのバージョンを選択してください。

このページでは、バックアップを使用したデータ保護を提供する AlloyDB Omni Standard Availability リファレンス アーキテクチャについて説明します。

ユースケース

このリファレンス アーキテクチャは、次のシナリオをサポートしています。

  • 対象のデータベースで、多少のダウンタイムと前回のバックアップ以降のデータ損失を許容できる。
  • AlloyDB Omni データベースを（サーバーまたは VM イメージのスナップショットではなく）データベース レベルのユーザーエラー、破損、物理障害から保護する。
  • データベースを（たとえば特定の時点まで遡って）インプレースまたはリモートで復元する。

リファレンス アーキテクチャの仕組み

Standard Availability リファレンス アーキテクチャは、AlloyDB Omni データベースのバックアップと復元を対象としています。

Standard Availability は基本的な実装であり、必要な追加のハードウェアやサービスを最小限に抑えますが、データベースが大きくなるにつれて目標復旧時間（RTO）が増加します。バックアップするデータが多いほど、データベースの復元に時間がかかります。データ損失はバックアップのタイプによって異なります。データファイルのみが定期的にバックアップされる場合、復元時に前回のバックアップ以降のデータが失われます。

RPO の低減

PostgreSQL の継続的アーカイブ機能を使用すると、目標復旧時点（RPO）を低減し、バックアップによるポイントインタイム リカバリを有効にできます。このプロセスでは、write-ahead log 書き込み（WAL）ファイルのアーカイブと WAL データのストリーミング（リモート ストレージ ロケーションへのストリーミングなど）が行われます。

WAL ファイルがフル バックアップ時または特定の間隔でのみアーカイブされる場合、データベース全体（現在の WAL ファイルを含む）が失われると、復元は最後にアーカイブされた WAL ファイルに制限されます。つまり、RPO では、データ損失の可能性を考慮する必要があります。一方、継続的な WAL データ転送では、データ損失の可能性を最小限に抑えることができます。

継続的バックアップを構成すると、ポイントインタイム リカバリを実行できます。ポイントインタイム リカバリでは、テーブルの偶発的な削除やバッチ アップデートの誤りなどのエラーが発生する前の状態にデータベースを復元できます。ただし、この復元方法では、一時的な補助データベースを使用しない限り、RPO と RTO の両方に影響します。データベース全体をインプレースで復元すると、影響を受けないテーブルの後続のトランザクションがロールバックされ、データベースがオフラインになります。一方、一時的な補助データベースに復元すると、復元されたデータのみをコピーできます。

バックアップ戦略

AlloyDB Omni は、定期的な物理バックアップ、ポイントインタイム リカバリ、WAL アーカイブとストリーミング、バックアップの異なるロケーションへの保存などのデータ保護戦略をサポートしています。または、小規模なデータベースの場合は、単一のデータベースの場合は pg_dump、クラスタ全体の場合は pg_dumpall を使用して論理バックアップを実行し、pg_restore を使用して復元できます。

バックアップ ツール

コンテナと Linux のデプロイメントの場合は、次の PostgreSQL ツールを使用してバックアップをスケジュールして管理できます。

デプロイ オプションに応じて、AlloyDB Omni を構成して、バックアップをローカル ストレージまたはリモート ストレージ（Cloud Storage や、任意のクラウド ベンダーが提供するストレージ オプションなど）に保存できます。ローカル ストレージの方がバックアップと復元は高速ですが、ホストまたは VM 全体の障害が発生した場合の障害対応は通常、リモート ストレージの方が堅牢です。詳細については、バックアップ先の候補を示す図 1 をご覧ください。

AlloyDB Omni とバックアップ オプション

図 1: AlloyDB Omni とバックアップ オプション

バックアップは、ローカル ストレージ オプションまたはリモート ストレージ オプションのいずれかに作成できます。ローカル バックアップは I/O スループットのみに依存するため、通常は高速です。一方、リモート バックアップは通常、レイテンシが高く、ネットワーク帯域幅が低くなります。ただし、リモート バックアップは、ローカル バックアップよりもホスト障害やゾーン障害に対する保護が優れています。

ローカル バックアップをローカル ストレージまたは共有ストレージに分割することもできます。ローカル ストレージには、データベース ホストで障害が発生した場合に障害復旧オプションがありませんが、共有ストレージでは、そのストレージを別のサーバーに再配置して復元に使用できます。つまり、共有ストレージでは RTO を短縮できる可能性があります。

ローカル ストレージ、共有ストレージ、リモート ストレージのデプロイでは、次のタイプのバックアップをスケジュールするか、オンデマンドで手動で作成できます。

  • フル バックアップ: データ復元に必要なすべてのデータベース ファイルの完全バックアップ。
  • 差分バックアップ: 前回のフル バックアップ以降のファイル変更のみのバックアップ。
  • 増分バックアップ: 前回のバックアップ（種類を問わない）以降のファイル変更のみのバックアップ。

ポイントインタイム リカバリ

PostgreSQL の WAL ファイルの継続的バックアップは、ポイントインタイム リカバリをサポートしています。障害イベントの後に WAL ファイルが破損しておらず使用可能な状態であれば、これらのファイルを使用して特定の時点に復元し、データ損失を最小限に抑えることができます。

リモート ロケーションに WAL データをストリーミングする

バックアップ ツール（Barman など）によっては、WAL データをリモート ロケーションにリアルタイムでストリーミングするように構成して、復元時のデータ損失を最小限に抑えることができます。リアルタイム ストリーミングでも、リモート ロケーションへのストリーミング書き込みはデフォルトで非同期であるため、commit されたトランザクションが失われる可能性は多少あります。ただし、WAL データを保存してステータス レスポンスをソース データベースに送信する同期モードを使用するように WAL ストリーミングを構成することもできます。このアプローチでは、トランザクションを継続する前にこの書き込みの完了を待つ必要がある場合、トランザクションが遅くなる可能性があることに注意してください。

バックアップ スケジュール

ほとんどの環境では、バックアップは通常、週単位でスケジュールされます。一般的な週次バックアップ スケジュールは次のとおりです。

  • 日曜日: フル バックアップ
  • 月曜日、火曜日: 増分バックアップ
  • 水曜日: 差分バックアップ
  • 木曜日、金曜日: 増分バックアップ
  • 土曜日: 差分バックアップ

この一般的なスケジュールを使用すると、1 週間のローリング復元ウィンドウでは、最大 3 回のフル バックアップに加えて、必要な増分バックアップまたは差分バックアップを保存するためのストレージ容量が必要になります。このアプローチは、日曜日のフル バックアップ中に障害が発生し、そのバックアップが開始される前週の日曜日の時点までデータベースの復元を延長する必要がある場合をサポートします。

RPO が大きくなる可能性があっても RTO を最小限に抑えるには、追加のデータベースを継続的リカバリモードで動作させます。このモードでは、バックアップの再生と、新しい WAL ファイルのアーカイブと再生によるセカンダリ環境の継続的な更新が行われます。潜在的なデータ損失を反映する実際の RPO は、トランザクションの頻度、WAL ファイルのサイズ、WAL ストリーミングの使用によって異なります。

バックアップの復元

保存されたバックアップから AlloyDB Omni データベースを復元したり、保持期間内の特定の時点に復元したりできます。デプロイ環境と復元のニーズに応じて、データを元の場所に復元することも、バックアップを新しいデータベース インスタンスまたはクラスタに復元することもできます。

コンテナと Linux のデプロイの場合、AlloyDB Omni データベースを復元するには、通常、データベース サービスまたはコンテナを停止して既存のデータ ディレクトリにデータを復元するか、新しい場所にデータを復元して、その復元されたデータを使用して新しいデータベース インスタンスを起動します。詳細については、pgBackRest を使用して AlloyDB Omni クラスタを復元するまたは Barman を使用して AlloyDB Omni クラスタを復元するをご覧ください。

実装

この可用性リファレンス アーキテクチャを選択する際は、以下の利点、制限事項、代替案を考慮してください。

利点

  • 使用と管理が簡単で、RTO と RPO が緩やかなクリティカルではないデータベースに適しています。
  • 追加のハードウェアは最小限で済みます。
  • 災害復旧計画に必要な基本的なバックアップを提供します。
  • 復元期間内の任意の時点への復元をサポートします。

制限事項

  • 保持要件によっては、データベース自体よりも多くのストレージ容量が必要になる場合があります。
  • 復元に時間がかかり、RTO が長くなる可能性があります。
  • データベース障害後の現在の WAL データの可用性によっては、一部のデータが失われる可能性があり、RPO に悪影響を及ぼす可能性があります。

別の方法

可用性と障害復旧のオプションを改善するには、Enhanced Availability または Premium Availability のリファレンス アーキテクチャを検討してください。

次のステップ