Appendix A - Backup on volume snapshots

注釈

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

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

CloudNativePGは、完全に宣言的な方法で、バックアップとリカバリー操作の両方にKubernetesネイティブボリュームスナップショットAPIを直接利用するデータベースオペレーターの最初の既知のケースの1つです。

標準のボリュームスナップショットについて

ボリュームスナップショットは Kubernetes 1.12 (2018) as alpha で最初に導入され、 beta in 1.17 (2019) 、および moved to GA in 1.20 (2020) に昇格しました。安定して広く利用可能な標準になり、3つのカスタムリソース定義VolumeSnapshot 、VolumeSnapshotContent 、VolumeSnapshotClass を提供します。

このKubernetes機能は、次の汎用インターフェイスを定義します。

• PVCから始まる新しいボリュームスナップショットの作成

• 既存のスナップショットの削除

• スナップショットからの新しいボリュームの作成

Kubernetesは、実際の実装を基になるCSIドライバーに委任しますそれらのすべてがボリュームスナップショットをサポートしているわけではありません。通常、ボリュームスナップショットを提供するストレージクラスは、 アプリケーションの透過的な方法でのインクリメンタルおよび差分ブロックレベルのバックアップ をサポートします。これにより、スナップショットのクラスター間の可用性を含む、スタックの複雑さと独立した管理を委任できます。

要件

ボリュームスナップショットがCloudNativePGクラスターで動作するには、PostgreSQLボリュームつまり storage およびwalStorage セクションの動的プロビジョニングに使用される各ストレージクラスがボリュームスナップショットをサポートしていることを確認する必要があります。

手順はストレージクラスごとに異なるため、Kubernetesシステムに展開した特定のストレージクラスと関連するCSIドライバーのドキュメントを参照してください。

通常、それは VolumeSnapshotClass です

特定のストレージクラスの永続ボリュームからスナップショットを取得し、VolumeSnapshot およびVolumeSnapshotContent リソースとして管理できることを保証します。

注釈

ボリュームスナップショットがサポートされていることをサードパーティベンダーに確認するのはあなたの責任です。 CloudNativePGは、この問題に関してKubernetes APIとのみ対話し、特定のCSIドライバーごとにストレージレベルでの問題をサポートすることはできません。

ボリュームスナップショットバックアップを構成する方法

CloudNativePGでは、 backup.volumeSnapshot スタンザを介したボリュームスナップショットバックアップ用に特定のPostgresクラスターを構成できます。

注釈

VolumeSnapshotConfiguration を参照してください。

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

ボリュームスナップショットを使用した一般的な例PGDATAとWALが同じストレージクラスを共有すると仮定した場合、次のとおりです。

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: snapshot-cluster
spec:
  instances: 3

  storage:
    storageClass: @STORAGE_CLASS@
    size: 10Gi
  walStorage:
    storageClass: @STORAGE_CLASS@
    size: 10Gi

  backup:
    # Volume snapshot backups
    volumeSnapshot:
       className: @VOLUME_SNAPSHOT_CLASS_NAME@

  plugins:
  - name: barman-cloud.cloudnative-pg.io
    isWALArchiver: true
    parameters:
      barmanObjectName: @OBJECTSTORE_NAME@

ご覧のとおり、 backup セクションには、 volumeSnapshot スタンザボリュームスナップショットの物理ベースバックアップの制御と plugins スタンザ WALアーカイブ の制御 の両方が含まれています。

注釈

plugin を定義すると、ボリュームスナップショットとプラグインバックアップ戦略の両方を同時に使用して物理的バックアップを取ることができます。

volumeSnapshot.className オプションを使用すると、PostgreSQLクラスターで定義したすべてのストレージボリュームに使用されるデフォルトのVolumeSnapshotClass オブジェクトを参照できます。

注釈

PGDATA およびWALファイルに別のストレージクラスを使用している場合、 walClassName オプションデフォルトで`className` と同じ値を介してそのボリュームに別個の`VolumeSnapshotClass` を指定できます。

ボリュームスナップショットバックアップ用にクラスターを定義したら、このようなバックアップを定期的に要求するScheduledBackup リソースを定義する必要があります。

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

警告

backup document で述べたように、プライマリをターゲットとするように明示的に設定されたコールドスナップショットは、バックアップ中にプライマリがフェンスされ、この期間中のクラスターは読み取り専用になります。安全のため、フェンスされたインスタンスが既に含まれているクラスターでは、コールドスナップショットは拒否されます。

デフォルトでは、CloudNativePGは PostgreSQL defaults of the low-level API for base backups を使用して、ボリュームスナップショットのオンライン/ホットバックアップを要求します。

