バックアップとリカバリ

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 ツールに依存しています。その結果、ベースバックアップは tarball になります。ベースバックアップとWALファイルの両方を圧縮および暗号化できます。

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

重要

Barman cloudで導入された改善を活用するには、システムでオペランドの最新バージョンを実行していることを常に確認してください（およびクラスターのセキュリティ側面を改善します）。

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

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

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

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

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

• AWS S3

• Microsoft Azure Blob Storage

• Google Cloud Storage

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

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

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互換オブジェクトストレージプロバイダー

MinIO や LinodeObjectStorage などの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:
        [...]

DigitalOceanSpaces を使用している場合、 Pathスタイルの構文を使用する必要があります。この例では、リージョン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で署名された証明書を使用するObject Storageプロバイダーを構成するとします。その場合、 Barmanが証明書を正しく検証できるように、CAバンドルを含むシークレットを参照するオプション`endpointCA` を設定する必要があります。

注釈

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

MinIOゲートウェイ

必要に応じて、バックアップオブジェクトをS3やGCSなどの他のクラウドストレージソリューションに中継する共通インターフェイスとしてMinIO Gatewayを使用できます。詳細については、 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 Gatewayでのみ使用されます。

重要

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 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つの認証方法をサポートしています。

• 最初のものは、ポッドが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回よりも頻繁にバックアップをスケジュールすることは非常にまれです。

ScheduledBackupsは、必要に応じて.spec.suspend: true を設定することにより一時停止できます。これにより、オプションが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のアーカイブを要求する場合、そのアーカイブ要求は肯定的なステータスで却下されます。

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

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

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

デフォルトでは、バックアップはCluster の最もアライメントされたレプリカで実行されます。利用可能なレプリカがない場合、バックアップはプライマリインスタンスで実行されます。

注釈

スタンバイは常にプライマリと最新の状態ではない場合がありますが、最初に利用可能なバックアップから最後にアーカイブされたWALまでの連続した時間では、これは通常無関係です。ベースバックアップは実際、PITRを含むリカバリ操作を開始する開始点を表します。 ライブクラスターからのブートストラップ（`pg_basebackup ）<ライブクラスターからのブートストラップ（pg_basebackup ）>` で起こることと同様に 、スタンバイからバックアップするときは、プライマリでWALの切り替えを強制しません。これにより、書き込みアクティビティが少ないデプロイメントで短期間（ archive_timeout がキックインする前）に予期しない結果が生じる場合があります。

常にプライマリでバックアップを実行したい場合は、以下の例に概要を示すように、バックアップターゲットをprimary に設定できます。

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

バックアップターゲットが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は稼働していますが、接続を受け入れることはできず、ライブネスプローブによると、ポッドは正常です。 restore_command を介して、PostgreSQLはアーカイブからWALファイルのフェッチを開始します（ maxParallel オプションを設定し、並列WAL復元機能を有効にすることで、このフェーズをスピードアップできます）。

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

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

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

バックアップセクションを備えたクラスターへの復元

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

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

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

警告

オペレーターは、クラスターが情報を含むストレージバケットを上書きしないことを保証するための安全性チェックを含めます。既存のストレージを上書きするクラスターは、Podが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 および 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"