検索

4.4. バックアップおよび復元

download PDF

4.4.1. アプリケーションのバックアップ

Backup カスタムリソース (CR) を作成して、アプリケーションをバックアップします。バックアップ CR の作成 を参照してください。

Backup CR は、Kubernetes リソースや内部イメージのバックアップファイルを S3 オブジェクトストレージ上に作成し、クラウドプロバイダーが OpenShift Data Foundation 4 のようにスナップショットを作成するためにネイティブスナップショット API や Container Storage Interface (CSI) を使用している場合は、永続ボリューム (PV) のスナップショットを作成します。

CSI ボリュームスナップショットの詳細は、CSI ボリュームスナップショット を参照してください。

重要

S3 ストレージ用の CloudStorage API は、テクノロジープレビュー機能のみです。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

  • クラウドプロバイダーがネイティブスナップショット API を備えている場合、または CSI スナップショットをサポートしている場合、Backup CR はスナップショットを作成することによって永続ボリューム (PV) をバックアップします。CSI スナップショットの操作の詳細は、CSI スナップショットを使用した永続ボリュームのバックアップ を参照してください。
  • クラウドプロバイダーがスナップショットをサポートしていない場合、またはアプリケーションが NFS データボリューム上にある場合は、Restic を使用してバックアップを作成できます。Restic を使用したアプリケーションのバックアップ を参照してください。
重要

OpenShift API for Data Protection (OADP) は、他のソフトウェアで作成されたボリュームスナップショットのバックアップをサポートしていません。

バックアップ操作の前または後にコマンドを実行するためのバックアップフックを作成できます。バックアップフックの作成 を参照してください。

Backup CR の代わりに Schedule CR を作成することにより、バックアップをスケジュールできます。バックアップのスケジュール設定 を参照してください。

4.4.1.1. バックアップ CR の作成

Backup カスタムリソース (CR) を作成して、Kubernetes イメージ、内部イメージ、および永続ボリューム (PV) をバックアップします。

前提条件

  • OpenShift API for Data Protection (OADP) Operator をインストールする必要があります。
  • DataProtectionApplication CR は Ready 状態である必要があります。
  • バックアップ場所の前提条件:

    • Velero 用に S3 オブジェクトストレージを設定する必要があります。
    • DataProtectionApplication CR でバックアップの場所を設定する必要があります。
  • スナップショットの場所の前提条件:

    • クラウドプロバイダーには、ネイティブスナップショット API が必要であるか、Container Storage Interface (CSI) スナップショットをサポートしている必要があります。
    • CSI スナップショットの場合、CSI ドライバーを登録するために VolumeSnapshotClass CR を作成する必要があります。
    • DataProtectionApplication CR でボリュームの場所を設定する必要があります。

手順

  1. 次のコマンドを入力して、backupStorageLocations CR を取得します。

    $ oc get backupStorageLocations

    出力例

    NAME              PHASE       LAST VALIDATED   AGE   DEFAULT
    velero-sample-1   Available   11s              31m

  2. 次の例のように、Backup CR を作成します。

    apiVersion: velero.io/v1
    kind: Backup
    metadata:
      name: <backup>
      labels:
        velero.io/storage-location: default
      namespace: openshift-adp
    spec:
      hooks: {}
      includedNamespaces:
      - <namespace> 1
      includedResources: [] 2
      excludedResources: [] 3
      storageLocation: <velero-sample-1> 4
      ttl: 720h0m0s
      labelSelector: 5
        matchLabels:
          app=<label_1>
          app=<label_2>
          app=<label_3>
      orLabelSelectors: 6
      - matchLabels:
          app=<label_1>
          app=<label_2>
          app=<label_3>
    1
    バックアップする namespace の配列を指定します。
    2
    オプション: バックアップに含めるリソースの配列を指定します。リソースは、ショートカット (Pods は po など) または完全修飾の場合があります。指定しない場合、すべてのリソースが含まれます。
    3
    オプション: バックアップから除外するリソースの配列を指定します。リソースは、ショートカット (Pods は po など) または完全修飾の場合があります。
    4
    backupStorageLocations CR の名前を指定します。
    5
    指定したラベルを すべて 持つバックアップリソースの {key,value} ペアのマップ。
    6
    指定したラベルを 1 つ以上 持つバックアップリソースの {key,value} ペアのマップ。
  3. Backup CR のステータスが Completed したことを確認します。

    $ oc get backup -n openshift-adp <backup> -o jsonpath='{.status.phase}'

