バックアップとリカバリー¶

オペレーターは、: BarmanCredentials ツールに基づいた継続的バックアップインフラストラクチャを調整できます。オペレーターは、多くのPostgreSQLインスタンスをバックアップするBarmanサーバーで古典的なアーキテクチャを使用する代わりに、

barman-cloud-wal-archive 、barman-cloud-check-wal-archive 、barman-cloud-backup 、barman-cloud-backup-list 、およびbarman-cloud-backup-delete ツールに依存しています。その結果、ベースバックアップはtarballになります。ベースバックアップとWALファイルの両方を圧縮して暗号化できます。

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

重要

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

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

レプリカクラスターを参照してください）。

クラウドプロバイダーのサポート¶

Barman Cloudインフラストラクチャでサポートされているサービスでバックアップファイルをアーカイブできます。つまり：

サポートされているサービスの互換性のある実装を使用することもできます。

必要な設定は、選択したストレージプロバイダーによって異なり、次のセクションで説明します。

S3¶

環境に関する次の情報が必要です。

ACCESS_KEY_ID ：S3にファイルをアップロードするために使用されるアクセスキーのID
ACCESS_SECRET_KEY ：上記のアクセスキーのシークレット部分
ACCESS_SESSION_TOKEN ：必要な場合のオプションのセッショントークン

使用するアクセスキーには、バケットにファイルをアップロードする権限が必要です。そのため、資格情報でKubernetesシークレットを作成する必要があります。次のコマンドで作成できます。

kubectl create secret generic aws-creds \
  --from-literal=ACCESS_KEY_ID=<access key here> \
  --from-literal=ACCESS_SECRET_KEY=<secret key here>
#  --from-literal=ACCESS_SESSION_TOKEN=<session token here> # if required

資格情報はKubernetes内に保存され、インストールで保存時の暗号化が構成されている場合は暗号化されます。

そのシークレットを作成したら、次の例のようにクラスターを構成できます。

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

宛先パスは、インスタンスがWALファイルをアップロードできるフォルダーを指す任意のURLです。 s3://BUCKET_NAME/path/to/folder 。

その他のS3互換オブジェクトストレージプロバイダー¶

MinIOやLinode Object StorageなどのS3互換オブジェクトストレージを使用している場合、デフォルトのS3を使用する代わりにエンドポイントを指定できます。

この例では、リージョンus-east1 のLinodeのbucket バケットを使用します。

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
[...]
spec:
  backup:
    barmanObjectStore:
      destinationPath: "<destination path here>"
      endpointURL: bucket.us-east1.linodeobjects.com
      s3Credentials:
        [...]

重要

HTTPS経由でMinIOを使用する場合など、プライベートCAで署名された証明書を使用するObject Storageプロバイダーを構成するとします。その場合、 Barmanが証明書を正しく検証できるように、CAバンドルを含むシークレットを参照するオプション endpointCA を設定する必要があります。

注釈

ConfigMapとSecretをインスタンスによって**自動的に**リロードしたい場合、キー`cnpg.io/reload` を持つラベルをSecrets/ConfigMapに追加できます。それ以外の場合は、 kubectl cnpg reload サブコマンドを使用してインスタンスをリロードする必要があります。

MinIOゲートウェイ¶

オプションで、S3やGCSなどの他のクラウドストレージソリューションにバックアップオブジェクトを中継する共通インターフェイスとしてMinIOゲートウェイを使用できます。詳細については、: MinIO official documentation を参照してください。

具体的には、CloudNativePGクラスターは、以前に作成した資格情報とサービスを使用して、エンドポイントとしてローカルMinIOゲートウェイを直接ポイントできます。

MinIO シークレットは、PostgreSQL クラスターと MinIO インスタンスの両方で使用されます。したがって、同じ名前空間に作成する必要があります。

kubectl create secret generic minio-creds \
  --from-literal=MINIO_ACCESS_KEY=<minio access key here> \
  --from-literal=MINIO_SECRET_KEY=<minio secret key here>

注釈

Cloud Object Storageの資格情報は、この場合MinIOゲートウェイでのみ使用されます。

重要

PostgreSQLがMinIOゲートウェイに到達できるようにするには、MinIOゲートウェイインスタンスにバインドされたポート`9000` で`ClusterIP` サービスを作成する必要があります。