• バックアップ手順の開始時に、即時チェックポイントを要求しません

• バックアップ手順を終了するときに、WALアーカイバーがバックアップの最後のセグメントをアーカイブするのを待機します

注釈

デフォルト値は、ほとんどの実稼働環境に適しています。ホットバックアップは一貫性があり、スナップショットリカバリーを実行するために使用できます。バックアップの開始から一時レプリケーションスロットを介してWALの保持を保証します。ただし、そのためにはコールドバックアップに依存することをお勧めします。

Cluster リソースの.spec.backup.volumeSnapshot スタンザの次のオプションを使用して、デフォルトの動作を明示的に変更できます。

• online true デフォルトまたはfalse を値として受け入れます

• onlineConfiguration.immediateCheckpoint バックアップ手順を開始する前に、即時チェックポイントを要求するかどうか。技術的には、PostgreSQLのpg_backup_start /pg_start_backup() ファンクションに渡すfast 引数に対応し、true デフォルトまたはfalse を受け入れます

• onlineConfiguration.waitForArchive アーカイバーがバックアップの最後のセグメントを処理するまで待機するかどうか。技術的には、PostgreSQLのpg_backup_stop /pg_stop_backup() ファンクションに渡すwait_for_archive 引数に対応し、true デフォルトまたはfalse を受け入れます

デフォルトでコールドバックアップを取得するようにPostgresクラスターのデフォルト動作を変更する場合、次のようにマニフェストにonline: false オプションを追加するだけです。

# ...
backup:
  volumeSnapshot:
     online: false
     # ...

代わりに、デフォルトの動作として即時チェックポイントを要求する場合、このセクションを追加できます。

# ...
backup:
  volumeSnapshot:
     online: true
     onlineConfiguration:
       immediateCheckpoint: true
     # ...

デフォルト動作のオーバーライド

Backup またはScheduledBackup オブジェクトのonline および必要に応じてonlineConfiguration に別の値を設定することにより、クラスターリソースで定義されたデフォルトの動作を変更できます。

たとえば、オンデマンドのコールドバックアップを発行する場合、.spec.online: false を使用してBackup オブジェクトを作成できます。

apiVersion: postgresql.cnpg.io/v1
kind: Backup
metadata:
  name: snapshot-cluster-cold-backup-example
spec:
  cluster:
    name: snapshot-cluster
  method: volumeSnapshot
  online: false

同様に、 ScheduledBackupの場合

apiVersion: postgresql.cnpg.io/v1
kind: ScheduledBackup
metadata:
  name: snapshot-cluster-cold-backup-example
spec:
  schedule: "0 0 0  **  *"
  backupOwnerReference: self
  cluster:
    name: snapshot-cluster
  method: volumeSnapshot
  online: false

ボリュームスナップショットオブジェクトの永続化

デフォルトでは、 CloudNativePGによって作成されたVolumeSnapshot オブジェクトは、それらを生成したBackup オブジェクトまたはそれらが参照するCluster を削除した後も保持されます。このような動作は、次の値を受け入れる.spec.backup.volumeSnapshot.snapshotOwnerReference オプションによって制御されます。

• none 所有権が設定されていません。Backup および/またはCluster リソースが削除された後もVolumeSnapshot オブジェクトが持続することを意味します

• backup VolumeSnapshot オブジェクトは、それを生成したBackup リソースが所有しており、バックアップオブジェクトが削除されると、ボリュームスナップショットも削除されます

• cluster VolumeSnapshot オブジェクトは、バックアップされたCluster リソースが所有しており、Postgresクラスターが削除されると、ボリュームスナップショットも削除されます

VolumeSnapshot が削除される場合、 VolumeSnapshotContent で指定されたdeletionPolicy が評価されます。

• Retain に設定されている場合、VolumeSnapshotContent オブジェクトは保持されます

• Delete に設定されている場合、VolumeSnapshotContent オブジェクトも削除されます

警告

VolumeSnapshotContent オブジェクトは、バックアップと参照するクラスターに関するすべての情報を保持していません VolumeSnapshot オブジェクトに含まれる注釈やラベルなど。可能ですが、この種のオブジェクトのみからの復元は簡単ではない場合があります。このため、Kubernetesレベルのデータ保護ソリューションを使用する場合でも、常に`VolumeSnapshot` 定義をバックアップすることをお勧めします。

VolumeSnapshotContent の値は、対応するVolumeSnapshotClass 定義で設定されたdeletionPolicy によって決定されます。これは、 .spec.backup.volumeSnapshot.className オプションで参照されます。

