Kubernetes でのバックアップと復元

このページでは、AlloyDB Omni Kubernetes オペレーターを使用して AlloyDB Omni データをバックアップおよび復元する方法について説明します。これには、マニフェスト ファイルと kubectl コマンドライン ツールを使用して Kubernetes クラスタを更新する方法に関する基本的な知識が必要です。Kubernetes クラスタに AlloyDB Omni をインストールして実行する方法については、Kubernetes に AlloyDB をインストールするをご覧ください。

AlloyDB Omni の継続的なバックアップと復元を有効にするには、データベース クラスタごとにバックアップ プランを作成する必要があります。バックアップは、backupPlan リソースで定義されたバックアップ スケジュールに基づいて取得されます。バックアップ プランでバックアップ スケジュールが定義されていない場合、デフォルトでは連続バックアップが毎日実行されます。復元ウィンドウ内の任意のタイムスタンプから、秒単位でバックアップを復元またはクローンを作成できます。

Kubernetes 以外のデプロイメントで AlloyDB Omni データをバックアップして復元する方法については、AlloyDB Omni 用に Barman を設定すると AlloyDB Omni 用に pgBackRest を設定するをご覧ください。

バックアップを有効にしてスケジュールを設定する

継続的なバックアップは、データベース クラスタのバックアップ プラン リソースを作成するときに有効になります。クラスタの継続的なバックアップを有効にするには、データベース クラスタごとに backupPlan リソースを作成する必要があります。このバックアップ プラン リソースは、次のパラメータを定義します。

• AlloyDB Omni オペレーターがバックアップを保存する場所。これは、Kubernetes クラスタまたは Cloud Storage バケットにローカルに配置できます。

• full、incremental、differential バックアップを自動的に作成する複数のバックアップ スケジュールを設定できます。このスケジュールは、バックアップ プランの初期定義時を含め、いつでも一時停止できます。バックアップ プランが一時停止されている場合、スケジュール設定されたバックアップは作成されませんが、バックアップ プランを使用して手動でバックアップを作成することはできます。

  バックアップ スケジュールが指定されていない場合、デフォルトは「0 0 * * *」です。これは、ローカル時間の午前 0 時に 1 日 1 回完全バックアップを実行します。

• 保存されたバックアップの保持期間。最短で 1 日、最長で 90 日間です。デフォルト値は 14 です。

データベース クラスタには、それぞれに独自の名前と構成を持つ複数のバックアップ プランを含めることができます。データベース クラスタに異なるバックアップ スケジュールを持つ複数の backupPlan リソースを作成する場合は、バックアップ リソースごとに一意のバックアップ ロケーションを定義する必要があります。

バックアップをローカルに保存するプランを作成する

ローカルに保存されるバックアップを有効にするには、次のマニフェストを適用します。

    apiVersion: alloydbomni.dbadmin.goog/v1
    kind: BackupPlan
    metadata:
      name: BACKUP_PLAN_NAME
      namespace: NAMESPACE
    spec:
      dbclusterRef: DB_CLUSTER_NAME
      backupSchedules:
        full: "FULL_CRON_SCHEDULE"
        differential: "DIFF_CRON_SCHEDULE"
        incremental: "INCR_CRON_SCHEDULE"
      backupRetainDays: RETENTION_DAYS
      paused: PAUSED_BOOLEAN

次のように置き換えます。

• BACKUP_PLAN_NAME: このバックアップ プラン リソースの名前（例: backup-plan-1）。

• NAMESPACE: このバックアップ プランの Kubernetes Namespace。データベース クラスタの名前空間と一致する必要があります。

• DB_CLUSTER_NAME: データベース クラスタの名前。作成時に割り当てたものです。

• FULL_CRON_SCHEDULE: すべてのデータを含むフル バックアップを作成するバックアップ スケジュール。cron 形式で表されます。たとえば、毎週日曜日の 00:00 に完全バックアップを取得するには、「0 0 * * 0」に設定します。

• DIFF_CRON_SCHEDULE: 最初はフル バックアップであるバックアップを作成するバックアップ スケジュール。その後のバックアップは、データの変更に基づく差分バックアップで、cron 形式で表されます。たとえば、毎週水曜日の 22:00 に差分バックアップを作成するには、「0 22 * * 3」に設定します。

