Backup

注釈

このセクションでは、PostgreSQLの**物理バックアップ**について説明します。 PostgreSQLは、 pg_dump ユーティリティを使用した論理バックアップもサポートしていますが、これらは**ビジネス継続性に適しておらず**、CloudNativePGによって**管理されません**。 pg_dump を使用する場合は、 *Troubleshooting / Emergency backup* section を参照してください。

ガイダンス用に。

注釈

バージョン1.26から、ネイティブバックアップおよびリカバリー機能は、コアオペレーターの**段階的にフェーズアウト**され、公式CNPG-Iプラグインに移動されます。この移行は、WALアーカイブ、物理ベースバックアップ**の管理を標準化する拡張可能なインターフェイス**CNPG-I**によって有効になる**バックアップに依存しないアーキテクチャ**へのCloudNativePGのシフトと一致しています。、および対応する**リカバリプロセス*。

CloudNativePGは現在、2つの主な方法で PostgreSQLクラスターの物理バックアップ をサポートしています。

`CNPG-I <https://github.com/cloudnative-pg/cnpg-i/>`_ プラグイン経由 CloudNativePGコミュニティは **Barman Cloud Plugin** を公式にサポート

オブジェクトストレージサービスとの統合用。

ネイティブ 、以下をサポート

( Barman Cloudプラグインを優先して1.26から非推奨ですが) - Kubernetes Volume Snapshots 、基になるストレージクラスでサポートされている場合

CloudNativePGでバックアップ戦略を選択する前に、メインコンセプトでカバーされている基本的な概念を理解することが重要です

セクション。これらには、WALアーカイブ、ホットおよびコールドバックアップ、スタンバイからのバックアップの実行などが含まれます。

メインコンセプト

PostgreSQLは、ファイルシステムレベルの物理コピーに基づいて、ファーストクラスのバックアップおよびリカバリー機能をネイティブに提供します。これらはミッションクリティカルな運用データベースで15年以上使用され、世界中の組織がPostgresでディザスターリカバリー目標を達成するのを支援してきました。

CloudNativePGでは、各PostgreSQLクラスターのバックアップインフラストラクチャは次のリソースで構成されます。

WALアーカイブ Postgresによって継続的に書き込まれ、データ耐久性のためにアーカイブされるWALファイルトランザクションログを含む場所
物理ベースバックアップ PostgreSQLがデータベースにデータを保存するために使用するすべてのファイルのコピー主にPGDATA およびテーブルスペース

CNPG-Iは、WALアーカイブアーカイブとリストア操作の両方、およびベースバックアップおよび対応する復元プロセスを管理するための汎用かつ拡張可能なインターフェイスを提供します。

WALアーカイブ

PostgreSQLのWALアーカイブは、 継続的バックアップ の中心であり、次の理由で基本的なものです。

ホットバックアップ サーバーをシャットダウンせずに、Postgresクラスタープライマリまたはスタンバイのインスタンスから物理ベースのバックアップを取得する可能性。オンラインバックアップとしても知られています
ポイントインタイムリカバリー PITR システムで最初に使用可能なベースバックアップから任意の時点で復旧する可能性。

警告

WALアーカイブだけでは役に立ちません。物理ベースのバックアップがないと、PostgreSQLクラスターを復元できません。

一般に、WALアーカイブの存在により、PostgreSQLクラスターの復元力が強化され、各インスタンスは、必要に応じてアーカイブから必要なWALファイルを取得できます。通常、WALアーカイブの保持期間は、通常これらのファイルをリサイクルするPostgresインスタンスよりも長くなります。。

このユースケースは、WALアーカイブに依存するだけで長距離にわたって同期でき、さまざまなリージョンにわたってディザスターリカバリー目標を拡張できるため、レプリカクラスターに拡張することもできます。

configure a WAL archive を実行すると、CloudNativePGは、リージョンを超えても、ディザスターリカバリーに PgBouncerPoolMode ≤ 5分をすぐに提供します。

注釈

常に本番でWALアーカイブをセットアップすることをお勧めします。通常ステージング環境と開発環境が関係する既知のユースケースがあり、上記の利点はいずれも必要とされず、WALアーカイブは必要ありません。この場合のRPOは、24時間毎日のバックアップまたは無限バックアップなしなどの任意の値です。