4.4.1.2. CSI スナップショットを使用した永続ボリュームのバックアップ

Backup CR を作成する前に、クラウドストレージの VolumeSnapshotClass カスタムリソース (CR) を編集して、Container Storage Interface (CSI) スナップショットを使用して永続ボリュームをバックアップします。

前提条件

  • クラウドプロバイダーは、CSI スナップショットをサポートする必要があります。
  • DataProtectionApplication CR で CSI を有効にする必要があります。

手順

  • metadata.labels.velero.io/csi-volumesnapshot-class: "true" のキー: 値ペアを VolumeSnapshotClass CR に追加します。

    apiVersion: snapshot.storage.k8s.io/v1
    kind: VolumeSnapshotClass
    metadata:
      name: <volume_snapshot_class_name>
      labels:
        velero.io/csi-volumesnapshot-class: "true"
    driver: <csi_driver>
    deletionPolicy: Retain

これで、Backup CR を作成できます。

4.4.1.3. Restic を使用したアプリケーションのバックアップ

Backup カスタムリソース (CR) を編集して、Restic を使用して Kubernetes リソース、内部イメージ、および永続ボリュームをバックアップします。

DataProtectionApplication CR でスナップショットの場所を指定する必要はありません。

重要

Restic は、hostPath ボリュームのバックアップをサポートしません。詳細は、additional Rustic limitations を参照してください。

前提条件

  • OpenShift API for Data Protection (OADP) Operator をインストールする必要があります。
  • DataProtectionApplication CR で spec.configuration.restic.enablefalse に設定して、デフォルトの Restic インストールを無効にしないでください。
  • DataProtectionApplication CR は Ready 状態である必要があります。

手順

  • 次の例のように、Backup CR を編集します。

    apiVersion: velero.io/v1
    kind: Backup
    metadata:
      name: <backup>
      labels:
        velero.io/storage-location: default
      namespace: openshift-adp
    spec:
      defaultVolumesToRestic: true 1
    ...
    1
    defaultVolumesToRestic: truespec ブロックに追加します。

4.4.1.4. CSI スナップショットに Data Mover を使用する

重要

CSI スナップショット用の Data Mover は、テクノロジープレビュー機能のみです。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

OADP 1.1.0 Data Mover を使用すると、顧客は Container Storage Interface (CSI) ボリュームスナップショットをリモートオブジェクトストアにバックアップできます。Data Mover が有効になっていると、クラスターの障害、誤った削除、または破損が発生した場合に、ストアからステートフルアプリケーションを復元できます。OADP 1.1.0 Data Mover ソリューションは、VolSync の Restic オプションを使用します。

注記

Data Mover は、CSI ボリュームスナップショットのバックアップとリストアのみをサポートします。

現在、Data Mover は Google Cloud Storage (GCS) バケットをサポートしていません。

前提条件

  • StorageClass および VolumeSnapshotClass カスタムリソース (CR) が CSI をサポートしていることを確認しました。
  • 注釈 snapshot.storage.kubernetes.io/is-default-class: true を持つ volumeSnapshotClass CR が 1 つだけであることを確認しました。
  • 注釈 storageclass.kubernetes.io/is-default-class: true を持つ storageClass CR が 1 つだけであることを確認しました。
  • VolumeSnapshotClass CR にラベル velero.io/csi-volumesnapshot-class: 'true' を含めました。
  • Operator Lifecycle Manager (OLM) を使用して VolSync Operator をインストールしました。

    注記

    VolSync Operator は、テクノロジープレビューのデータ Mover との使用にのみ必要です。Operator は、OADP プロダクション機能を使用するために必要ではありません。

  • OLM を使用して OADP Operator をインストールしました。