• INCR_CRON_SCHEDULE: 前回のフルバックアップ、差分バックアップ、増分バックアップから変更されたデータを含むバックアップを作成するバックアップ スケジュール。cron 形式で表されます。たとえば、毎日 21:00 に増分バックアップを作成するには、「0 21 * * *」と設定します。

• RETENTION_DAYS: AlloyDB Omni オペレーターがこのバックアップを保持する日数。1～90 の整数を指定してください。デフォルト値は 14 です。

• PAUSED_BOOLEAN: バックアップ プランが一時停止されているかどうかを指定します。次のいずれかの値を指定します。

  • true: バックアップが一時停止され、スケジュール設定されたバックアップは作成されません。

  • false: AlloyDB Omni オペレーターは、cronSchedule で指定されたスケジュールに従ってバックアップを作成します。true に明示的に設定されていない場合、これがデフォルト値になります。

  デフォルト値は false です。

Cloud Storage にバックアップを保存するプランを作成する

Cloud Storage に保存されるバックアップを有効にするには、次の操作を行います。

注: ローカルにバックアップを保存する場合は、ディスク容量を慎重に計画してください。保持期間が長くなるほど、必要な容量は増加します。

1. Cloud Storage バケットを作成します。このバケットに割り当てた名前をメモしておきます。この名前は後の手順で必要になります。

2. バックアップをバケットに追加するためのサービス アカウントを作成します。

3. サービス アカウントに storage.objectAdmin Identity and Access Management ロールを付与します。

4. サービス アカウントのキーを作成します。これにより、秘密鍵がローカル環境にダウンロードされます。

5. ダウンロードした鍵ファイルの名前を key.json に変更します。

6. 秘密鍵を含む Kubernetes Secret を作成します。

   kubectl create secret generic SECRET_NAME --from-file=KEY_PATH -n NAMESPACE

   次のように置き換えます。

   • SECRET_NAME: 作成する Kubernetes Secret の名前（例: gcs-key）。

   • KEY_PATH: 前の手順でダウンロードした key.json ファイルのローカル ファイル システム パス。

   • NAMESPACE: データベース クラスタの Namespace。

7. 次のマニフェストを適用します。

     apiVersion: alloydbomni.dbadmin.goog/v1
     kind: BackupPlan
     metadata:
       name: BACKUP_PLAN_NAME
       namespace: NAMESPACE
     spec:
       dbclusterRef: DB_CLUSTER_NAME
       backupSchedules:
         full: "FULL_CRON_SCHEDULE"
         differential: "DIFF_CRON_SCHEDULE"
         incremental: "INCR_CRON_SCHEDULE"
       backupRetainDays: RETENTION_DAYS
       paused: PAUSED_BOOLEAN
       backupLocation:
         type: GCS
         gcsOptions:
           bucket: BUCKET_URL
           key: BACKUP_PATH
           secretRef:
             name: SECRET_NAME
             namespace: NAMESPACE
   

   次のように置き換えます。

   • BACKUP_PLAN_NAME: このバックアップ プラン リソースの名前（例: backup-plan-1）。

   • NAMESPACE: このバックアップ プランの Kubernetes Namespace。データベース クラスタの名前空間と一致する必要があります。

   • DB_CLUSTER_NAME: データベース クラスタの名前。作成時に割り当てたものです。

   • FULL_CRON_SCHEDULE: すべてのデータを含むフル バックアップを作成するバックアップ スケジュール。cron 形式で表されます。たとえば、毎週日曜日の 00:00 に完全バックアップを取得するには、「0 0 * * 0」に設定します。

   • DIFF_CRON_SCHEDULE: 最初はフル バックアップであるバックアップを作成するバックアップ スケジュール。その後のバックアップは、データの変更に基づく差分バックアップで、cron 形式で表されます。たとえば、毎週水曜日の 22:00 に差分バックアップを作成するには、「0 22 * * 3」に設定します。

   • INCR_CRON_SCHEDULE: 前回のフルバックアップ、差分バックアップ、増分バックアップから変更されたデータを含むバックアップを作成するバックアップ スケジュール。cron 形式で表されます。たとえば、毎日 21:00 に増分バックアップを作成するには、「0 21 * * *」と設定します。

   • RETENTION_DAYS: AlloyDB Omni オペレーターがこのバックアップを保持する日数。1～90 の整数を指定してください。デフォルト値は 14 です。

   • PAUSED_BOOLEAN: バックアップ プランが一時停止されているかどうかを指定します。次のいずれかの値を指定します。

     • true: バックアップが一時停止され、スケジュール設定されたバックアップは作成されません。

     • false: AlloyDB Omni オペレーターは、cronSchedule で指定されたスケジュールに従ってバックアップを作成します。true に明示的に設定されていない場合、これがデフォルト値になります。

     デフォルト値は false です。

   • BUCKET_URL: 前の手順で作成した Cloud Storage バケットの名前。これはバケットの完全な URL ではありません。バケット名の前に gs:// を付けないでください。

   • BACKUP_PATH: AlloyDB Omni オペレーターが Cloud Storage バケット内にバックアップを書き込むディレクトリのパス。パスは / で始まる絶対パスにする必要があります。

   • SECRET_NAME: 前の手順で作成した Kubernetes Secret に選択した名前。