コールドおよびホットバックアップ

ホットバックアップは前のセクションで既に定義されています。これらはWALアーカイブの存在を必要とし、最新のデータベース管理システムでは標準です。

コールドバックアップ は、オフラインバックアップとしても知られ、代わりに、PostgreSQLインスタンススタンバイまたはプライマリがシャットダウンしたときに取得される物理ベースバックアップです。これらは定義ごとに一貫しており、シャットダウンされた時点のデータベースのスナップショットを表します。

その結果、PostgreSQLインスタンスは、WALアーカイブを必要とせずにコールドバックアップから再起動できますが、利用可能な場合はそれを利用できます前のセクションで強調表示した復旧面のすべての利点を備えています。

RPOが高く1時間または24時間など、保持期間が短い状況では、コールドバックアップは、ディザスターリカバリー計画で検討される実行可能なオプションを表します。

使用可能なバックアップオプションの比較:オブジェクトストアとボリュームスナップショット

CloudNativePGは現在、物理バックアップの2つの主要なアプローチをサポートしています。

オブジェクトストアベースのバックアップ 、 **Barman Cloud Plugin** または **deprecated native integration** 経由
**Volume Snapshots** 、Kubernetes CSIインターフェイスとサポートされているストレージクラスを使用

注釈

CNPG-Iは、サードパーティが独自のバックアッププラグインをビルドおよび統合できるように設計されています。時間の経過とともに、サポートされているバックアップソリューションのエコシステムが成長すると予想されます。

オブジェクトストアベースのバックアップ

オブジェクトストアへのバックアップAWS S3、Azure Blob、GCSなど

常にWALアーカイブが必要
ホットバックアップのみをサポート
インクリメンタルまたは差分コピーをサポートしていません
リテンションポリシーのサポート

ボリュームスナップショット

ネイティブボリュームのスナップショット

WALアーカイブは必要ありませんが、運用環境での使用を強くお勧めします
基になるストレージクラスの機能に応じて、インクリメンタルおよび差分コピーをサポート
ホットおよびコールドバックアップの両方をサポート
リテンションポリシーをサポートしていません

2つの間の選択

最適なアプローチは、環境と操作要件によって異なります。次の要素を考慮します。

オブジェクトストアの可用性 Kubernetesクラスターが、安定したネットワーキングレイヤーを含む信頼できるオブジェクトストレージソリューションにアクセスできることを確認します。
ストレージクラス機能 ストレージクラスが、インクリメンタル/差分機能を備えたCSIボリュームスナップショットをサポートしていることを確認します。
データベースサイズ 非常に大規模なデータベースVLDBの場合、コピーオンライトテクノロジーによる高速なリカバリーが可能になるため、 ボリュームスナップショットが一般的に優先されます 。これにより、 Recovery Time Objective (RTO) が大幅に向上します。
データモビリティ オブジェクトストアベースのバックアップは、リージョンまたは環境を超えてバックアップをレプリケートまたは保存するためのより高い柔軟性を提供する場合があります。
操作の慣れ ストレージの管理におけるチームの経験と自信に最も適した方法を選択します。

比較の概要

Feature	Object Store	Volume Snapshots
WAL archiving	Required	Recommended^1^
Cold backup	NO	OK
Hot backup	OK	OK
Incremental copy	NO	OK^2^
Differential copy	NO	OK^2^
Backup from a standby	OK	OK
Snapshot recovery	NO^3^	OK
Retention policies	OK	NO
Point-in-Time Recovery (PITR)	OK	Requires WAL archive
Underlying technology	Barman Cloud	Kubernetes API

注意事項 > > 1.現在、WALアーカイブでは、プラグインまたは非推奨のネイティブ > を介してオブジェクトストアを使用する必要があります。 > 2. インクリメンタルおよび差分コピーの可用性は、PostgreSQLボリュームに使用されるストレージクラスの機能によって異なります。 > 3. スナップショットリカバリーは、 bootstrap.recovery.recoveryTarget.targetImmediate オプションを使用してエミュレートできます。

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

スケジュールされたバックアップは、CloudNativePGで信頼できるバックアップ戦略を実装するための推奨される方法です。これらはScheduledBackup カスタムリソースを使用して定義されます。

