バックアップ

重要

バージョン1.21では、 Kubernetes Volume Snapshots のネイティブサポートの導入により、CloudNativePGのバックアップおよびリカバリー機能が大幅に変更されました。その時点まで、バックアップとリカバリーはオブジェクトストアでのみ利用できました。このセクションと バックアップ リカバリー を注意深くお読みください

CloudNativePG 1.15〜1.20のユーザーである場合に1つ。

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

注釈

PostgreSQLでデータベースをバックアップする別の方法があります。pg_dump ユーティリティは、物理的バックアップではなく論理バックアップに依存します。ただし、論理バックアップは事業継続のユースケースには適していないため、少なくともまだCloudNativePGの対象になっていません。 pg_dump ユーティリティを使用する場合は、 Troubleshooting / Emergency backup からインスピレーションを得てください。

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

• WALアーカイブ Postgresによって継続的に書き込まれ、データ耐久性のためにアーカイブされるWALファイルトランザクションログを含む場所

• 物理ベースバックアップ PostgreSQLがデータベースにデータを保存するために使用するすべてのファイルのコピー主にPGDATA およびテーブルスペース

WALアーカイブは、現時点ではオブジェクトストアにのみ保存できます。

一方、CloudNativePGは、物理ベースバックアップを保存する2つの方法をサポートしています。

• 付録A-バックアップ用の共通オブジェクトストア で、tarballsとして - オプションで圧縮

• Kubernetes Volume Snapshots 上、基になるストレージクラスでサポートされている場合

重要

CloudNativePGでバックアップ戦略を選択する前に、時間をかけてWALアーカイブ、ホットおよびコールドバックアップなどの基本的な概念を理解することが重要です。

重要

サポートされているすべてのサービスのリストについては、Kubernetesの公式ドキュメントを参照してください Container Storage Interface (CSI) drivers

スナップショット機能を提供します。

WALアーカイブ

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

• ホットバックアップ サーバーをシャットダウンせずに、Postgresクラスタープライマリまたはスタンバイのインスタンスから物理ベースのバックアップを取得する可能性。オンラインバックアップとしても知られています

• ポイント インタイム リカバリー PITR システムで最初に使用可能なベースバックアップから任意の時点で復旧できます。

警告

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

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

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

レプリカクラスター に拡張することもできます。

configure a WAL archive を使用すると、CloudNativePGは、リージョンを超えても、ディザスターリカバリーに5分以下のRPOをすぐに提供します。

重要

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

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

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

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

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

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

オブジェクトストアまたはボリュームスナップショットどちらを使用しますか?

CloudNativePGでは、オブジェクトストアベースのバックアップ

• 常にWALアーカイブが必要

• ホットバックアップのみをサポート

• インクリメンタルコピーをサポートしていません

• 差分コピーをサポートしていません

代わりにボリュームスナップショット

• WALアーカイブは必要ありませんが、運用環境では常にお勧めします

• 基になるストレージクラスに応じて、インクリメンタルコピーをサポート

• 基になるストレージクラスに応じて、差分コピーをサポート

• コールドバックアップもサポート

どちらを使用するかは、次を含む特定の要件と環境によって異なります。

• Kubernetesクラスターでの実行可能なオブジェクトストアソリューションの可用性

• ボリュームスナップショットをサポートする信頼できるストレージクラスの可用性

• データベースのサイズ オブジェクトストアの場合、データベースが大きくなると、バックアップ、そして最も重要なことに、リカバリ手順に時間がかかります後者はRTOに影響します。超大規模データベースVLDBが存在する場合、一般的なアドバイスは、コピーオンライトのおかげで、より速いリカバリを提供するため、ボリュームスナップショットに依存することです

• データのモビリティと、別のリージョンまたはその後のリージョンのセカンダリの場所にバックアップファイルを保存または中継する可能性

• その他の要素、主に基になるストレージソリューションへの信頼と精通に基づいています

以下の概要表は、物理ベースバックアップの保存に使用可能な2つの方法の主な違いの一部を強調表示しています。

	Object store	Volume Snapshots