バックアップを手動で作成する

データベース クラスタにすでに適用されているバックアップ プランを使用して、バックアップ リソースを手動でいつでも作成できます。AlloyDB Omni オペレーターは、選択したバックアップ プランのストレージ ロケーションと保持期間を新しい手動バックアップに適用します。

バックアップを手動で作成するには、次のマニフェストを適用します。

apiVersion: alloydbomni.dbadmin.goog/v1
kind: Backup
metadata:
  name: BACKUP_NAME
  namespace: NAMESPACE
spec:
  dbclusterRef: DB_CLUSTER_NAME
  backupPlanRef: BACKUP_PLAN_NAME
  manual: true
  physicalBackupSpec:
    backupType: BACKUP_TYPE

次のように置き換えます。

• BACKUP_NAME: このバックアップの名前（例: backup-1）。

• NAMESPACE: この復元の Kubernetes Namespace。データベース クラスタの名前空間と一致する必要があります。

• BACKUP_PLAN_NAME: このバックアップが属するバックアップ プラン リソースの名前。バックアップ プランの作成時に選択した名前と一致している必要があります。

• DB_CLUSTER_NAME: データベース クラスタの名前。作成時に割り当てたものです。

• BACKUP_TYPE: 作成する手動バックアップのタイプを指定します。次のいずれかの値を選択します。

  • full: すべてのデータを含む完全バックアップを作成します。

  • diff: 最後の完全バックアップに依存する差分バックアップを作成します。その後のバックアップは、データの変更に基づいて差分バックアップになります。

  • incr: 前回の完全バックアップまたは差分バックアップに依存する増分バックアップを作成し、前回の完全バックアップまたは差分バックアップから変更されたデータを含めます。

バックアップのモニタリングと一覧表示

バックアップ プランとバックアップはすべて Kubernetes クラスタのリソースです。これらの情報は、kubectl get コマンドを使用して表示できます。

バックアップ プランの概要を表示する

データベース クラスタのバックアップ プランに関する情報を表示するには、次のコマンドを実行します。

kubectl get backupplan.alloydbomni.dbadmin.goog -n NAMESPACE

NAMESPACE は、データベース クラスタの Namespace に置き換えます。

出力は次のようになります。

NAME               PHASE   LASTBACKUPTIME         NEXTBACKUPTIME
backup-plan-prod   Ready   2023-10-26T17:26:43Z   2023-10-27T00:00:00Z

バックアップのリストを表示する

データベース クラスタで使用可能なバックアップのリストを表示するには、次のコマンドを実行します。

kubectl get backup.alloydbomni.dbadmin.goog -n NAMESPACE

NAMESPACE は、データベース クラスタの Namespace に置き換えます。

出力は次のようになります。

NAME                              PHASE       COMPLETETIME               TYPE
backup-plan-prod-20231026172643   Succeeded   2023-10-26T17:26:53Z       full
manual-backup-1                   Succeeded   2023-10-26T18:15:27Z       full
manual-backup-2                   InProgress                             full

