Backup and Recovery

演算子は、 BarmanObjectStoreConfiguration ツールに基づいた継続的なバックアップインフラストラクチャを調整できます。多くのPostgreSQLインスタンスをバックアップするBarmanサーバーで従来のアーキテクチャを使用する代わりに、演算子はthe 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イメージとlatest barman-cli-cloud パッケージで構成されるため、イメージ ghcr.io/cloudnative-pg/postgresql を使用できます。

重要

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

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

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

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

• AWS S3

• Microsoft Azure Blob Storage

• Google Cloud Storage

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

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

S3

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

• ACCESS_KEY_ID ：使用されるアクセスキーのID S3でファイルをアップロードするには

• ACCESS_SECRET_KEY ：前のアクセスキーの秘密のパート

• ACCESS_SESSION_TOKEN ：必要な場合のオプショナルのセッショントークン

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

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（eg s3://BUCKET_NAME/path/to/folder など）にすることができます。

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

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

この例では、region 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 を設定する必要があります。

注釈

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

MinIOゲートウェイ

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

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

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 Gatewayに到達できるようにするには、MinIO Gatewayインスタンスにバインドされたポート 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 definitionで 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 Storage

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

• **Connection String**

• ストレージアカウント名前 および **Storage account access key**

• ストレージアカウント名前 および **Storage account SAS Token**

資格情報は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>

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

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

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 StorageEmulatorまたは 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 KubernetesEngine内で実行されていること、つまりファイルをアップロードするために資格情報が必要ないことを演算子に伝えます。

重要

このメソッドでは、クラスター管理者が定義する必要があるクラスターとポッドのアクセス許可を慎重に定義する必要があります。

認証を使用する

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 likeになります。

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 名前付けのリソースを作成して、バックアップを定期的にスケジュールすることもできます。後者はa 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セグメントに対してthe archive_command がシーケンシャルに実行されます。

重要

デフォルトでは、CloudNativePGは archive_timeout を 5min に設定します。これにより、ワークロードが低い場合でも、少なくとも5分ごとにWALファイルが閉じられ、アーカイブされます。 archive_timeout の値を変更しても、経験により、演算子によって設定されたデフォルト値はほとんどのユースケースに適していることが示唆されています。

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

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

前の例では、インスタンスマネージャは、 PostgreSQLが要求するものを含め、最大8つのreadyWALを並行してアーカイビングすることにより、WALarchivingプロセスを最適化します。

PostgreSQLが、最適化としてインスタンスマネージャによって既にアーカイブされているWALのアーカイビングを要求する場合、そのアーカイブ要求は肯定的なステータスで破棄されます。

回復

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

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

フードの下で、演算子は新しいクラスターの最初のインスタンスにinitコンテナーを注入し、initコンテナーはオブジェクトストレージからバックアップのリカバリをスタートします。

重要

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

ベースバックアップリカバリプロセスが完了すると、演算子はPostgresインスタンスをリカバリモードで開始します。このフェーズでは、接続を受け入れることができず、ポッドは健全であるにもかかわらず、 PostgreSQLはプローブしています。 restore_command を介して、 PostgreSQLはアーカイブからWALファイルの取得を開始します（ maxParallel オプションを設定し、並列WAL復元機能を有効にすることで、このフェーズを高速化できます）。

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

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

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

保持ポリシー

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"