手順

  1. 次のように .yaml ファイルを作成して、Restic シークレットを設定します。

    apiVersion: v1
    kind: Secret
    metadata:
      name: <secret_name>
      namespace: openshift-adp
    type: Opaque
    stringData:
      RESTIC_PASSWORD: <secure_restic_password>
    注記

    デフォルトでは、Operator は dm-credential という名前のシークレットを探します。別の名前を使用している場合は、dpa.spec.features.dataMover.credentialName を使用して、データ保護アプリケーション (DPA) CR で名前を指定する必要があります。

  2. 次の例のような DPA CR を作成します。デフォルトのプラグインには CSI が含まれています。

    データ保護アプリケーション (DPA) CR の例

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: velero-sample
      namespace: openshift-adp
    spec:
      features:
        dataMover:
          enable: true
          credentialName: <secret_name> 1
      backupLocations:
        - velero:
            config:
              profile: default
              region: us-east-1
            credential:
              key: cloud
              name: cloud-credentials
            default: true
            objectStorage:
              bucket: <bucket_name>
              prefix: <bucket_prefix>
            provider: aws
      configuration:
        restic:
          enable: <true_or_false>
        velero:
          defaultPlugins:
            - openshift
            - aws
            - csi

    1
    前のステップの Restic シークレット名を追加します。これが行われない場合、デフォルトのシークレット名 dm-credential が使用されます。

    OADP Operator は、2 つのカスタムリソース定義 (CRD)、VolumeSnapshotBackup および VolumeSnapshotRestore をインストールします。

    VolumeSnapshotBackup CRD の例

    apiVersion: datamover.oadp.openshift.io/v1alpha1
    kind: VolumeSnapshotBackup
    metadata:
      name: <vsb_name>
      namespace: <namespace_name> 1
    spec:
      volumeSnapshotContent:
        name: <snapcontent_name>
      protectedNamespace: <adp_namespace>
      resticSecretRef:
        name: <restic_secret_name>

    1
    ボリュームスナップショットが存在する namespace を指定します。

    VolumeSnapshotRestore CRD の例

    apiVersion: datamover.oadp.openshift.io/v1alpha1
    kind: VolumeSnapshotRestore
    metadata:
      name: <vsr_name>
      namespace: <namespace_name> 1
    spec:
      protectedNamespace: <protected_ns> 2
      resticSecretRef:
        name: <restic_secret_name>
      volumeSnapshotMoverBackupRef:
        sourcePVCData:
          name: <source_pvc_name>
          size: <source_pvc_size>
        resticrepository: <your_restic_repo>
        volumeSnapshotClassName: <vsclass_name>

    1
    ボリュームスナップショットが存在する namespace を指定します。
    2
    Operator がインストールされている namespace を指定します。デフォルトは openshift-adp です。
  3. 次の手順を実行して、ボリュームスナップショットをバックアップできます。

    1. バックアップ CR を作成します。

      apiVersion: velero.io/v1
      kind: Backup
      metadata:
        name: <backup_name>
        namespace: <protected_ns> 1
      spec:
        includedNamespaces:
        - <app_ns>
        storageLocation: velero-sample-1
      1
      Operator がインストールされている namespace を指定します。デフォルトの namespace は openshift-adp です。
    2. 次のコマンドを入力して、最大 10 分待機し、VolumeSnapshotBackup CR のステータスが Completed かどうかを確認します。

      $ oc get vsb -n <app_ns>
      $ oc get vsb <vsb_name> -n <app_ns> -o jsonpath="{.status.phase}"

      DPA で設定されたオブジェクトストアにスナップショットが作成されます。

      注記

      VolumeSnapshotBackup CR のステータスが Failed になった場合は、トラブルシューティングのために Velero ログを参照してください。

  4. 次の手順を実行して、ボリュームスナップショットを復元できます。

    1. アプリケーションの namespace と、Velero CSI プラグインによって作成された volumeSnapshotContent を削除します。
    2. Restore CR を作成し、restorePVstrue に設定します。

      Restore CR の例

      apiVersion: velero.io/v1
      kind: Restore
      metadata:
        name: <restore_name>
        namespace: <protected_ns>
      spec:
        backupName: <previous_backup_name>
        restorePVs: true

    3. 最大 10 分間待機し、次のコマンドを入力して、VolumeSnapshotRestore CR ステータスが Completed であるかどうかを確認します。

      $ oc get vsr -n <app_ns>
      $ oc get vsr <vsr_name> -n <app_ns> -o jsonpath="{.status.phase}"
    4. アプリケーションデータとリソースが復元されたかどうかを確認します。

      注記

      VolumeSnapshotRestore CR のステータスが失敗になった場合は、トラブルシューティングのために Velero ログを参照してください。