例：

apiVersion: v1
kind: Service
metadata:
  name: minio-gateway-service
spec:
  type: ClusterIP
  ports:
    - port: 9000
      targetPort: 9000
      protocol: TCP
  selector:
    app: minio

警告

このドキュメントを書いている時点では、Kubernetesの公式の MinIO Operator はゲートウェイ機能をサポートしていません。そのため、代わりに deployment を使用します。

MinIO展開では、クラウドストレージの資格情報を使用してオブジェクトをリモートバケットにアップロードし、バックアップファイルを別の場所にリレーします。

以下は、AWS S3をクラウドオブジェクトストレージとして使用した例です。

apiVersion: apps/v1
kind: Deployment
[...]
spec:
  containers:
  - name: minio
    image: minio/minio:RELEASE.2020-06-03T22-13-49Z
    args:
    - gateway
    - s3
    env:
    # MinIO access key and secret key
    - name: MINIO_ACCESS_KEY
      valueFrom:
        secretKeyRef:
          name: minio-creds
          key: MINIO_ACCESS_KEY
    - name: MINIO_SECRET_KEY
      valueFrom:
        secretKeyRef:
          name: minio-creds
          key: MINIO_SECRET_KEY
    # AWS credentials
    - name: AWS_ACCESS_KEY_ID
      valueFrom:
        secretKeyRef:
          name: aws-creds
          key: ACCESS_KEY_ID
    - name: AWS_SECRET_ACCESS_KEY
      valueFrom:
        secretKeyRef:
          name: aws-creds
          key: ACCESS_SECRET_KEY
#  Uncomment the below section if session token is required
#    - name: AWS_SESSION_TOKEN
#      valueFrom:
#        secretKeyRef:
#          name: aws-creds
#          key: ACCESS_SESSION_TOKEN
        ports:
        - containerPort: 9000

Cluster 定義でendpointURL としてMinIO Gatewayサービスを構成し、BUCKET_NAME を置き換えるバケット名を選択します。

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
[...]
spec:
  backup:
    barmanObjectStore:
      destinationPath: s3://BUCKET_NAME/
      endpointURL: http://minio-gateway-service:9000
      s3Credentials:
        accessKeyId:
          name: minio-creds
          key: MINIO_ACCESS_KEY
        secretAccessKey:
          name: minio-creds
          key: MINIO_SECRET_KEY
    [...]

バックアップを進める前に、 s3://BUCKET_NAME/ でアーカイブされたWALファイルの存在を確認します。

Azure Blobストレージ¶

ストレージアカウントにアクセスするには、次のいずれかの資格情報の組み合わせが必要です。

**Connection String**
ストレージアカウント名 と **Storage account access key**
ストレージアカウント名 と **Storage account SAS Token**
ストレージアカウント名 と **Azure AD Workload Identity** が適切に構成されています。

AzureADWorkloadIdentity を使用すると、資格情報をKubernetes Secretに保存せずに、次のようにクラスター構成にinheritFromAzureAD を追加できます。

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
[...]
spec:
  backup:
    barmanObjectStore:
      destinationPath: "<destination path here>"
      azureCredentials:
        inheritFromAzureAD: true

一方、 ストレージアカウントアクセスキー または ストレージアカウントSASトークン の両方を使用して、資格情報をKubernetes Secret内に保存し、必要な場合にのみデータエントリを追加する必要があります。次のコマンドはそれを実行します。

kubectl create secret generic azure-creds \
  --from-literal=AZURE_STORAGE_ACCOUNT=<storage account name> \
  --from-literal=AZURE_STORAGE_KEY=<storage account key> \
  --from-literal=AZURE_STORAGE_SAS_TOKEN=<SAS token> \
  --from-literal=AZURE_STORAGE_CONNECTION_STRING=<connection string>

使用されるKubernetesクラスターでこの機能が有効になっている場合、資格情報は保存時に暗号化されます。

前のシークレットがあれば、提供された資格情報をクラスター構成内に注入できます。

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
[...]
spec:
  backup:
    barmanObjectStore:
      destinationPath: "<destination path here>"
      azureCredentials:
        connectionString:
          name: azure-creds
          key: AZURE_CONNECTION_STRING
        storageAccount:
          name: azure-creds
          key: AZURE_STORAGE_ACCOUNT
        storageKey:
          name: azure-creds
          key: AZURE_STORAGE_KEY
        storageSasToken:
          name: azure-creds
          key: AZURE_STORAGE_SAS_TOKEN