出力テーブルの各行は、次の属性を持つバックアップ リソースを表します。

• バックアップの名前。
• バックアップの状態。Succeeded は、復元の準備ができているバックアップを示します。
• バックアップの作成時のタイムスタンプ。

バックアップからの復元

注意: バックアップから復元すると、データベース クラスタのデータがすべて上書きされます。

AlloyDB では、個々のバックアップから復元したり、特定の時点のバックアップを使用してクラスタをクローンしたりできます。

名前付きバックアップから復元する

バックアップから復元し、データベース クラスタ内のデータをバックアップ内のデータに置き換える手順は次のとおりです。

1. フェーズが Succeeded のすべてのバックアップを一覧表示します。

   kubectl get backup.alloydbomni.dbadmin.goog -n NAMESPACE | grep Succeeded

   NAMESPACE は、データベース クラスタの Namespace に置き換えます。

   適切なバックアップ候補が 1 つ以上存在する場合、出力は次のようになります。

   backup-plan-prod-20231026172643   Succeeded   2023-10-26T17:26:53Z
   manual-backup-1                   Succeeded   2023-10-26T18:15:27Z
   

2. 前の手順で表示されたバックアップのいずれかを選択して、復元元のバックアップにします。名前をメモします。これは次のステップで使用します。

3. 次のマニフェストを適用します。

     apiVersion: alloydbomni.dbadmin.goog/v1
     kind: Restore
     metadata:
       name: RESTORE_NAME
       namespace: NAMESPACE
     spec:
       sourceDBCluster: DB_CLUSTER_NAME
       backup: BACKUP_NAME
   

   次のように置き換えます。

   • RESTORE_NAME: このマニフェストが作成するデータ復元リソースで使用する名前（例: restore-1）。

   • DB_CLUSTER_NAME: データベース クラスタの名前。作成時に割り当てたものです。

   • BACKUP_NAME: 前の手順で選択したバックアップの名前。

特定の時点からクラスタのクローンを作成する

AlloyDB Omni オペレーターを使用すると、復元ウィンドウ内の任意の時点からクラスタのデータをクローンできます。復元ウィンドウの長さは、保持期間によって直接決まります。

たとえば、保持期間が 14 日に設定されている場合、14 日より古いデータは復元できません。復元期間内の任意の時点に復元できます。AlloyDB Omni オペレーターは、指定された値より 1 日長くバックアップとログを保持します。

注: AlloyDB Omni オペレーターは、同じ Namespace と同じ Kubernetes クラスタ内の特定の時点からのクローンをサポートしています。名前空間間のクローン作成はサポートされていません。クラスタ間の復元またはクローンについては、バックアップと復元ベースの障害復旧のマニュアルをご覧ください。

1. 復元期間をモニタリングして、復元ポイントを特定します。

   kubectl get backupplan.alloydbomni.dbadmin.goog BACKUP_NAME -n NAMESPACE -o json | jq .status.recoveryWindow
   

   レスポンスの例を次に示します。

   recoveryWindow:
   begin: "2024-01-31T02:54:35Z"
   

   復元リソースでは、RFC 3339 タイムスタンプ形式のタイムスタンプ値が使用されます。

2. 次の復元リソース マニフェストを作成して適用します。

   apiVersion: alloydbomni.dbadmin.goog/v1
   kind: Restore
   metadata:
     name: RESTORE_NAME
     namespace: NAMESPACE
   spec:
     sourceDBCluster: DB_CLUSTER_NAME
     pointInTime: "DATE_AND_TIME_STAMP"
     clonedDBClusterConfig:
       dbclusterName: NEW_DB_CLUSTER_NAME
   

   次のように置き換えます。

   • RESTORE_NAME: このマニフェストが作成するデータ復元リソースで使用する名前（例: restore-1）。

   • DB_CLUSTER_NAME: データベース クラスタの名前。作成時に割り当てた名前です。

   • DATE_AND_TIME_STAMP: 復元元の継続バックアップの分単位の RFC 3339 タイムスタンプ（例: 2024-03-05T15:32:10Z）。

   • NEW_DB_CLUSTER_NAME: 新しいデータベース クラスタの名前。

復元ステータスを表示する

