Appendix B - Backup on object stores

警告

CloudNativePG 1.26の時点で、** Barman Cloudプラグイン**を優先して、ネイティブBarman Cloudサポートは非推奨です。このページは、参考のために付録に移動しました。現時点ではネイティブ統合は機能し続けていますが、適切なテストの後、プラグインベースのインターフェイスへの段階的な移行を開始することを強くお勧めします。ガイダンスについては、 Migrating from Built-in CloudNativePG Backup を参照してください。

CloudNativePGは、オブジェクトストアでの継続的な物理バックアップとWALアーカイブを介して、PostgreSQLクラスターの オンライン/ホットバックアップ をネイティブにサポートしています。これは、データベースが常に稼働しており、ダウンタイムが必要なく、ポイントインタイムリカバリーが利用できることを意味します。

オペレーターは、 Barman Cloud ツールに基づいた継続的なバックアップインフラストラクチャをオーケストレーションできます。多くのPostgreSQLインスタンスをバックアップするBarmanサーバーで古典的なアーキテクチャを使用する代わりに、オペレーターはbarman-cloud-wal-archive 、barman-cloud-check-wal-archive 、barman-cloud-backup 、barman-cloud-backup-list 、およびbarman-cloud-backup-delete ツールに依存します。その結果、ベースバックアップは tarballs になります。ベースバックアップとWALファイルは両方とも圧縮および暗号化できます。

このためには、 barman-cli-cloud が含まれるイメージを使用する必要があります。コミュニティPostgreSQLイメージと最新のbarman-cli-cloud パッケージで構成されているため、このスコープにイメージghcr.io/cloudnative-pg/postgresql を使用できます。

注釈

Barmanクラウドで導入された機能強化を利用するために、システムで最新バージョンのオペランドを実行していることを常に確認して、クラスターのセキュリティ面を向上させます。

警告

Barman Cloud 3.16以降、ほとんどのBarman Cloudコマンドは、ターゲットバケットが既に存在するものと仮定して、ターゲットバケットを自動的に作成しません。現在、barman-cloud-check-wal-archive コマンドのみがバケットを作成します。これが空のバケットで実行される最初のオペレーションでない場合、CloudNativePGはエラーをスローします。その結果、信頼性の高い将来性の操作を保証し、潜在的な問題を回避するために、オブジェクトストアバケットを参照する`Cluster` リソースを作成する前に、オブジェクトストアバケットを作成および構成することを強くお勧めします。

バックアップは、Cluster のプライマリまたは指定されたプライマリインスタンスから実行されますレプリカクラスターを参照してください

指定されたプライマリインスタンスの詳細については、スタンバイからのバックアップ。

共通オブジェクトストア

AWS S3 、 Microsoft Azure Blob Storage 、 Google Cloud Storage 、互換性のあるプロバイダーなどの特定のオブジェクトストア、または互換性のあるプロバイダーを探している場合は、 Appendix C - Common object stores for backups を参照してください。

WALアーカイブ

WALアーカイブは、 WALアーカイブをフィードするプロセスです

CloudNativePGで。

WALアーカイブは、Cluster リソースの.spec.backup.barmanObjectStore スタンザで定義されています。

注釈

BarmanObjectStoreConfiguration を参照してください。

オプションの完全なリストについては、barman-cloud APIで。

必要に応じて、WALファイルがアップロードされたらすぐに圧縮および/または暗号化することを選択できます。

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
[...]
spec:
  backup:
    barmanObjectStore:
      [...]
      wal:
        compression: gzip
        encryption: AES256

バケットに暗号化を直接構成できます。クラスター構成でオーバーライドしない限り、オペレーターはそれを使用します。

PostgreSQLは、シークエンシャルアーカイブスキームを実装しており、アーカイブされるすべてのWALセグメントに対してarchive_command がシークエンシャルに実行されます。

注釈

