Backup ====== .. raw:: html .. Note:: このセクションでは、PostgreSQLの**物理バックアップ**について説明します。 PostgreSQLは、 `pg_dump` ユーティリティを使用した論理バックアップもサポートしていますが、これらは**ビジネス継続性に適しておらず**、CloudNativePGによって**管理されません**。 `pg_dump` を使用する場合は、 :ref:`*Troubleshooting / Emergency backup* section ` を参照してください。 ガイダンス用に。 　 .. Note:: バージョン1.26から、ネイティブバックアップおよびリカバリー機能は、コアオペレーターの**段階的にフェーズアウト**され、公式CNPG-Iプラグインに移動されます。この移行は、**WALアーカイブ**、*物理ベースバックアップ**の管理を標準化する拡張可能なインターフェイス**CNPG-I**によって有効になる**バックアップに依存しないアーキテクチャ**へのCloudNativePGのシフトと一致しています。 、および対応する**リカバリプロセス**。 　 CloudNativePGは現在、2つの主な方法で **PostgreSQLクラスターの物理バックアップ** をサポートしています。 - **`CNPG-I `_ プラグイン経由** CloudNativePGコミュニティは `**Barman Cloud Plugin** `_ を公式にサポート オブジェクトストレージサービスとの統合用。 - **ネイティブ** 、以下をサポート *( Barman Cloudプラグインを優先して1.26から非推奨ですが)* - :ref:`Kubernetes Volume Snapshots ` 、基になるストレージクラスでサポートされている場合 CloudNativePGでバックアップ戦略を選択する前に、 :ref:`メインコンセプト <メインコンセプト>` でカバーされている基本的な概念を理解することが重要です セクション。これらには、WALアーカイブ、ホットおよびコールドバックアップ、スタンバイからのバックアップの実行などが含まれます。 メインコンセプト ---------------- PostgreSQLは、ファイルシステムレベルの物理コピーに基づいて、ファーストクラスのバックアップおよびリカバリー機能をネイティブに提供します。これらはミッションクリティカルな運用データベースで15年以上使用され、世界中の組織がPostgresでディザスターリカバリー目標を達成するのを支援してきました。 CloudNativePGでは、各PostgreSQLクラスターのバックアップインフラストラクチャは次のリソースで構成されます。 - **WALアーカイブ** Postgresによって継続的に書き込まれ、データ耐久性のためにアーカイブされるWALファイルトランザクションログを含む場所 - **物理ベースバックアップ** PostgreSQLがデータベースにデータを保存するために使用するすべてのファイルのコピー主に\ ``PGDATA`` およびテーブルスペース CNPG-Iは、WALアーカイブアーカイブとリストア操作の両方、およびベースバックアップおよび対応する復元プロセスを管理するための汎用かつ拡張可能なインターフェイスを提供します。 WALアーカイブ ^^^^^^^^^^^^^ PostgreSQLのWALアーカイブは、 **継続的バックアップ** の中心であり、次の理由で基本的なものです。 - **ホットバックアップ** サーバーをシャットダウンせずに、Postgresクラスタープライマリまたはスタンバイのインスタンスから物理ベースのバックアップを取得する可能性。オンラインバックアップとしても知られています - **ポイント インタイム リカバリー** PITR システムで最初に使用可能なベースバックアップから任意の時点で復旧する可能性。 .. Warning:: WALアーカイブだけでは役に立ちません。物理ベースのバックアップがないと、PostgreSQLクラスターを復元できません。 　 一般に、WALアーカイブの存在により、PostgreSQLクラスターの復元力が強化され、各インスタンスは、必要に応じてアーカイブから必要なWALファイルを取得できます。通常、WALアーカイブの保持期間は、通常これらのファイルをリサイクルするPostgresインスタンスよりも長くなります。 。 このユースケースは、WALアーカイブに依存するだけで長距離にわたって同期でき、さまざまなリージョンにわたってディザスターリカバリー目標を拡張できるため、 :ref:`レプリカクラスター <レプリカクラスター>` に拡張することもできます。 :ref:`configure a WAL archive ` を実行すると、CloudNativePGは、リージョンを超えても、ディザスターリカバリーに :ref:`PgBouncerPoolMode ` ≤ 5分をすぐに提供します。 .. Note:: 常に本番でWALアーカイブをセットアップすることをお勧めします。通常ステージング環境と開発環境が関係する既知のユースケースがあり、上記の利点はいずれも必要とされず、WALアーカイブは必要ありません。この場合のRPOは、24時間毎日のバックアップまたは無限バックアップなしなどの任意の値です。 　 コールドおよびホットバックアップ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ホットバックアップは前のセクションで既に定義されています。これらはWALアーカイブの存在を必要とし、最新のデータベース管理システムでは標準です。 **コールドバックアップ** は、オフラインバックアップとしても知られ、代わりに、PostgreSQLインスタンススタンバイまたはプライマリがシャットダウンしたときに取得される物理ベースバックアップです。これらは定義ごとに一貫しており、シャットダウンされた時点のデータベースのスナップショットを表します。 その結果、PostgreSQLインスタンスは、WALアーカイブを必要とせずにコールドバックアップから再起動できますが、利用可能な場合はそれを利用できます前のセクションで強調表示した復旧面のすべての利点を備えています。 RPOが高く1時間または24時間など、保持期間が短い状況では、コールドバックアップは、ディザスターリカバリー計画で検討される実行可能なオプションを表します。 使用可能なバックアップオプションの比較:オブジェクトストアとボリュームスナップショット ------------------------------------------------------------------------------------- CloudNativePGは現在、物理バックアップの2つの主要なアプローチをサポートしています。 - **オブジェクトストアベースのバックアップ** 、 `**Barman Cloud Plugin** `_ または :ref:`**deprecated native integration** ` 経由 - :ref:`**Volume Snapshots** ` 、Kubernetes CSIインターフェイスとサポートされているストレージクラスを使用 .. Note:: CNPG-Iは、サードパーティが独自のバックアッププラグインをビルドおよび統合できるように設計されています。時間の経過とともに、サポートされているバックアップソリューションのエコシステムが成長すると予想されます。 　 オブジェクトストアベースのバックアップ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ オブジェクトストアへのバックアップAWS S3、Azure Blob、GCSなど - 常にWALアーカイブが必要 - ホットバックアップのみをサポート - インクリメンタルまたは差分コピーをサポートしていません - リテンションポリシーのサポート ボリュームスナップショット ^^^^^^^^^^^^^^^^^^^^^^^^^^ ネイティブボリュームのスナップショット - WALアーカイブは必要ありませんが、運用環境での使用を強くお勧めします - 基になるストレージクラスの機能に応じて、インクリメンタルおよび差分コピーをサポート - ホットおよびコールドバックアップの両方をサポート - リテンションポリシーをサポートしていません 2つの間の選択 ^^^^^^^^^^^^^ 最適なアプローチは、環境と操作要件によって異なります。次の要素を考慮します。 - **オブジェクトストアの可用性** Kubernetesクラスターが、安定したネットワーキングレイヤーを含む信頼できるオブジェクトストレージソリューションにアクセスできることを確認します。 - **ストレージクラス機能** ストレージクラスが、インクリメンタル/差分機能を備えたCSIボリュームスナップショットをサポートしていることを確認します。 - **データベースサイズ** 非常に大規模なデータベースVLDBの場合、コピーオンライトテクノロジーによる高速なリカバリーが可能になるため、 **ボリュームスナップショットが一般的に優先されます** 。これにより、 :ref:`Recovery Time Objective (RTO) ` が大幅に向上します。 - **データモビリティ** オブジェクトストアベースのバックアップは、リージョンまたは環境を超えてバックアップをレプリケートまたは保存するためのより高い柔軟性を提供する場合があります。 - **操作の慣れ** ストレージの管理におけるチームの経験と自信に最も適した方法を選択します。 比較の概要 ^^^^^^^^^^ .. csv-table:: :header: Feature,Object Store,Volume Snapshots :widths: 12,25,15 :align: left :class: longtable **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`` カスタムリソースを使用して定義されます。 .. Note:: 構成オプションの完全なリストについては、 :ref:`ScheduledBackupSpec ` を参照してください。 APIリファレンスで。 　 Cronスケジュール ^^^^^^^^^^^^^^^^ ``schedule`` フィールドは、秒を含む *6フィールドのcron式*\ を使用して、バックアップを発生する*\* タイミングを定義します。このフォーマットは `Go `cron` package specification `_ に従います。 .. Warning:: このフォーマットは、従来のUnix/Linux `crontab` とは異なります。最初のエントリとして**seconds**フィールドが含まれます。 　 毎日のスケジュールされたバックアップの例 .. code:: yaml 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:: バックアップの頻度は、 **目標復旧時間** :ref:`バックアップ頻度とRTO <バックアップ頻度とRTO>` に直接影響します。 　 継続的なバックアップに基づいてディザスターリカバリー戦略を最適化するには - バックアップからの復元を定期的にテストします。 - 完全なリカバリーに必要な時間を測定します。 - ベースバックアップのサイズと、取得および再生する必要があるWALファイルの数を考慮します。 ほとんどの場合、 **毎週のベースバックアップ** で十分です。 1日1回よりも多くの頻度で完全なバックアップをスケジュールすることはほとんどありません。 即時バックアップ ^^^^^^^^^^^^^^^^ ``ScheduledBackup`` の作成時にすぐにバックアップをトリガーするには .. code:: yaml spec: immediate: true スケジュールされたバックアップを一時停止する ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ スケジュールされたバックアップの実行を一時的に停止するには .. code:: yaml spec: suspend: true バックアップ所有者リファレンス ``.spec.backupOwnerReference`` ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ どのKubernetesオブジェクトをバックアップリソースの所有者として設定するかを制御します。 - ``none`` 所有者参照なし 古い動作 - ``self`` ``ScheduledBackup`` オブジェクトが所有者になります - ``cluster`` PostgreSQLクラスターが所有者になります オンデマンド バックアップ ------------------------- オンデマンドバックアップでは、 ``Backup`` リソースを作成することにより、いつでもバックアップ操作を手動でトリガーできます。 .. Note:: 使用可能なオプションの完全なリストについては、APIリファレンスの :ref:`BackupSpec ` を参照してください。 　 例オンデマンドバックアップの要求 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ オンデマンドバックアップを開始するには、次のような\ ``Backup`` 要求カスタムリソースを適用します。 .. code:: yaml apiVersion: postgresql.cnpg.io/v1 kind: Backup metadata: name: backup-example spec: method: barmanObjectStore cluster: name: pg-backup この例では、オペレーターは\ ``barman-cloud-backup`` ツールを使用してバックアッププロセスをオーケストレーションし、構成済みのオブジェクトストアにバックアップを保存します。 バックアップの進行状況のモニタリング ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 次を使用してバックアップのステータスを確認できます。 .. code:: bash kubectl describe backup backup-example バックアップの進行中、次のような出力が表示されます。 .. code:: text Name: backup-example Namespace: default ... Spec: Cluster: Name: pg-backup Status: Phase: running Started At: 2020-10-26T13:57:40Z Events: バックアップが正常に完了すると、\ ``phase`` は\ ``completed`` に設定され、出力には追加のメタデータが含まれます。 .. code:: text 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 -------------- .. Note:: オンデマンドバックアップには、PostgreSQLスーパーユーザーまたはアプリケーションユーザーのKubernetesシークレットは含まれません。これらのシークレットが、より広範なKubernetesクラスターバックアップ戦略に含まれていることを確認する必要があります。 　 バックアップ方法 ---------------- CloudNativePGは現在、スケジュールされたバックアップとオンデマンドバックアップとして次のバックアップ方法をサポートしています。 - ``plugin`` – CNPG-Iプラグインを使用します ``.spec.pluginConfiguration`` が必要 - ``volumeSnapshot`` – ネイティブ :ref:`Kubernetes volume snapshots ` を使用します - ``barmanObjectStore`` – :ref:`Barman Cloud for object storage ` を使用します - `Barman Cloud Plugin `_ を優先してv1.26から非推奨ですが、下位互換性の為のデフォルトです。 ``.spec.method`` フィールドデフォルト\ ``barmanObjectStore`` を使用して方法を指定します。 クラスターがボリュームスナップショットをサポートするように構成されている場合、次のようなスケジュールされたスナップショットバックアップを有効にできます。 .. code:: yaml spec: method: volumeSnapshot バックアップ方法としてBarman Cloudプラグインを使用するには、 ``method: plugin`` を設定し、それに応じてプラグインを構成します。 `Performing a Base Backup `_ に例があります。 スタンバイからのバックアップ ---------------------------- ベースバックアップの取得には、PostgreSQLインスタンスのディスク上のデータセット全体の読み取りが含まれます。これにより、I/O競合が発生し、アクティブなワークロードのパフォーマンスに影響を与える可能性があります。 この影響を軽減するために、 **CloudNativePGは、読み取り専用レプリカからバックアップを実行するPostgreSQLのビルトイン機能を活用して、スタンバイインスタンス** からのバックアップ取得をサポートしています。 デフォルトでは、バックアップはクラスター内の **最新のレプリカ** で実行されます。使用可能なレプリカがない場合、バックアップは **プライマリインスタンス** にフォールバックします。 .. Note:: このセクションの例では、バックアップターゲットの選択に焦点を当てており、バックアップ方法 `spec.method` は、説明しているスコープに関連していないため、考慮されていません。 　 仕組み ^^^^^^ ``prefer-standby`` がターゲットである場合デフォルトの動作、CloudNativePGは次のことを試行します。 1. 最も同期されたスタンバイノードを特定します。 2. そのスタンバイでバックアッププロセスを実行します。 3. 使用可能なスタンバイがない場合、プライマリにフォールバックします。 この戦略により、プライマリのワークロードへの干渉が最小限に抑えられます。 .. Warning:: スタンバイはプライマリと常に最新の状態であるとは限りませんが、最初に使用可能なバックアップから最後にアーカイブされたWALまでの時間連続性では、これは通常無関係です。ベースバックアップは、確かに、PITRを含む復旧操作を開始する開始ポイントを表します。 `pg_basebackup `_ で起こることと同様に、オンラインスタンバイからバックアップする場合、プライマリでWALのスイッチを強制しません。これにより、書き込みアクティビティが低い展開では、短期的に`archive_timeout` がキックインする前に予期しない結果が発生する可能性があります。 　 プライマリでのバックアップの強制 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 常にプライマリインスタンスでバックアップを実行するには、クラスター構成でバックアップターゲットを\ ``primary`` に明示的に設定します。 .. code:: yaml apiVersion: postgresql.cnpg.io/v1 kind: Cluster metadata: [...] spec: backup: target: "primary" .. Warning:: `primary` を**ボリュームスナップショットを使用したコールドバックアップ**のターゲットとして使用する場合、プライマリインスタンスを一時的にシャットダウンする必要があるため、すべての書き込み操作を中断する必要があるため注意してください。ターゲットを明示的に設定していない場合でも、同じ注意が単一インスタンスのクラスターに適用されます。 　 クラスター全体のターゲットのオーバーライド ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ``Backup`` または\ ``ScheduledBackup`` リソースを使用して、バックアップごとにクラスターレベルのターゲットをオーバーライドできます。次に、オンデマンドバックアップの例を示します。 .. code:: yaml 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 `_ 。 .. Note:: ユーザーは、使用しているバックアッププラグインが提供する保持メカニズムを信頼することをお勧めします。これにより、使用中のバックアップ方法の柔軟性と一貫性が保証されます。