WAL archiving	Required	Recommended (1)
Cold backup	✗	✓
Hot backup	✓	✓
Incremental copy	✗	✓ (2)
Differential copy	✗	✓ (2)
Backup from a standby	✓	✓
Snapshot recovery	✗ (3)	✓
Point In Time Recovery (PITR)	✓	Requires WAL archive
Underlying technology	Barman Cloud	Kubernetes API
上記の表の注意事項については、以下の説明を参照してください。 > >
1.現在、WALアーカイブはオブジェクトストア上にある必要があります >
2.PostgreSQLボリュームの基になるストレージクラスでサポートされている場合
> 3.スナップショットリカバリーはエミュレート可能>
bootstrap.recovery.recoveryTarget.targetImmediate
オプションを使用する

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

スケジュールされたバックアップは、CloudNativePGでバックアップ戦略を構成するための推奨される方法です。これらはScheduledBackup リソースによって管理されます。

注釈

ScheduledBackupSpec {postgresql-cnpg-io-v1-ScheduledBackupSpec} を参照してください。

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

schedule フィールドでは、 Go `cron package format <https://pkg.go.dev/github.com/robfig/cron#hdr-CRON_Expression_Format>`_ で表現される秒を含む 6期間cronスケジュール 仕様を定義できます。

警告

このフォーマットは`seconds` フィールドも受け入れます。Unix/Linuxシステムの`crontab` フォーマットとは異なることに注意してください。

これは、スケジュールされたバックアップの例です。

apiVersion: postgresql.cnpg.io/v1
kind: ScheduledBackup
metadata:
  name: backup-example
spec:
  schedule: "0 0 0  **  *"
  backupOwnerReference: self
  cluster:
    name: pg-backup

上記の例では、スケジュールで秒、分、および時間を指定する一方、日、月、曜日にすべてを意味するワイルドカードを指定するため、毎日午前0時にバックアップをスケジュールします。

Kubernetes CronJobでは、秒が含まれないため、同等の式は0 0  **  * になります。

ヒント

バックアップ頻度は、完全またはポイントインタイム復旧操作が必要なディザスターの発生後の復旧時間オブジェクトRTOに影響を与える可能性があります。私たちのアドバイスは、バックアップをリカバリーし、スクラッチからのリカバリーにかかる時間を測定することにより、バックアップを定期的にテストして、RTOの予測可能性を調整することです。リカバリ時間は、ベースバックアップのサイズと、リカバリ中にアーカイブから取得して再生する必要があるWALファイルの量に影響されます。WALアーカイブは、PostgreSQLでの継続的なバックアップを可能にするものであることに注意してください。私たちの経験に基づいて、ほとんどの場合、毎週のベースバックアップで十分です。ただし、1日1回より頻繁にバックアップをスケジュールすることは非常にまれです。

.spec.method 属性、デフォルトではbarmanObjectStore に設定を介して、定義されたオブジェクトストアまたはボリュームスナップショットのバックアップをスケジュールするかどうかを選択できます。

オブジェクトストアまたはボリュームスナップショットどちらを使用しますか? を適切に定義している場合

クラスターのbackup スタンザでは、ボリュームスナップショットのベースバックアップのスケジュールを開始するようにmethod: volumeSnapshot を設定できます。

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

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

注釈

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

• none: 作成されたバックアップオブジェクトの所有者参照なしフィールドが導入される前と同じ動作

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

注釈

BackupSpec {postgresql-cnpg-io-v1-BackupSpec} を参照してください。

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

新しいバックアップを要求するには、次のような新しい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 <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クラスターの標準のバックアップ手順の一部としてバックアップされることになっています。

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

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

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

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

注釈

スタンバイはプライマリと常に最新の状態であるとは限りませんが、最初に使用可能なバックアップから最後にアーカイブされたWALまでの時間連続性では、これは通常無関係です。ベースバックアップは、確かに、PITRを含む復旧操作を開始する開始ポイントを表します。 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は常にプライマリインスタンスを選択します。