4.4. バックアップおよび復元
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 でボリュームの場所を設定する必要があります。
手順
次のコマンドを入力して、
backupStorageLocations
CR を取得します。$ oc get backupStorageLocations
出力例
NAME PHASE LAST VALIDATED AGE DEFAULT velero-sample-1 Available 11s 31m
次の例のように、
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} ペアのマップ。
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.enable
をfalse
に設定して、デフォルトの 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: true
をspec
ブロックに追加します。
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 をインストールしました。
手順
次のように
.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 で名前を指定する必要があります。次の例のような 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>
次の手順を実行して、ボリュームスナップショットをバックアップできます。
バックアップ 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
です。
次のコマンドを入力して、最大 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 ログを参照してください。
次の手順を実行して、ボリュームスナップショットを復元できます。
-
アプリケーションの namespace と、Velero CSI プラグインによって作成された
volumeSnapshotContent
を削除します。 Restore
CR を作成し、restorePVs
をtrue
に設定します。Restore
CR の例apiVersion: velero.io/v1 kind: Restore metadata: name: <restore_name> namespace: <protected_ns> spec: backupName: <previous_backup_name> restorePVs: true
最大 10 分間待機し、次のコマンドを入力して、
VolumeSnapshotRestore
CR ステータスがCompleted
であるかどうかを確認します。$ oc get vsr -n <app_ns>
$ oc get vsr <vsr_name> -n <app_ns> -o jsonpath="{.status.phase}"
アプリケーションデータとリソースが復元されたかどうかを確認します。
注記VolumeSnapshotRestore
CR のステータスが失敗になった場合は、トラブルシューティングのために Velero ログを参照してください。
-
アプリケーションの namespace と、Velero CSI プラグインによって作成された
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>
フォルダーを削除します。 個々のスナップショットを削除するには、以下のようになりました。
-
DPA
.spec.backupLocation.objectStorage.bucket
リソースで指定されている/<protected_namespace>
フォルダーを参照します。 -
/<volumeSnapshotContent name>-pvc
という接頭辞が付いた適切なフォルダーを削除します。ここで、<VolumeSnapshotContent_name>
は、Data Mover によって PVC ごとに作成されたVolumeSnapshotContent
です。
-
DPA
4.4.1.5.2. クラスターリソースの削除
Data Mover は、コンテナーストレージインターフェイス (CSI) ボリュームのスナップショットをリモートオブジェクトストアに正常にバックアップするかどうかに関係なく、クラスターリソースを残す場合があります。
4.4.1.5.2.1. Data Mover を使用したバックアップとリストアが成功した後のクラスターリソースの削除
Data Mover を使用したバックアップとリストアが成功した後、アプリケーションの namespace に残っている VolumeSnapshotBackup
または VolumeSnapshotRestore
CR を削除できます。
手順
Data Mover を使用したバックアップ後に、アプリケーションのnamespace (バックアップおよびリストアするアプリケーション PVC を含む namespace) に残っているクラスターリソースを削除します。
$ oc delete vsb -n <app_namespace> --all
Data Mover を使用するリストア後に残るクラスターリソースを削除します。
$ oc delete vsr -n <app_namespace> --all
必要に応じて、Data Mover を使用するバックアップおよびリストア後に残っている
VolumeSnapshotContent
リソースを削除します。$ oc delete volumesnapshotcontent --all
4.4.1.5.2.2. Data Mover を使用したバックアップとリストアが部分的に成功または失敗した後のクラスターリソースの削除
Data Mover を使用したバックアップおよびリストア操作が失敗するか、部分的にしか成功しない場合は、アプリケーションの namespace に存在する VolumeSnapshotBackup
(VSB) または VolumeSnapshotRestore
カスタムリソース定義 (CRD) をクリーンアップし、このコントローラーによって作成された余分なリソースをクリーンアップする必要があります。
手順
次のコマンドを入力して、Data Mover を使用したバックアップ操作後に残ったクラスターリソースをクリーンアップします。
アプリケーション namespace 上の VSB CRD を削除します。この namespace には、バックアップおよび復元するアプリケーション PVC が含まれています。
$ oc delete vsb -n <app_namespace> --all
VolumeSnapshot
CR を削除します。$ oc delete volumesnapshot -A --all
VolumeSnapshotContent
CR を削除します。$ oc delete volumesnapshotcontent --all
保護された namespace (Operator がインストールされている namespace) 上の PVC をすべて削除します。
$ oc delete pvc -n <protected_namespace> --all
namespace 上の
ReplicationSource
リソースをすべて削除します。$ oc delete replicationsource -n <protected_namespace> --all
次のコマンドを入力して、Data Mover を使用したリストア操作後に残ったクラスターリソースをクリーンアップします。
VSR CRD を削除します。
$ oc delete vsr -n <app-ns> --all
VolumeSnapshot
CR を削除します。$ oc delete volumesnapshot -A --all
VolumeSnapshotContent
CR を削除します。$ oc delete volumesnapshotcontent --all
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
- エラー処理に許可される値は、
Fail
とContinue
です。デフォルトは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
状態である必要があります。
手順
backupStorageLocations
CR を取得します。$ oc get backupStorageLocations
出力例
NAME PHASE LAST VALIDATED AGE DEFAULT velero-sample-1 Available 11s 31m
次の例のように、
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
スケジュールされたバックアップの実行後に、
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) の容量が要求されたサイズと一致するよう、要求されたサイズを調整します。
手順
次の例のように、
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
- オプション: 復元プロセスに含めるリソースの配列を指定します。リソースは、ショートカット (
Pods
はpo
など) または完全修飾の場合があります。指定しない場合、すべてのリソースが含まれます。 - 3
- オプション:
RestorePVs
パラメーターをfalse
に設定すると、コンテナーストレージインターフェイス (CSI) スナップショットのVolumeSnapshot
から、またはVolumeSnaphshotLocation
が設定されている場合はネイティブスナップショットからのPersistentVolumes
の復元をオフにすることができます。
次のコマンドを入力して、
Restore
CR のステータスがCompleted
であることを確認します。$ oc get restore -n openshift-adp <restore> -o jsonpath='{.status.phase}'
次のコマンドを入力して、バックアップリソースが復元されたことを確認します。
$ oc get all -n <namespace> 1
- 1
- バックアップした namespace。
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 CR
のspec.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
になります。
-