デフォルトでは、CloudNativePGは`archive_timeout` を`5min` に設定し、ワークロードが低い場合でもWALファイルが少なくとも5分ごとに閉じてアーカイブされ、目標リカバリポイント PgBouncerPoolMode の決定論的な時間ベースの値を提供します。 archive_timeout の値を変更する場合でも、私たちの経験から、オペレーターによって設定されたデフォルト値がほとんどのユースケースに適していることが示唆されています。

PostgreSQLインスタンスとオブジェクトストア間の帯域幅で複数のWALファイルを並列してアーカイブできる場合、次の例のようにインスタンスマネージャーの並列WALアーカイブ機能を使用できます。

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
[...]
spec:
  backup:
    barmanObjectStore:
      [...]
      wal:
        compression: gzip
        maxParallel: 8
        encryption: AES256

前の例では、インスタンスマネージャーは、PostgreSQLによって要求されたものを含む最大8つの準備ができているWALを並列アーカイブすることにより、WALアーカイブプロセスを最適化します。

PostgreSQLが、最適化としてインスタンスマネージャーによって既にアーカイブされたWALのアーカイブを要求する場合、そのアーカイブ要求はポジティブなステータスで却下されるだけです。

リテンションポリシー

CloudNativePGは、リカバリウィンドウに基づいて リテンションポリシー を使用して、バックアップオブジェクトストアからのバックアップファイルの自動削除を管理できます。

内部的には、保持ポリシー機能はbarman-cloud-backup-delete と--retention-policy “RECOVERY WINDOW OF {{ retention policy value }} {{ retention policy unit }}” を使用します。

たとえば、次のように30日の保持ポリシーを使用してバックアップを定義できます。

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
[...]
spec:
  backup:
    barmanObjectStore:
      destinationPath: "<destination path here>"
      s3Credentials:
        accessKeyId:
          name: aws-creds
          key: ACCESS_KEY_ID
        secretAccessKey:
          name: aws-creds
          key: ACCESS_SECRET_KEY
    retentionPolicy: "30d"

注釈

**リカバリウィンドウリテンションポリシー**は、current time - recovery window によって決定される移動ポイントである*回復可能ポイント* PoR の概念に焦点を当てています。 *最初の有効なバックアップ*は、PoR の前に最初に使用可能なバックアップです新しい順に。 CloudNativePGは、最初の有効なバックアップから始めて、PoR と最新の正常にアーカイブされたWALファイル間の任意の時点でクラスターを復旧できることを保証する必要があります。最初の有効なバックアップよりも古いベースバックアップは*古い*としてマークされ、次のバックアップが完了した後に完全に削除されます。

圧縮アルゴリズム

CloudNativePGは、デフォルトでバックアップとWALファイルを非圧縮方法でアーカイブします。ただし、 barman-cloud-backup バックアップ用およびbarman-cloud-wal-archive WALファイル用を介して次の圧縮アルゴリズムもサポートします。

bzip2
gzip
lz4
きびきび
xx
zstd

バックアップとWALの圧縮設定は独立しています。 barman-cloud APIリファレンスの DataBackupConfiguration および WALBackupConfiguration セクションを参照してください。

アーカイブ時間、復元時間、およびサイズはアルゴリズムによって異なるため、ユースケースに応じて圧縮アルゴリズムを選択する必要があることに注意してください。

Barmanチームは、 Barman Cloudでサポートされているアルゴリズムのパフォーマンスの評価を実行しました。次の表は、ローカルのMinIO展開でバックアップが作成されるシナリオをまとめています。 Barman GitHubプロジェクトには、 deeper analysis が含まれています。

バックアップオブジェクトのタグ付け

Barman 2.18では、 barman-cloud-backup およびbarman-cloud-wal-archive を介してオブジェクトストアに保存する際のバックアップリソースのタグ付けのサポートを導入しました。その結果、PostgreSQLコンテナイメージにバージョン2.18以降のBarmanが含まれる場合、CloudNativePGでは、バックアップオブジェクト、つまりベースバックアップ、WALファイル、履歴ファイルのキーと値のペアとしてタグを指定できます。

