バックアップとリカバリ

CloudNativePG は、継続的な物理バックアップと WAL アーカイブを通じて、PostgreSQL クラスターの オンライン/ホットバックアップ をネイティブにサポートします。これは、データベースが常に稼働しており (ダウンタイムが不要)、システムで最初に使用可能なベース バックアップからいつでも復旧できることを意味します。後者は通常、「ポイント イン タイム リカバリ」（PITR）と呼ばれます。

オペレーターは、 BarmanCredentials ツールに基づく継続的なバックアップ インフラストラクチャを調整できます。多くの 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クラウドで導入された改善を活用してください (また、クラスターのセキュリティ面を改善します)。

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

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

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

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

• AWS S3

• Microsoft Azure Blob Storage

• Google クラウド ストレージ

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

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

S3

次の 2 つの方法で、S3 バケットにバックアップを保存するためのアクセス許可を定義できます。

• CloudNativePG が EKS で実行されている場合。 IRSA authentication method を使用することもできます

• または、ACCESS_KEY_ID および ACCESS_SECRET_KEY 資格情報を使用することもできます

AWS アクセス キー

環境に関する次の情報が必要になります。

• 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 .

サービス アカウントの IAM ロール (IRSA)

IRSA を使用するには、Postgres クラスターの ServiceAccount に annotation を設定する必要があります。

serviceAccountTemplate スタンザを使用してそれらを注入するように CloudNativePG を構成できます。

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
[...]
spec:
  serviceAccountTemplate:
    metadata:
      annotations:
        eks.amazonaws.com/role-arn: arn:[...]
        [...]

その他の S3 互換 Object Storage プロバイダー

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

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

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

デジタルオーシャンスペース を使用している場合は、パス スタイルの構文を使用する必要があります。この例では、領域 SFO3 で DigitalOceanSpaces の bucket を使用します。

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
[...]
spec:
  backup:
    barmanObjectStore:
      destinationPath: "s3://[your-bucket-name]/[your-backup-folder]/"
      endpointURL: "https://sfo3.digitaloceanspaces.com"
      s3Credentials:
        [...]

重要

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

注釈

インスタンスによって ConfigMap とシークレットを 自動的に リロードする場合は、キー cnpg.io/reload のラベルを Secrets/ConfigMaps に追加できます。それ以外の場合は、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>

この場合、.. Note::

クラウド オブジェクト ストレージ資格情報は、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

警告

このドキュメントの執筆時点では、公式の MinIO Operator

for Kubernetes はゲートウェイ機能をサポートしていません。そのため、代わりに deployment を使用します。

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

AWS S3 を Cloud Object Storage として使用する例を次に示します。

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 ゲートウェイ サービスを構成して続行し、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 ブロブ ストレージ

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

• **Connection String**

• ストレージアカウント名 と **Storage account access key**

• ストレージアカウント名 と **Storage account SAS Token**

• ストレージアカウント名 と **Azure AD Workload Identity**

適切に構成されています。

AzureADワークロードID を使用すると、資格情報を Kubernetes シークレットに保存することを回避し、次のように inheritFromAzureAD を追加するクラスター構成を持つことができます。

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

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

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 ストレージ エミュレーターまたは Azurite を介して Azure サポートをテストする場合に必要です。

Google クラウド ストレージ

現在、オペレーターは Google Cloud Storage の 2 つの認証方法をサポートしています。

• 最初のものは、ポッドが Google Kubernetes Engine クラスタ内で実行されていることを前提としています

• 2 つ目は、環境変数 GOOGLE_APPLICATION_CREDENTIALS を利用します。

Google Kubernetes Engine 内での実行

Google Kubernetes Engine 内で実行している場合、資格情報を設定する必要なく、単純に Workload Identity に依存するようにバックアップを構成できます。特に、次のことを行う必要があります。

• .spec.backup.barmanObjectStore.googleCredentials.gkeEnvironment を true に設定

• serviceAccountTemplate スタンザに iam.gke.io/gcp-service-account 注釈を設定します

次の例を参考にしてください。

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

  serviceAccountTemplate:
    metadata:
      annotations:
        iam.gke.io/gcp-service-account:  [...].iam.gserviceaccount.com
        [...]

認証の使用

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 回以上の頻度でバックアップをスケジュールすることは非常にまれです。

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

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

注釈

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

• none: 作成されたバックアップ オブジェクトの所有者参照なし (フィールドが導入される前と同じ動作) - self: バックアップの所有者としてスケジュールされたバックアップ オブジェクトを設定します - cluster: バックアップの所有者としてクラスターを設定します

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 に設定し、ワークロードが低い場合でも、WAL ファイルが少なくとも 5 分ごとに閉じられてアーカイブされるようにし、目標復旧時点 (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 のアーカイブを要求する場合、そのアーカイブ要求は肯定的なステータスで却下されます。

スタンバイからのバックアップ

デフォルトでは、バックアップは Cluster のプライマリ インスタンスで実行されます。

ベース バックアップを作成するには、ディスク上の PostgreSQL インスタンスのデータ コンテンツ全体をスクレイピングする必要があるため、データベースの実際のワークロードとの I/O 競合が発生する可能性があります。

このため、CloudNativePG では、PostgreSQL で直接利用できる機能、 スタンバイからのバックアップ を利用できます。

以下の例に示すように、バックアップ ターゲットを prefer-standby に設定できます。

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  [...]
spec:
  backup:
    target: "prefer-standby"

prefer-standby ポリシーは、バックアップが最新の使用可能なセカンダリ インスタンスで実行されることを保証し、他のインスタンスが使用できない場合はプライマリ インスタンスにフォールバックします。

デフォルトでは、指定されていない場合、ターゲットはプライマリからバックアップを取るように自動的に設定されます。

Cluster で指定されたバックアップ ターゲットは、次の例のように、Backup および ScheduledBackup タイプでオーバーライドできます。

apiVersion: postgresql.cnpg.io/v1
kind: Backup
metadata:
  [...]
spec:
  cluster:
    name: [...]
  target: "primary"

前の例では、Cluster がレプリカを優先するように設定されていても、CloudNativePG は常にプライマリ インスタンスを選択します。

回復

クラスターの復元は、既存のクラスターでは “インプレース” で実行されません。オブジェクト ストレージにアップロードされたデータを使用して、以前に取得したバックアップから新しいクラスターを ブートストラップ できます。オペレーターは、barman-cloud-restore ツール (ベース バックアップ用) と barman-cloud-wal-restore ツール (WAL ファイル用、必要に応じて並列サポートを含む) を使用して、復旧プロセスを調整します。

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

重要

PostgreSQL PITR の方法に慣れていない場合

.spec.postgresql.parameters に関しては、回復クラスターを元のクラスターとして構成することをお勧めします。新しいクラスターが復元されたら、必要に応じて設定を変更できます。

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

重要

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

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

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

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

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

バックアップ セクションを使用してクラスターに復元する

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

たとえば、以下のセクションは、クラスター 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 構成を再利用しないでください。ストレージ バケット内の既存の情報が新しいクラスターによって上書きされる場合があります。

警告

オペレーターには、クラスターが情報を含むストレージ バケットを上書きしないようにするための安全チェックが含まれています。既存のストレージを上書きするクラスターは、状態 Setting up primary のままになり、Pod はエラー状態になります。ポッドのログには次のように表示されます: 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 リファレンスの

データバックアップ構成 および WalBackupConfiguration セクションを参照してください。

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

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"