注釈

構成オプションの完全なリストについては、 ScheduledBackupSpec を参照してください。

APIリファレンスで。

Cronスケジュール

schedule フィールドは、秒を含む 6フィールドのcron式を使用して、バックアップを発生する** タイミングを定義します。このフォーマットは Go `cron package specification <https://pkg.go.dev/github.com/robfig/cron#hdr-CRON_Expression_Format>`_ に従います。

警告

このフォーマットは、従来のUnix/Linux crontab とは異なります。最初のエントリとして**seconds**フィールドが含まれます。

毎日のスケジュールされたバックアップの例

apiVersion: postgresql.cnpg.io/v1
kind: ScheduledBackup
metadata:
  name: backup-example
spec:
  schedule: "0 0 0  **  *"  # At midnight every day
  backupOwnerReference: self
  cluster:
    name: pg-backup
  # method: plugin, volumeSnapshot, or barmanObjectStore (default)

スケジュール"0 0 0 ** *" は、毎日深夜00:00:00にバックアップをトリガーします。 Kubernetes CronJobでは、秒がサポートされていないため、同等の式は0 0* ** になります。

バックアップ頻度とRTO

Tip

バックアップの頻度は、 目標復旧時間 バックアップ頻度とRTO に直接影響します。

継続的なバックアップに基づいてディザスターリカバリー戦略を最適化するには

バックアップからの復元を定期的にテストします。
完全なリカバリーに必要な時間を測定します。
ベースバックアップのサイズと、取得および再生する必要があるWALファイルの数を考慮します。

ほとんどの場合、 毎週のベースバックアップ で十分です。 1日1回よりも多くの頻度で完全なバックアップをスケジュールすることはほとんどありません。

即時バックアップ

ScheduledBackup の作成時にすぐにバックアップをトリガーするには

spec:
  immediate: true

スケジュールされたバックアップを一時停止する

スケジュールされたバックアップの実行を一時的に停止するには

spec:
  suspend: true

バックアップ所有者リファレンス `.spec.backupOwnerReference`

どのKubernetesオブジェクトをバックアップリソースの所有者として設定するかを制御します。

none 所有者参照なし古い動作
self ScheduledBackup オブジェクトが所有者になります
cluster PostgreSQLクラスターが所有者になります

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

オンデマンドバックアップでは、 Backup リソースを作成することにより、いつでもバックアップ操作を手動でトリガーできます。

注釈

使用可能なオプションの完全なリストについては、APIリファレンスの BackupSpec を参照してください。

例オンデマンドバックアップの要求

オンデマンドバックアップを開始するには、次のようなBackup 要求カスタムリソースを適用します。

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

この例では、オペレーターはbarman-cloud-backup ツールを使用してバックアッププロセスをオーケストレーションし、構成済みのオブジェクトストアにバックアップを保存します。

バックアップの進行状況のモニタリング

次を使用してバックアップのステータスを確認できます。

kubectl describe backup backup-example

バックアップの進行中、次のような出力が表示されます。

Name:         backup-example
Namespace:    default
...
Spec:
  Cluster:
    Name:  pg-backup
Status:
  Phase:       running
  Started At:  2020-10-26T13:57:40Z
Events:        <none>

バックアップが正常に完了すると、phase はcompleted に設定され、出力には追加のメタデータが含まれます。

Name:         backup-example
Namespace:    default
...
Status:
  Backup Id:         20201026T135740
  Destination Path:  s3://backups/
  Endpoint URL:      http://minio:9000
  Phase:             completed
  S3 Credentials:
    Access Key Id:
      Name:  minio
      Key:   ACCESS_KEY_ID
    Secret Access Key:
      Name:  minio
      Key:   ACCESS_SECRET_KEY
  Server Name:       pg-backup
  Started At:        2020-10-26T13:57:40Z
  Stopped At:        2020-10-26T13:57:44Z

注釈

オンデマンドバックアップには、PostgreSQLスーパーユーザーまたはアプリケーションユーザーのKubernetesシークレットは含まれません。これらのシークレットが、より広範なKubernetesクラスターバックアップ戦略に含まれていることを確認する必要があります。

バックアップ方法

CloudNativePGは現在、スケジュールされたバックアップとオンデマンドバックアップとして次のバックアップ方法をサポートしています。