.spec.backup.barmanObjectStore 定義では2つのプロパティを使用できます。

tags バックアップオブジェクトとバックアップオブジェクトストアのアーカイブされたWALファイルに追加するキーと値のペアタグ
historyTags バックアップオブジェクトストアのアーカイブされた履歴ファイルに追加されるキーと値のペアタグ

以下のYAMLマニフェストの抜粋は、この機能の使用例を提供します。

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
[...]
spec:
  backup:
    barmanObjectStore:
      [...]
      tags:
        backupRetentionPolicy: "expire"
      historyTags:
        backupRetentionPolicy: "keep"

backupおよびWALコマンドの追加オプション

.spec.backup.barmanObjectStore.data および.spec.backup.barmanObjectStore.wal セクションのadditionalCommandArgs プロパティを使用して、 barman-cloud-backup およびbarman-cloud-wal-archive コマンドに追加オプションを追加できます。これらのプロパティは、 barman-cloud-backup およびbarman-cloud-wal-archive コマンドに追加される文字列のリストです。

たとえば、 --read-timeout=60 を使用して、接続の読み取りタイムアウトをカスタマイズできます。

barman-cloud-backup およびbarman-cloud-wal-archive コマンドでサポートされる追加オプションについては、公式バーマンドキュメント here を参照してください。

additionalCommandArgs で提供されるオプションが、そのセクション.spec.backup.barmanObjectStore.data または.spec.backup.barmanObjectStore.wal の宣言されたオプションに既に存在する場合、追加のオプションは無視されます。

次に、このプロパティの使用方法の例を示します。

バックアップの場合

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
[...]
spec:
  backup:
    barmanObjectStore:
      [...]
      data:
        additionalCommandArgs:
        - "--min-chunk-size=5MB"
        - "--read-timeout=60"

WALファイルの場合

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
[...]
spec:
  backup:
    barmanObjectStore:
      [...]
      wal:
        additionalCommandArgs:
        - "--max-concurrency=1"
        - "--read-timeout=60"

オブジェクトストアからのリカバリー

Barman Cloudによって作成され、サポートされているオブジェクトストアに保存されているバックアップから復元できます。 barmanObjectStore セクションで必要な構成をすべて含む外部クラスターを定義した後、 .spec.recovery.source オプションで参照する必要があります。

この例では、AzureのBLOBコンテナにリカバリオブジェクトストアを定義します。

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: cluster-restore
spec:
  [...]

  superuserSecret:
    name: superuser-secret

  bootstrap:
    recovery:
      source: clusterBackup

  externalClusters:
    - name: clusterBackup
      barmanObjectStore:
        destinationPath: https://STORAGEACCOUNTNAME.blob.core.windows.net/CONTAINERNAME/
        azureCredentials:
          storageAccount:
            name: recovery-object-store-secret
            key: storage_account_name
          storageKey:
            name: recovery-object-store-secret
            key: storage_account_key
        wal:
          maxParallel: 8

前の例では、アプリケーションデータベースとその所有ユーザーの名前がデフォルトでapp であることを前提としています。リストアするPostgreSQLクラスターが別の名前を使用している場合、アプリケーションデータベースの構成に記載されているように、リカバリフェーズを終了する前にこれらの名前を指定する必要があります。

注釈

デフォルトでは、 recovery メソッドは、オブジェクトストア内のバックアップデータのメインフォルダーの名前として、 externalClusters セクションのクラスターの`name` を厳密に使用します。この名前は、通常、サーバーの名前用に予約されています。 barmanObjectStore.serverName プロパティを使用して、別のフォルダー名を指定できます。

注釈

この例では、並列WALリストア機能を利用し、最大8つのジョブを専用に作成して、アーカイブから必要なWALファイルを同時に取得します。この機能により、復旧時間を大幅に短縮できます。このシナリオを事前に計画し、ご使用の環境に合わせてこのパラメーターの値を正しく調整してください。必要なときに違いを生みますし、そうします。