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

ドキュメントのバージョンを選択してください。

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

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

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

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

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

  • AlloyDB Omni Operator がバックアップを保存する場所。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。データベース クラスタの 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 Operator がこのバックアップを保持する日数。1～90 の整数を指定する必要があります。デフォルト値は 14 です。

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

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

    • false: AlloyDB Omni Operator は、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。データベース クラスタの 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 Operator がこのバックアップを保持する日数。1～90 の整数を指定する必要があります。デフォルト値は 14 です。

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

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

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

      デフォルト値は false です。

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

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

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

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

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

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

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。データベース クラスタの 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
backup-plan-prod-20231026172643   Succeeded   2023-10-26T17:26:53Z
manual-backup-1                   Succeeded   2023-10-26T18:15:27Z
manual-backup-2                   InProgress

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

  • バックアップの名前。
  • バックアップの状態。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 Operator を使用すると、復元期間内の任意の時点からクラスタのデータをクローニングできます。復元期間の長さは、そのまま保持期間によって決まります。

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

  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 Operator は、バックアップ プランの作成時に指定した保持期間より古いバックアップを自動的に削除します。

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

  • そのバックアップが、バックアップ プランに保存されている唯一のバックアップではないこと。AlloyDB Omni Operator では、バックアップ プランごとに少なくとも 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 Operator は、更新された仕様を 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 に設定します。バックアップ プランを一時停止しても、バックアップは引き続き保存されます。また、手動バックアップの作成は可能です。