4.4.1.5. Data Mover と OADP 1.1 を使用したバックアップ後のクリーンアップ。

OADP 1.1 の場合、Data Mover のいずれかのバージョンを使用してバックアップを実行した後、データクリーンアップを実行する必要があります。

クリーンアップには、次のリソースの削除が含まれます。

  • バケット内のスナップショット
  • クラスターリソース
  • スケジュールに従って実行されるか、繰り返し実行されるバックアップ手順の後のボリュームスナップショットバックアップ (VSB)
4.4.1.5.1. バケット内のスナップショットの削除

Data Mover は、バックアップ後に 1 つ以上のスナップショットをバケットに残す場合があります。すべてのスナップショットを削除することも、個々のスナップショットを削除することもできます。

手順

  • バケット内のすべてのスナップショットを削除するには、データ保護アプリケーション (DPA) の .spec.backupLocation.objectStorage.bucket リソースで指定されている /<protected_namespace> フォルダーを削除します。
  • 個々のスナップショットを削除するには、以下のようになりました。

    1. DPA .spec.backupLocation.objectStorage.bucket リソースで指定されている /<protected_namespace> フォルダーを参照します。
    2. /<volumeSnapshotContent name>-pvc という接頭辞が付いた適切なフォルダーを削除します。ここで、<VolumeSnapshotContent_name> は、Data Mover によって PVC ごとに作成された VolumeSnapshotContent です。
4.4.1.5.2. クラスターリソースの削除

Data Mover は、コンテナーストレージインターフェイス (CSI) ボリュームのスナップショットをリモートオブジェクトストアに正常にバックアップするかどうかに関係なく、クラスターリソースを残す場合があります。

4.4.1.5.2.1. Data Mover を使用したバックアップとリストアが成功した後のクラスターリソースの削除

Data Mover を使用したバックアップとリストアが成功した後、アプリケーションの namespace に残っている VolumeSnapshotBackup または VolumeSnapshotRestore CR を削除できます。

手順

  1. Data Mover を使用したバックアップ後に、アプリケーションのnamespace (バックアップおよびリストアするアプリケーション PVC を含む namespace) に残っているクラスターリソースを削除します。

    $ oc delete vsb -n <app_namespace> --all
  2. Data Mover を使用するリストア後に残るクラスターリソースを削除します。

    $ oc delete vsr -n <app_namespace> --all
  3. 必要に応じて、Data Mover を使用するバックアップおよびリストア後に残っている VolumeSnapshotContent リソースを削除します。

    $ oc delete volumesnapshotcontent --all
4.4.1.5.2.2. Data Mover を使用したバックアップとリストアが部分的に成功または失敗した後のクラスターリソースの削除

Data Mover を使用したバックアップおよびリストア操作が失敗するか、部分的にしか成功しない場合は、アプリケーションの namespace に存在する VolumeSnapshotBackup (VSB) または VolumeSnapshotRestore カスタムリソース定義 (CRD) をクリーンアップし、このコントローラーによって作成された余分なリソースをクリーンアップする必要があります。

手順

  1. 次のコマンドを入力して、Data Mover を使用したバックアップ操作後に残ったクラスターリソースをクリーンアップします。

    1. アプリケーション namespace 上の VSB CRD を削除します。この namespace には、バックアップおよび復元するアプリケーション PVC が含まれています。

      $ oc delete vsb -n <app_namespace> --all
    2. VolumeSnapshot CR を削除します。

      $ oc delete volumesnapshot -A --all
    3. VolumeSnapshotContent CR を削除します。

      $ oc delete volumesnapshotcontent --all
    4. 保護された namespace (Operator がインストールされている namespace) 上の PVC をすべて削除します。

      $ oc delete pvc -n <protected_namespace> --all
    5. namespace 上の ReplicationSource リソースをすべて削除します。

      $ oc delete replicationsource -n <protected_namespace> --all
  2. 次のコマンドを入力して、Data Mover を使用したリストア操作後に残ったクラスターリソースをクリーンアップします。

    1. VSR CRD を削除します。

      $ oc delete vsr -n <app-ns> --all
    2. VolumeSnapshot CR を削除します。

      $ oc delete volumesnapshot -A --all
    3. VolumeSnapshotContent CR を削除します。

      $ oc delete volumesnapshotcontent --all
    4. namespace 上の ReplicationDestination リソースをすべて削除します。

      $ oc delete replicationdestination -n <protected_namespace> --all