1. 復元オペレーションの進行状況を表示します。

   kubectl get restore.alloydbomni.dbadmin.goog -n NAMESPACE

   NAMESPACE は、データベース クラスタの Namespace に置き換えます。

   コマンドを継続的に実行するには、-Aw フラグを追加します。

   出力は次のようになります。

   NAME        PHASE               COMPLETETIME   RESTOREDPOINTINTIME
   restore-1   RestoreInProgress
   

   出力テーブルの PHASE 列の値が ProvisionSucceeded になったら、復元は完了です。

2. 復元またはクローンを作成したデータベース クラスタがオンラインになるまでの進行状況を確認します。

   kubectl get dbclusters -A -n NAMESPACE

   NAMESPACE は、データベース クラスタの Namespace に置き換えます。

   コマンドを継続的に実行するには、-Aw フラグを追加します。

   出力は次のようになります。

   NAMESPACE   NAME               PRIMARYENDPOINT   PRIMARYPHASE   DBCLUSTERPHASE
   default     db-cluster-1       10.128.0.55       Ready          DBClusterReady
   

   出力テーブルの DBCLUSTERPHASE 列の値が DBClusterReady の場合、復元またはクローンを作成したデータベース クラスタは使用できる状態です。

バックアップを削除する

通常、バックアップを手動で削除する必要はありません。AlloyDB Omni オペレーターは、バックアップ プランの作成時に指定した保持期間より古いバックアップを自動的に削除します。

バックアップを手動で削除する場合は、バックアップが次の要件を満たしている必要があります。

• このバックアップは、バックアップ プランに保存される唯一のバックアップではありません。AlloyDB Omni 演算子では、バックアップ プランごとに少なくとも 1 つのバックアップが存在している必要があります。

• バックアップに依存する他のバックアップがない。たとえば、差分バックアップまたは増分バックアップに依存する完全バックアップ、または差分バックアップに依存する増分バックアップなどです。

バックアップを削除するには、次のコマンドを実行します。

kubectl delete backup.alloydbomni.dbadmin.goog/BACKUP_NAME -n NAMESPACE

次のように置き換えます。

• BACKUP_NAME: 削除するバックアップの名前。

• NAMESPACE: データベース クラスタの Namespace。

バックアップ ディスクのサイズを変更する

Kubernetes クラスタにバックアップを保存するローカル ディスクのサイズを変更するには、次の操作を行います。

1. DBCluster マニフェストの resources.disks フィールドを次のように更新します。

   spec:
     primarySpec:
       resources:
         disks:
           - name: BACKUP_DISK
             size: 10Gi
   

   BACKUP_DISK は、バックアップを保存するディスクの名前に置き換えます。

2. マニフェストを適用して更新を適用します。

   AlloyDB Omni オペレーターは、更新された仕様を DBCluster にすぐに適用します。

実行中のデータベース クラスタのバックアップ ディスクの変更には、次の制限が適用されます。

• ディスクのサイズを増やすことができるのは、指定された storageClass がボリュームの拡張をサポートしている場合のみです。
• ディスクサイズの縮小はできません。

バックアップ プランの更新

すべてのバックアップ プランは Kubernetes リソースです。構成を更新するには、次のいずれかを行います。

• バックアップ プランのマニフェスト ファイルを編集して再適用します。

• kubectl patch コマンドを使用します。

たとえば、実行中のバックアップ プランを一時停止するには、マニフェストの paused 属性を true に変更してから、マニフェストを再適用します。

バックアップ プランの削除

注意: バックアップ プランを削除すると、そのプランに関連付けられているすべてのバックアップが完全に消去されます。

バックアップ プランを削除して、そのバックアップ リソースをすべて削除するには、次のコマンドを実行します。

kubectl delete backupplan.alloydbomni.dbadmin.goog/BACKUP_PLAN_NAME -n NAMESPACE

次のように置き換えます。

• BACKUP_PLAN_NAME: 削除するバックアップ プランの名前。

• NAMESPACE: データベース クラスタの Namespace。

バックアップ プランを削除せずに一時停止するには、バックアップ プランのリソースの paused 属性を true に設定します。一時停止されたバックアップ プランは、バックアップの保存を継続し、手動バックアップの作成を許可します。