Azure Blob Storageを使用する場合、 destinationPath は次の構造を満たします。

<http|https>://<account-name>.<service-name>.core.windows.net/<resource-path>

ここで、 <resource-path> は<container>/<blob> です。アカウント名は、ストレージアカウント名とも呼ばれ、使用するホスト名に含まれます。

その他の Azure Blob Storage 互換プロバイダー¶

Azure Blob Storage APIの別の実装を使用している場合、 destinationPath は次の構造になります。

<http|https>://<local-machine-address>:<port>/<account-name>/<resource-path>

その場合、 <account-name> はパスの最初のコンポーネントです。

これは、Azure Storage Emulatorまたは Azurite を介してAzureサポートをテストする場合に必要です。

Google Cloud Storage¶

現在、オペレーターはGoogle Cloud Storageの2つの認証方法をサポートしています。1つはポッドがGoogle Kubernetes Engineクラスタ内で実行されていることを前提とし、もう1つは環境変数GOOGLE_APPLICATION_CREDENTIALS を利用します。

Google Kubernetes Engine内で実行¶

これは、バックアップを作成する最も簡単な方法の1つであり、次の構成のみが必要です。

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
[...]
spec:
  backup:
    barmanObjectStore:
      destinationPath: "gs://<destination path here>"
      googleCredentials:
        gkeEnvironment: true

これにより、クラスターがGoogle Kubernetes Engine内で実行されていることをオペレーターに伝えます。つまり、ファイルのアップロードに資格情報は必要ありません

重要

この方法では、クラスターとポッドに注意深く定義された権限が必要です。これらはクラスター管理者が定義する必要があります。

認証の使用¶

instruction from Google に従うと、認証に必要なすべての情報を含むJSONファイルを取得します。

JSONファイルの内容は、次のコマンドで作成できるSecret を使用して提供する必要があります。

kubectl create secret generic backup-creds --from-file=gcsCredentials=gcs_credentials_file.json

これにより、 backup-creds という名前でSecret が作成され、次のようにyamlファイルで使用されます。

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
[...]
spec:
  backup:
    barmanObjectStore:
      destinationPath: "gs://<destination path here>"
      googleCredentials:
        applicationCredentials:
          name: backup-creds
          key: gcsCredentials

これで、オペレーターは資格情報を使用して Google Cloud Storage に対して認証を行います。

重要

この認証方法では、Google Cloud Storageバケットへのアクセスに必要なすべての情報を含むJSONファイルがコンテナ内に作成されます。つまり、誰かがポッドにアクセスすると、バケットへの書き込み権限も付与されます。

オンデマンドバックアップ¶

新しいバックアップを要求するには、次のような新しいバックアップリソースを作成する必要があります。

apiVersion: postgresql.cnpg.io/v1
kind: Backup
metadata:
  name: backup-example
spec:
  cluster:
    name: pg-backup

オペレーターは、barman-cloud-backup を使用して必要なバックアップを取得するようにクラスターのオーケストレーションを開始します。プレーンなkubectl describe backup <name> コマンドを使用して、バックアップのステータスを確認できます。

Name:         backup-example
Namespace:    default
Labels:       <none>
Annotations:  API Version:  postgresql.cnpg.io/v1
Kind:         Backup
Metadata:
  Creation Timestamp:  2020-10-26T13:57:40Z
  Self Link:         /apis/postgresql.cnpg.io/v1/namespaces/default/backups/backup-example
  UID:               ad5f855c-2ffd-454a-a157-900d5f1f6584
Spec:
  Cluster:
    Name:  pg-backup
Status:
  Phase:       running
  Started At:  2020-10-26T13:57:40Z
Events:        <none>

バックアップが完了すると、次の例のようにフェーズはcompleted になります。

Name:         backup-example
Namespace:    default
Labels:       <none>
Annotations:  API Version:  postgresql.cnpg.io/v1
Kind:         Backup
Metadata:
  Creation Timestamp:  2020-10-26T13:57:40Z
  Self Link:         /apis/postgresql.cnpg.io/v1/namespaces/default/backups/backup-example
  UID:               ad5f855c-2ffd-454a-a157-900d5f1f6584
