Appendix B - Backup on object stores
====================================
.. raw:: html
.. Warning::
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``
を使用できます。
.. Note::
Barmanクラウドで導入された機能強化を利用するために、システムで最新バージョンのオペランドを実行していることを常に確認して、クラスターのセキュリティ面を向上させます。
.. Warning::
Barman Cloud 3.16以降、ほとんどのBarman Cloudコマンドは、ターゲットバケットが既に存在するものと仮定して、ターゲットバケットを自動的に作成しません。現在、`barman-cloud-check-wal-archive` コマンドのみがバケットを作成します。これが空のバケットで実行される最初のオペレーションでない場合、CloudNativePGはエラーをスローします。その結果、信頼性の高い将来性の操作を保証し、潜在的な問題を回避するために、オブジェクトストアバケットを参照する`Cluster` リソースを作成する前に、オブジェクトストアバケットを作成および構成することを強くお勧めします。
バックアップは、\ ``Cluster``
のプライマリまたは指定されたプライマリインスタンスから実行されます
:ref:`レプリカクラスター <レプリカクラスター>` を参照してください
指定されたプライマリインスタンスの詳細については、 :ref:`スタンバイからのバックアップ <スタンバイからのバックアップ>` 。
共通オブジェクトストア
----------------------
:ref:`AWS S3 ` 、 :ref:`Microsoft Azure Blob Storage ` 、 :ref:`Google Cloud Storage `
、互換性のあるプロバイダーなどの特定のオブジェクトストア、または互換性のあるプロバイダーを探している場合は、
:ref:`Appendix C - Common object stores for backups ` を参照してください。
WALアーカイブ
-------------
WALアーカイブは、 :ref:`WALアーカイブ ` をフィードするプロセスです
CloudNativePGで。
WALアーカイブは、\ ``Cluster``
リソースの\ ``.spec.backup.barmanObjectStore``
スタンザで定義されています。
.. Note::
`BarmanObjectStoreConfiguration `_ を参照してください。
オプションの完全なリストについては、barman-cloud APIで 。
必要に応じて、WALファイルがアップロードされたらすぐに圧縮および/または暗号化することを選択できます。
.. code:: yaml
apiVersion: postgresql.cnpg.io/v1
kind: Cluster
[...]
spec:
backup:
barmanObjectStore:
[...]
wal:
compression: gzip
encryption: AES256
バケットに暗号化を直接構成できます。クラスター構成でオーバーライドしない限り、オペレーターはそれを使用します。
PostgreSQLは、シークエンシャル
アーカイブスキームを実装しており、アーカイブされるすべてのWALセグメントに対して\ ``archive_command``
がシークエンシャルに実行されます。
.. Note::
デフォルトでは、CloudNativePGは`archive_timeout` を`5min` に設定し、ワークロードが低い場合でもWALファイルが少なくとも5分ごとに閉じてアーカイブされ、目標リカバリポイント :ref:`PgBouncerPoolMode ` の決定論的な時間ベースの値を提供します。 `archive_timeout `_ の値を変更する場合でも、私たちの経験から、オペレーターによって設定されたデフォルト値がほとんどのユースケースに適していることが示唆されています。
PostgreSQLインスタンスとオブジェクトストア間の帯域幅で複数のWALファイルを並列してアーカイブできる場合、次の例のようにインスタンスマネージャーの並列WALアーカイブ機能を使用できます。
.. code:: yaml
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日の保持ポリシーを使用してバックアップを定義できます。
.. code:: yaml
apiVersion: postgresql.cnpg.io/v1
kind: Cluster
[...]
spec:
backup:
barmanObjectStore:
destinationPath: ""
s3Credentials:
accessKeyId:
name: aws-creds
key: ACCESS_KEY_ID
secretAccessKey:
name: aws-creds
key: ACCESS_SECRET_KEY
retentionPolicy: "30d"
.. Note::
**リカバリウィンドウリテンションポリシー**は、`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 `_ が含まれています。
.. csv-table::
:header: Compression,Backup Time (ms),Restore Time (ms),Uncompressed size (MB),Compressed size (MB),Approx ratio
widths: 10,10,10,8,8,8
:align: left
:class: longtable
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マニフェストの抜粋は、この機能の使用例を提供します。
.. code:: 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``
の宣言されたオプションに既に存在する場合、追加のオプションは無視されます。
次に、このプロパティの使用方法の例を示します。
バックアップの場合
.. code:: yaml
apiVersion: postgresql.cnpg.io/v1
kind: Cluster
[...]
spec:
backup:
barmanObjectStore:
[...]
data:
additionalCommandArgs:
- "--min-chunk-size=5MB"
- "--read-timeout=60"
WALファイルの場合
.. code:: yaml
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コンテナにリカバリオブジェクトストアを定義します。
.. code:: yaml
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クラスターが別の名前を使用している場合、
:ref:`アプリケーションデータベースの構成 <アプリケーションデータベースの構成>` に記載されているように、リカバリフェーズを終了する前にこれらの名前を指定する必要があります。
.. Note::
デフォルトでは、 `recovery` メソッドは、オブジェクトストア内のバックアップデータのメインフォルダーの名前として、 `externalClusters` セクションのクラスターの`name` を厳密に使用します。この名前は、通常、サーバーの名前用に予約されています。 `barmanObjectStore.serverName` プロパティを使用して、別のフォルダー名を指定できます。
.. Note::
この例では、並列WALリストア機能を利用し、最大8つのジョブを専用に作成して、アーカイブから必要なWALファイルを同時に取得します。この機能により、復旧時間を大幅に短縮できます。このシナリオを事前に計画し、ご使用の環境に合わせてこのパラメーターの値を正しく調整してください。必要なときに違いを生みますし、そうします。