4.4.1.6. バックアップフックの作成

Backup カスタムリソース (CR) を編集して、Pod 内のコンテナーでコマンドを実行するためのバックアップフックを作成します。

プレ フックは、Pod のバックアップが作成される前に実行します。ポスト フックはバックアップ後に実行します。

手順

  • 次の例のように、Backup CR の spec.hooks ブロックにフックを追加します。

    apiVersion: velero.io/v1
    kind: Backup
    metadata:
      name: <backup>
      namespace: openshift-adp
    spec:
      hooks:
        resources:
          - name: <hook_name>
            includedNamespaces:
            - <namespace> 1
            excludedNamespaces: 2
            - <namespace>
            includedResources: []
            - pods 3
            excludedResources: [] 4
            labelSelector: 5
              matchLabels:
                app: velero
                component: server
            pre: 6
              - exec:
                  container: <container> 7
                  command:
                  - /bin/uname 8
                  - -a
                  onError: Fail 9
                  timeout: 30s 10
            post: 11
    ...
    1
    オプション: フックが適用される namespace を指定できます。この値が指定されていない場合、フックはすべてのネームスペースに適用されます。
    2
    オプション: フックが適用されない namespace を指定できます。
    3
    現在、Pod は、フックを適用できる唯一のサポート対象リソースです。
    4
    オプション: フックが適用されないリソースを指定できます。
    5
    オプション: このフックは、ラベルに一致するオブジェクトにのみ適用されます。この値が指定されていない場合、フックはすべてのネームスペースに適用されます。
    6
    バックアップの前に実行するフックの配列。
    7
    オプション: コンテナーが指定されていない場合、コマンドは Pod の最初のコンテナーで実行されます。
    8
    これは、追加される init コンテナーのエントリーポイントです。
    9
    エラー処理に許可される値は、FailContinue です。デフォルトは Fail です。
    10
    オプション: コマンドの実行を待機する時間。デフォルトは 30s です。
    11
    このブロックでは、バックアップ後に実行するフックの配列を、バックアップ前のフックと同じパラメーターで定義します。

4.4.1.7. バックアップのスケジュール

Backup CR の代わりに Schedule カスタムリソース (CR) を作成して、バックアップをスケジュールします。

警告

バックアップスケジュールでは、別のバックアップが作成される前にバックアップを数量するための時間を十分確保してください。

たとえば、namespace のバックアップに通常 10 分かかる場合は、15 分ごとよりも頻繁にバックアップをスケジュールしないでください。

前提条件

  • OpenShift API for Data Protection (OADP) Operator をインストールする必要があります。
  • DataProtectionApplication CR は Ready 状態である必要があります。

手順

  1. backupStorageLocations CR を取得します。

    $ oc get backupStorageLocations

    出力例

    NAME              PHASE       LAST VALIDATED   AGE   DEFAULT
    velero-sample-1   Available   11s              31m

  2. 次の例のように、Schedule CR を作成します。

    $ cat << EOF | oc apply -f -
    apiVersion: velero.io/v1
    kind: Schedule
    metadata:
      name: <schedule>
      namespace: openshift-adp
    spec:
      schedule: 0 7 * * * 1
      template:
        hooks: {}
        includedNamespaces:
        - <namespace> 2
        storageLocation: <velero-sample-1> 3
        defaultVolumesToRestic: true 4
        ttl: 720h0m0s
    EOF
    1
    バックアップをスケジュールするための cron 式。たとえば、毎日 7:00 にバックアップを実行する場合は 0 7 * * * です。
    2
    バックアップを作成する namespace の配列。
    3
    backupStorageLocations CR の名前。
    4
    オプション: Restic を使用してボリュームをバックアップする場合は、キーと値のペア defaultVolumesToRestic: true を追加します。
  3. スケジュールされたバックアップの実行後に、Schedule CR のステータスが Completed となっていることを確認します。

    $ oc get schedule -n openshift-adp <schedule> -o jsonpath='{.status.phase}'

4.4.1.8. バックアップの削除

Backup カスタムリソース (CR) を削除することで、バックアップファイルを削除できます。

警告

Backup CR および関連するオブジェクトストレージデータを削除した後、削除したデータを復元することはできません。