Spec:
  Cluster:
    Name:  pg-backup
Status:
  Backup Id:         20201026T135740
  Destination Path:  s3://backups/
  Endpoint URL:      http://minio:9000
  Phase:             completed
  s3Credentials:
    Access Key Id:
      Key:   ACCESS_KEY_ID
      Name:  minio
    Secret Access Key:
      Key:      ACCESS_SECRET_KEY
      Name:     minio
  Server Name:  pg-backup
  Started At:   2020-10-26T13:57:40Z
  Stopped At:   2020-10-26T13:57:44Z
Events:         <none>

!!!重要この機能では、スーパーユーザーとアプリケーションユーザーのシークレットはバックアップされません。シークレットは、Kubernetesクラスターの標準バックアップ手順の一部としてバックアップされることになっています。

スケジュールされたバックアップ¶

ScheduledBackup という名前のリソースを作成して、バックアップを定期的にスケジュールすることもできます。後者はBackup に似ていますが、schedule と呼ばれるフィールドが追加されています。

このフィールドはcronスケジュール仕様であり、同じ format used in Kubernetes CronJobs に従います。

これは、スケジュールされたバックアップの例です。

apiVersion: postgresql.cnpg.io/v1
kind: ScheduledBackup
metadata:
  name: backup-example
spec:
  schedule: "0 0 0 * * *"
  backupOwnerReference: self
  cluster:
    name: pg-backup

上記の例では、毎日午前0時にバックアップをスケジュールします。

ヒント

バックアップの頻度は、完全またはポイントインタイムのリカバリ操作を必要とする災害後のリカバリ時間オブジェクト（RTO）に影響を与える場合があります。私たちのアドバイスは、バックアップを復元して定期的にテストし、最初から復元するのにかかる時間を測定して、RTOの予測可能性を向上させることです。リカバリ時間は、ベースバックアップのサイズと、アーカイブから取得してリカバリ中に再生する必要があるWALファイルの量に影響されます（WALアーカイブはPostgreSQLでの連続バックアップを可能にすることを忘れないでください！）。私たちの経験に基づいて、ほとんどの場合、毎週のベースバックアップで十分ですが、バックアップを1日に1回以上スケジュールすることは非常にまれです。

ScheduledBackupsは、必要に応じて.spec.suspend: true を設定することで一時停止できます。これにより、オプションがfalseに設定されている限り、スケジュールされた新しいバックアップが停止します。

ScheduledBackupリソースが作成されたらすぐにバックアップを発行する場合は、 .spec.immediate: true を設定します。

注釈

.spec.backupOwnerReference は、作成されたバックアップリソース内に配置する必要があるownerReferenceを示します。

none:作成されたバックアップオブジェクトの所有者参照はありません（フィールドが導入される前と同じ動作）- self:バックアップの所有者としてスケジュールされたバックアップオブジェクトを設定します

WALアーカイブ¶

宛先パスを選択し、クラウド資格情報を構成するとすぐにWALアーカイブが有効になります。

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

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

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

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

重要

デフォルトでは、CloudNativePGは`archive_timeout` を`5min` に設定し、ワークロードが低い場合でも、少なくとも5分ごとにWALファイルが閉じられてアーカイブされ、目標復旧時点（RPO）の確定的な時間ベースの値を提供します。 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のアーカイブを要求する場合、そのアーカイブ要求は肯定的なステータスで却下されます。

リカバリー¶

クラスターの復元は、既存のクラスターでは「インプレース」で実行されません。オブジェクトストレージにアップロードされたデータを使用して、以前に作成したバックアップから新しいクラスターをブートストラップできます。オペレーターは、 barman-cloud-restore ツール（ベースバックアップ用）およびbarman-cloud-wal-restore ツール（要求に応じて並列サポートを含むWALファイル用）を使用して、回復プロセスを調整します。

recovery ブートストラップメソッドの詳細と手順については、: バックアップからのブートストラップ（`recovery ）<バックアップからのブートストラップ（recovery ）>` を参照してください。

