4.6. OADP のバックアップ
4.6.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.6.1.1. 既知の問題
OpenShift Container Platform 4.14 は、Restic 復元プロセス中に Pod の readiness を妨げる可能性がある Pod セキュリティーアドミッション (PSA) ポリシーを強制します。
この問題は OADP 1.1.6 および OADP 1.2.2 リリースで解決されており、これらのリリースにアップグレードすることが推奨されます。
4.6.2. バックアップ 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 -n openshift-adp
出力例
NAMESPACE NAME PHASE LAST VALIDATED AGE DEFAULT openshift-adp 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.6.3. CSI スナップショットを使用した永続ボリュームのバックアップ
Backup
CR を作成する前に、クラウドストレージの VolumeSnapshotClass
カスタムリソース (CR) を編集して、Container Storage Interface (CSI) スナップショットを使用して永続ボリュームをバックアップします。CSI ボリュームスナップショット を参照してください。
詳細は、バックアップ CR の作成 を参照してください。
前提条件
- クラウドプロバイダーは、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.6.4. Restic を使用したアプリケーションのバックアップ
クラウドプロバイダーがスナップショットをサポートしていない場合、またはアプリケーションが NFS データボリューム上にある場合は、Restic を使用してバックアップを作成できます。
Restic は、デフォルトで OADP Operator によってインストールされます。
Restic と OADP の統合により、ほぼすべてのタイプの Kubernetes ボリュームをバックアップおよび復元するためのソリューションが提供されます。この統合は、OADP 機能への追加であり、既存の機能を置き換えるものではありません。
Backup
カスタムリソース (CR) を編集して、Restic を使用して Kubernetes リソース、内部イメージ、および永続ボリュームをバックアップします。
DataProtectionApplication
CR でスナップショットの場所を指定する必要はありません。
Restic は、hostPath
ボリュームのバックアップをサポートしません。詳細は、追加の Restic 制限事項 を参照してください。
前提条件
- 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.6.5. バックアップフックの作成
バックアップを実行する際に、バックアップされる Pod に基づいて、Pod 内のコンテナーで実行するコマンドを 1 つ以上指定できます。
コマンドは、カスタムアクション処理の前 (プリ フック)、またはすべてのカスタムアクションが完了し、カスタムアクションで指定された追加アイテムがバックアップされた後に実行するように設定できます。
ポスト フックはバックアップ後に実行します。
Backup
カスタムリソース (CR) を編集して、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.6.6. スケジュール CR を使用したバックアップのスケジュール設定
スケジュール操作では、Cron 式で定義された指定時刻にデータのバックアップを作成できます。
Backup
CR の代わりに Schedule
カスタムリソース (CR) を作成して、バックアップをスケジュールします。
バックアップスケジュールでは、別のバックアップが作成される前にバックアップを数量するための時間を十分確保してください。
たとえば、namespace のバックアップに通常 10 分かかる場合は、15 分ごとよりも頻繁にバックアップをスケジュールしないでください。
前提条件
- OpenShift API for Data Protection (OADP) Operator をインストールしている。
-
DataProtectionApplication
CR がReady
状態である。
手順
backupStorageLocations
CR を取得します。$ oc get backupStorageLocations -n openshift-adp
出力例
NAMESPACE NAME PHASE LAST VALIDATED AGE DEFAULT openshift-adp 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.6.7. バックアップの削除
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.6.8. Kopia について
Kopia は、高速かつセキュアなオープンソースのバックアップおよび復元ツールです。これを使用して、データの暗号化されたスナップショットを作成し、そのスナップショットを選択したリモートストレージまたはクラウドストレージに保存できます。
Kopia は、ネットワークおよびローカルストレージの場所、および多くのクラウドまたはリモートストレージの場所をサポートしています。以下はその一部です。
- Amazon S3 および S3 と互換性のあるクラウドストレージ
- Azure Blob Storage
- Google Cloud Storage プラットフォーム
Kopia は、スナップショットにコンテンツアドレスを指定できるストレージを使用します。
- 各スナップショットは、必ず累積されます。つまり、ファイルの内容に基づいて、すべてのデータがリポジトリーに一度アップロードされます。リポジトリーに再度アップロードされるのは、ファイルが変更されたときだけです。
- 同じファイルの複数のコピーが 1 回保存されるため、重複が排除されます。大きなファイルを移動した後、またはその名前を変更した後、Kopia はファイルのコンテンツが同じであることを認識し、再度アップロードしません。
4.6.8.1. OADP と Kopia の統合
OADP 1.3 は、Pod ボリュームバックアップのバックアップメカニズムとして、Restic に加えて Kopia をサポートします。インストール時に、DataProtectionApplication
カスタムリソース (CR) の uploaderType
フィールドを設定して、どちらかを選択する必要があります。使用できる値は、restic
または kopia
です。uploaderType
を指定しない場合、OADP 1.3 はデフォルトで Kopia をバックアップメカニズムとして使用します。データは統合リポジトリーに書き込まれ、統合リポジトリーから読み取られます。
Kopia の DataProtectionApplication
設定
apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: dpa-sample spec: configuration: nodeAgent: enable: true uploaderType: kopia # ...