前提条件

  • Backup CR を作成した。
  • Backup CR の名前とそれを含む namespace がわかっている。
  • Velero CLI ツールをダウンロードした。
  • クラスター内の Velero バイナリーにアクセスできる。

手順

  • 次のいずれかのアクションを選択して、Backup CR を削除します。

    • Backup CR を削除し、関連するオブジェクトストレージデータを保持する場合は、次のコマンドを実行します。

      $ oc delete backup <backup_CR_name> -n <velero_namespace>
    • Backup CR を削除し、関連するオブジェクトストレージデータを削除する場合は、次のコマンドを実行します。

      $ velero backup delete <backup_CR_name> -n <velero_namespace>

      ここでは、以下のようになります。

      <backup_CR_name>
      Backup カスタムリソースの名前を指定します。
      <velero_namespace>
      Backup カスタムリソースを含む namespace を指定します。

4.4.2. アプリケーションの復元

アプリケーションのバックアップを復元するには、Restore カスタムリソース (CR) を作成します。復元 CR の作成 を参照してください。

Restore (CR) を編集することでアプリケーションを復元する際に、Pod 内のコンテナーでコマンドを実行するための復元フックを作成できます。復元フックの作成 を参照してください。

4.4.2.1. 復元 CR の作成

Restore CR を作成して、Backup カスタムリソース (CR) を復元します。

前提条件

  • OpenShift API for Data Protection (OADP) Operator をインストールする必要があります。
  • DataProtectionApplication CR は Ready 状態である必要があります。
  • Velero Backup CR が必要です。
  • バックアップ時に永続ボリューム (PV) の容量が要求されたサイズと一致するよう、要求されたサイズを調整します。