内部では、オペレーターは新しいクラスターの最初のインスタンスに init コンテナーを挿入し、init コンテナーはオブジェクトストレージからのバックアップの回復を開始します。

重要

新しいPVCでのベースバックアップコピーの期間は、バックアップのサイズと、ネットワークとストレージの両方の速度によって異なります。

ベースバックアップリカバリープロセスが完了すると、オペレーターはPostgresインスタンスをリカバリーモードで起動します。このフェーズでは、PostgreSQLは稼働していますが、接続を受け入れることはできず、ライブネスプローブによるとポッドは正常です。 restore_command を介して、PostgreSQLはアーカイブからWALファイルのフェッチを開始します（ maxParallel オプションを設定し、並列WAL復元機能を有効にすることで、このフェーズを高速化できます）。

このフェーズは、PostgreSQLがターゲット（WALの終わりまたはポイントインタイムリカバリの場合は必要なターゲット）に到達すると終了します。実際、オプションで recoveryTarget を指定して、ポイントインタイムリカバリを実行できます。指定しない場合、リカバリはデフォルトのターゲットタイムラインで利用可能な最新のWALまで続行されます（11までのPostgreSQLの場合はlatest 、バージョン12以降の場合）。

リカバリが完了すると、オペレーターは必要なスーパーユーザーのパスワードをインスタンスに設定します。新しいプライマリインスタンスが通常どおりに起動され、残りのインスタンスがレプリカとしてクラスターに参加します。

このプロセスはユーザーに対して透過的であり、ポッドで実行されているインスタンスマネージャーによって管理されます。

バックアップセクションを使用したクラスターへの復元¶

クラスター復元のマニフェストには、 backup セクションが含まれる場合があります。これは、新しいクラスターが回復後にWALのアーカイブとバックアップの作成を開始することを意味します。

警告

リカバリーのために、externalClusters セクションと同じ`barmanObjectStore` オブジェクトを使用することは許可されていません。場合によっては、これは機能*できますが、ソースクラスターと同じバックアップオブジェクトを使用している場合、オペレーターは新しいクラスターへのリカバリを防ぎます。これは、ソースWALが上書きされる可能性のあるエッジケースから保護するためです。リカバリとバックアップに再利用された同じ`barmanObjectStore` を持つクラスターは、検証エラーを生成します：spec.backup.barmanObjectStore: Invalid value: …

たとえば、以下のセクションは、クラスターcluster-example-backup からのクラスターブートストラップのマニフェストの一部である可能性があり、回復されたクラスターのベースバックアップとWALが保存されるrecoveredCluster という名前のストレージバケットに新しいフォルダーを作成します。

backup:
  barmanObjectStore:
    destinationPath: s3://backups/
    endpointURL: http://minio:9000
    serverName: "recoveredCluster"
    s3Credentials:
      accessKeyId:
        name: minio
        key: ACCESS_KEY_ID
      secretAccessKey:
        name: minio
        key: ACCESS_SECRET_KEY
  retentionPolicy: "30d"

externalClusters:
- name: cluster-example-backup
  barmanObjectStore:
    destinationPath: s3://backups/
    endpointURL: http://minio:9000
    s3Credentials:

異なるクラスターにまったく同じbarmanObjectStore 構成を再利用しないでください。ストレージバケット内の既存の情報が新しいクラスタによって上書きされる場合があります。

警告

クラスターが情報を含むストレージバケットを上書きしないことを保証する安全性チェックがオペレーターに含まれるようになりました。既存のストレージを上書きするクラスターは、ポッドが Error 状態である Setting up primary 状態のままになります。ポッドログには次のように表示されます。ERROR: WAL archive check failed for server recoveredCluster: Expected empty archive"

保持ポリシー¶

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"

圧縮アルゴリズム¶

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

bzip2
gzip

*サクサク

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

アーカイブ時間、復元時間、およびサイズはアルゴリズム間で異なることに注意することが重要です。圧縮アルゴリズムは、ユースケースに応じて選択する必要があります。

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

Compression	Backup Time (ms)	Restore Time (ms)	Uncompressed size (MB)	Compressed size (MB)	Approx ratio
None	10927	7553	395	395	1:1
bzip2	25404	13886	395	67	5.9:1
gzip	116281	3077	395	91	4.3:1
snappy	8134	8341	395	166	2.4:1

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

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"