Kubernetes documentation on Volume Snapshot Classes を参照してください。

この標準の動作の詳細については、

バックアップボリュームのスナップショットの期限

CloudNativePGは、ボリュームスナップショット方法を使用したバックアップをサポートしています。一部の環境では、ボリュームスナップショットで再試行可能な一時的な問題が発生する場合があります。

backup.cnpg.io/volumeSnapshotDeadline アノテーションは、バックアップを失敗としてマーキングする前に、CloudNativePGが回復可能なエラーの再試行を継続する時間を定義します。

backup.cnpg.io/volumeSnapshotDeadline アノテーションは、 Backup およびScheduledBackup リソースの両方に追加できます。 ScheduledBackup リソースの場合、このアノテーションは、スケジュールから作成されたBackup リソースに自動的に継承されます。

指定しない場合、デフォルトの再試行期限は 10分 です。

エラー処理

ボリュームスナップショット操作中に再試行可能なエラーが発生した場合

1. CloudNativePGは、最初のエラーの時間を記録します。

2. システムは 10秒 ごとに操作を再試行します。

3. エラーが指定された期限またはデフォルトの10分を超えて続く場合、バックアップは 失敗 としてマークされます。

再試行可能なエラー

CloudNativePGは、次の種類のエラーを再試行可能として扱います。

• サーバータイムアウトエラー HTTP 408、429、500、502、503、504

• 競合 オプティミスティックロックエラー

• 内部エラー

• コンテキスト期限超過エラー

• CSIスナップショットコントローラからのタイムアウトエラー

例

次のようにして、アノテーションをScheduledBackup リソースに追加できます。

apiVersion: postgresql.cnpg.io/v1
kind: ScheduledBackup
metadata:
  name: daily-backup-schedule
  annotations:
    backup.cnpg.io/volumeSnapshotDeadline: "20"
spec:
  schedule: "0 0  **  *"
  backupOwnerReference: self
  method: volumeSnapshot
  # other configuration...

アノテーションを使用してScheduledBackup を定義すると、このスケジュールから作成されるBackup リソースは、指定されたタイムアウト値を自動的に継承します。

次の例では、スケジュールから作成されたすべてのバックアップには、回復可能なスナップショットエラーを再試行するために30分のタイムアウトがあります。

apiVersion: postgresql.cnpg.io/v1
kind: ScheduledBackup
metadata:
  name: weekly-backup
  annotations:
    backup.cnpg.io/volumeSnapshotDeadline: "30"
spec:
  schedule: "0 0  **  0"  # Weekly backup on Sunday
  method: volumeSnapshot
  cluster:
    name: my-postgresql-cluster

または、アノテーションをBackup リソースに直接追加できます。

apiVersion: postgresql.cnpg.io/v1
kind: Backup
metadata:
  name: my-backup
  annotations:
    backup.cnpg.io/volumeSnapshotDeadline: "15"
spec:
  method: volumeSnapshot
  # other backup configuration...

ボリュームスナップショットバックアップの例

次の例は、 ebs-sc ストレージクラスとcsi-aws-vsc ボリュームスナップショットクラスを使用して、AWSのEKSクラスターでボリュームスナップショットベースバックアップを構成する方法を示しています。

注釈

例のテストに興味がある場合は、ストレージクラスとスナップショットクラスのインストールプロセスの詳細な手順については、 Volume Snapshots <!--wakeignore:rule=master -->を読んでください。

次のマニフェストは、ボリュームスナップショットに使用する準備ができ、サービスアカウントIRSAのIAMロールを介してS3バケットにWALアーカイブを保存するを作成します AWS S3 を参照してください。

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: hendrix
spec:
  instances: 3

  storage:
    storageClass: ebs-sc
    size: 10Gi
  walStorage:
    storageClass: ebs-sc
    size: 10Gi

  backup:
    volumeSnapshot:
       className: csi-aws-vsc

  plugins:
  - name: barman-cloud.cloudnative-pg.io
    isWALArchiver: true
    parameters:
      barmanObjectName: @OBJECTSTORE_NAME@

  serviceAccountTemplate:
    metadata:
      annotations:
        eks.amazonaws.com/role-arn: "@ARN@"
- --
apiVersion: postgresql.cnpg.io/v1
kind: ScheduledBackup
metadata:
  name: hendrix-vs-backup
spec:
  cluster:
    name: hendrix
  method: volumeSnapshot
  schedule: 0 0 0  **  *
  backupOwnerReference: cluster
  immediate: true

最後のリソースは、深夜に毎日のボリュームスナップショットバックアップを定義し、クラスターが作成された直後に1つを要求します。