手順

  1. 次の例のように、Restore CR を作成します。

    apiVersion: velero.io/v1
    kind: Restore
    metadata:
      name: <restore>
      namespace: openshift-adp
    spec:
      backupName: <backup> 1
      includedResources: [] 2
      excludedResources:
      - nodes
      - events
      - events.events.k8s.io
      - backups.velero.io
      - restores.velero.io
      - resticrepositories.velero.io
      restorePVs: true 3
    1
    Backup CR の名前
    2
    オプション: 復元プロセスに含めるリソースの配列を指定します。リソースは、ショートカット (Podspo など) または完全修飾の場合があります。指定しない場合、すべてのリソースが含まれます。
    3
    オプション: RestorePVs パラメーターを false に設定すると、コンテナーストレージインターフェイス (CSI) スナップショットの VolumeSnapshot から、または VolumeSnaphshotLocation が設定されている場合はネイティブスナップショットからの PersistentVolumes の復元をオフにすることができます。
  2. 次のコマンドを入力して、Restore CR のステータスが Completed であることを確認します。

    $ oc get restore -n openshift-adp <restore> -o jsonpath='{.status.phase}'
  3. 次のコマンドを入力して、バックアップリソースが復元されたことを確認します。

    $ oc get all -n <namespace> 1
    1
    バックアップした namespace。
  4. Restic を使用して DeploymentConfig オブジェクトを復元する場合、または復元後のフックを使用する場合は、次のコマンドを入力して dc-restic-post-restore.sh クリーンアップスクリプトを実行します。

    $ bash dc-restic-post-restore.sh <restore-name>
    注記

    復元プロセスの過程で、OADP Velero プラグインは、DeploymentConfig オブジェクトをスケールダウンし、Pod をスタンドアロン Pod として復元して、クラスターが復元された DeploymentConfig Pod を復元時にすぐに削除しないようにし、Restic および復元後のフックを完了できるようにします。復元された Pod でのアクション。クリーンアップスクリプトは、これらの切断された Pod を削除し、DeploymentConfig オブジェクトを適切な数のレプリカに戻します。

    例4.1 dc-restic-post-restore.sh クリーンアップスクリプト

    #!/bin/bash
    set -e
    
    # if sha256sum exists, use it to check the integrity of the file
    if command -v sha256sum >/dev/null 2>&1; then
      CHECKSUM_CMD="sha256sum"
    else
      CHECKSUM_CMD="shasum -a 256"
    fi
    
    label_name () {
        if [ "${#1}" -le "63" ]; then
    	echo $1
    	return
        fi
        sha=$(echo -n $1|$CHECKSUM_CMD)
        echo "${1:0:57}${sha:0:6}"
    }
    
    OADP_NAMESPACE=${OADP_NAMESPACE:=openshift-adp}
    
    if [[ $# -ne 1 ]]; then
        echo "usage: ${BASH_SOURCE} restore-name"
        exit 1
    fi
    
    echo using OADP Namespace $OADP_NAMESPACE
    echo restore: $1
    
    label=$(label_name $1)
    echo label: $label
    
    echo Deleting disconnected restore pods
    oc delete pods -l oadp.openshift.io/disconnected-from-dc=$label
    
    for dc in $(oc get dc --all-namespaces -l oadp.openshift.io/replicas-modified=$label -o jsonpath='{range .items[*]}{.metadata.namespace}{","}{.metadata.name}{","}{.metadata.annotations.oadp\.openshift\.io/original-replicas}{","}{.metadata.annotations.oadp\.openshift\.io/original-paused}{"\n"}')
    do
        IFS=',' read -ra dc_arr <<< "$dc"
        if [ ${#dc_arr[0]} -gt 0 ]; then
    	echo Found deployment ${dc_arr[0]}/${dc_arr[1]}, setting replicas: ${dc_arr[2]}, paused: ${dc_arr[3]}
    	cat <<EOF | oc patch dc  -n ${dc_arr[0]} ${dc_arr[1]} --patch-file /dev/stdin
    spec:
      replicas: ${dc_arr[2]}
      paused: ${dc_arr[3]}
    EOF
        fi
    done

4.4.2.2. 復元フックの作成

Restore カスタムリソース (CR) を編集して、アプリケーションの復元中に Pod 内のコンテナーでコマンドを実行する復元フックを作成します。

2 種類の復元フックを作成できます。

  • init フックは、init コンテナーを Pod に追加して、アプリケーションコンテナーが起動する前にセットアップタスクを実行します。

    Restic バックアップを復元する場合は、復元フック init コンテナーの前に restic-wait init コンテナーが追加されます。

  • exec フックは、復元された Pod のコンテナーでコマンドまたはスクリプトを実行します。

手順

  • 次の例のように、Restore CRspec.hooks ブロックにフックを追加します。

    apiVersion: velero.io/v1
    kind: Restore
    metadata:
      name: <restore>
      namespace: openshift-adp
    spec:
      hooks:
        resources:
          - name: <hook_name>
            includedNamespaces:
            - <namespace> 1
            excludedNamespaces:
            - <namespace>
            includedResources:
            - pods 2
            excludedResources: []
            labelSelector: 3
              matchLabels:
                app: velero
                component: server
            postHooks:
            - init:
                initContainers:
                - name: restore-hook-init
                  image: alpine:latest
                  volumeMounts:
                  - mountPath: /restores/pvc1-vm
                    name: pvc1-vm
                  command:
                  - /bin/ash
                  - -c
                timeout: 4
            - exec:
                container: <container> 5
                command:
                - /bin/bash 6
                - -c
                - "psql < /backup/backup.sql"
                waitTimeout: 5m 7
                execTimeout: 1m 8
                onError: Continue 9
    1
    オプション: フックが適用される namespace の配列。この値が指定されていない場合、フックはすべてのネームスペースに適用されます。
    2
    現在、Pod は、フックを適用できる唯一のサポート対象リソースです。
    3
    オプション: このフックは、ラベルセレクターに一致するオブジェクトにのみ適用されます。
    4
    オプション: Timeout は、initContainers が完了するまで Velero が待機する最大時間を指定します。
    5
    オプション: コンテナーが指定されていない場合、コマンドは Pod の最初のコンテナーで実行されます。
    6
    これは、追加される init コンテナーのエントリーポイントです。
    7
    オプション: コンテナーの準備が整うまでの待機時間。これは、コンテナーが起動して同じコンテナー内の先行するフックが完了するのに十分な長さである必要があります。設定されていない場合、復元プロセスの待機時間は無期限になります。
    8
    オプション: コマンドの実行を待機する時間。デフォルトは 30s です。
    9
    エラー処理に許可される値は、Fail および Continue です。
    • Continue: コマンドの失敗のみがログに記録されます。
    • Fail: Pod 内のコンテナーで復元フックが実行されなくなりました。Restore CR のステータスは PartiallyFailed になります。
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.