plugin – CNPG-Iプラグインを使用します .spec.pluginConfiguration が必要
volumeSnapshot – ネイティブ Kubernetes volume snapshots を使用します
barmanObjectStore – Barman Cloud for object storage を使用します
Barman Cloud Plugin を優先してv1.26から非推奨ですが、下位互換性の為のデフォルトです。

.spec.method フィールドデフォルトbarmanObjectStore を使用して方法を指定します。

クラスターがボリュームスナップショットをサポートするように構成されている場合、次のようなスケジュールされたスナップショットバックアップを有効にできます。

spec:
  method: volumeSnapshot

バックアップ方法としてBarman Cloudプラグインを使用するには、 method: plugin を設定し、それに応じてプラグインを構成します。

Performing a Base Backup に例があります。

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

ベースバックアップの取得には、PostgreSQLインスタンスのディスク上のデータセット全体の読み取りが含まれます。これにより、I/O競合が発生し、アクティブなワークロードのパフォーマンスに影響を与える可能性があります。

この影響を軽減するために、 CloudNativePGは、読み取り専用レプリカからバックアップを実行するPostgreSQLのビルトイン機能を活用して、スタンバイインスタンス からのバックアップ取得をサポートしています。

デフォルトでは、バックアップはクラスター内の 最新のレプリカ で実行されます。使用可能なレプリカがない場合、バックアップは プライマリインスタンス にフォールバックします。

注釈

このセクションの例では、バックアップターゲットの選択に焦点を当てており、バックアップ方法 spec.method は、説明しているスコープに関連していないため、考慮されていません。

仕組み

prefer-standby がターゲットである場合デフォルトの動作、CloudNativePGは次のことを試行します。

最も同期されたスタンバイノードを特定します。
そのスタンバイでバックアッププロセスを実行します。
使用可能なスタンバイがない場合、プライマリにフォールバックします。

この戦略により、プライマリのワークロードへの干渉が最小限に抑えられます。

警告

スタンバイはプライマリと常に最新の状態であるとは限りませんが、最初に使用可能なバックアップから最後にアーカイブされたWALまでの時間連続性では、これは通常無関係です。ベースバックアップは、確かに、PITRを含む復旧操作を開始する開始ポイントを表します。 pg_basebackup で起こることと同様に、オンラインスタンバイからバックアップする場合、プライマリでWALのスイッチを強制しません。これにより、書き込みアクティビティが低い展開では、短期的に`archive_timeout` がキックインする前に予期しない結果が発生する可能性があります。

プライマリでのバックアップの強制

常にプライマリインスタンスでバックアップを実行するには、クラスター構成でバックアップターゲットをprimary に明示的に設定します。

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

警告

primary を**ボリュームスナップショットを使用したコールドバックアップ**のターゲットとして使用する場合、プライマリインスタンスを一時的にシャットダウンする必要があるため、すべての書き込み操作を中断する必要があるため注意してください。ターゲットを明示的に設定していない場合でも、同じ注意が単一インスタンスのクラスターに適用されます。

クラスター全体のターゲットのオーバーライド

Backup またはScheduledBackup リソースを使用して、バックアップごとにクラスターレベルのターゲットをオーバーライドできます。次に、オンデマンドバックアップの例を示します。

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

この例では、クラスターのデフォルトターゲットがprefer-standby であっても、バックアップはプライマリインスタンスから取得されます。

リテンションポリシー

CloudNativePGは、 バックアップに依存しないアーキテクチャ に向けて進化しており、バックアップの責任が外部 CNPG-Iプラグイン に委任されます。これらのプラグインは、CloudNativePGのビルトイン機能と範囲を超える、高度なリテンション管理を含む高度なカスタマイズ可能なデータ保護機能を提供することが期待されています。

この移行の一環として、Cluster リソースのspec.backup.retentionPolicy フィールドは 非推奨 であり、将来のリリースでは削除される予定です。

使用可能な保持機能の詳細については、選択したプラグインのドキュメントを参照してください。例 Retention Policies 。

注釈

ユーザーは、使用しているバックアッププラグインが提供する保持メカニズムを信頼することをお勧めします。これにより、使用中のバックアップ方法の柔軟性と一貫性が保証されます。