4.17. OADP のバックアップ
4.17.1. アプリケーションのバックアップ リンクのコピーリンクがクリップボードにコピーされました!
頻繁にバックアップを行うと、Backup Storage Location のストレージが消費される可能性があります。S3 バケットなどの非ローカルバックアップを使用する場合は、バックアップの頻度、保持期間、永続ボリューム (PV) のデータ量を確認してください。取得したバックアップはすべて期限が切れるまで残るため、スケジュールの有効期限 (TTL) 設定も確認してください。
Backup カスタムリソース (CR) を作成することで、アプリケーションをバックアップできます。詳細は、バックアップ CR の作成 を参照してください。
-
BackupCR は、Kubernetes リソースと内部イメージのバックアップファイルを S3 オブジェクトストレージに作成します。 -
クラウドプロバイダーがネイティブスナップショット API を備えている場合、または CSI スナップショットをサポートしている場合、
BackupCR はスナップショットを作成することによって永続ボリューム (PV) をバックアップします。CSI スナップショットの操作の詳細は、CSI スナップショットを使用した永続ボリュームのバックアップ を参照してください。
CSI ボリュームスナップショットの詳細は、CSI ボリュームスナップショット を参照してください。
オブジェクトストレージのバケット作成を自動化する CloudStorage API は、テクノロジープレビュー機能のみです。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
CloudStorage API は、CloudStorage オブジェクトを使用しており、OADP で CloudStorage API を使用して BackupStorageLocation として使用する S3 バケットを自動的に作成するためのテクノロジープレビュー機能です。
CloudStorage API は、既存の S3 バケットを指定して BackupStorageLocation オブジェクトを手動作成することをサポートしています。現在、S3 バケットを自動的に作成する CloudStorage API は、AWS S3 ストレージに対してのみ有効です。
- クラウドプロバイダーがスナップショットをサポートしていない場合、またはアプリケーションが NFS データボリューム上にある場合は、Kopia または Restic を使用してバックアップを作成できます。File System Backup を使用してアプリケーションをバックアップする: Kopia または Restic を参照してください。
…/.snapshot: read-only file system エラーで失敗する
…/.snapshot ディレクトリーは、複数の NFS サーバーによって使用されるスナップショットコピーディレクトリーです。このディレクトリーにはデフォルトで読み取り専用アクセスが設定されているため、Velero はこのディレクトリーに復元できません。
Velero に .snapshot ディレクトリーへの書き込みアクセス権を付与しないでください。また、このディレクトリーへのクライアントアクセスを無効にしてください。
OpenShift API for Data Protection (OADP) は、他のソフトウェアで作成されたボリュームスナップショットのバックアップをサポートしていません。
4.17.1.1. バックアップと復元を実行する前にリソースをプレビューする リンクのコピーリンクがクリップボードにコピーされました!
OADP は、タイプ、namespace、またはラベルに基づいてアプリケーションリソースをバックアップします。そのため、バックアップが完了した後にリソースを確認できます。同様に、復元操作が完了した後も、namespace、永続ボリューム (PV)、またはラベルに基づいて、復元されたオブジェクトを確認できます。事前にリソースをプレビューするには、バックアップおよび復元操作のドライランを実行します。
前提条件
- OADP Operator がインストールされている。
手順
実際のバックアップを実行する前に、バックアップに含まれるリソースをプレビューするには、次のコマンドを実行します。
$ velero backup create <backup-name> --snapshot-volumes false1 - 1
--snapshot-volumesパラメーターの値をfalseに指定します。
バックアップリソースの詳細を確認するには、次のコマンドを実行します。
$ velero describe backup <backup_name> --details1 - 1
- バックアップの名前を指定します。
実際の復元を実行する前に、復元に含まれるリソースをプレビューするには、次のコマンドを実行します。
$ velero restore create --from-backup <backup-name>1 - 1
- バックアップリソースを確認するために、作成したバックアップの名前を指定します。
重要velero restore createコマンドは、クラスター内に復元リソースを作成します。リソースを確認した後、復元中に作成されたリソースを削除する必要があります。復元リソースの詳細を確認するには、次のコマンドを実行します。
$ velero describe restore <restore_name> --details1 - 1
- 復元の名前を指定します。
バックアップ操作の前または後にコマンドを実行するためのバックアップフックを作成できます。バックアップフックの作成 を参照してください。
Backup CR の代わりに Schedule CR を作成することにより、バックアップをスケジュールできます。Schedule CR を使用したバックアップのスケジュール設定 を参照してください。
4.17.1.2. 既知の問題 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 4.14 は、Restic 復元プロセス中に Pod の readiness を妨げる可能性がある Pod セキュリティーアドミッション (PSA) ポリシーを強制します。
この問題は OADP 1.1.6 および OADP 1.2.2 リリースで解決されており、これらのリリースにアップグレードすることが推奨されます。
4.17.2. バックアップ CR の作成 リンクのコピーリンクがクリップボードにコピーされました!
Backup カスタムリソース (CR) を作成して、Kubernetes イメージ、内部イメージ、および永続ボリューム (PV) をバックアップします。
前提条件
- OpenShift API for Data Protection (OADP) Operator をインストールしている。
-
DataProtectionApplicationCR がReady状態である。 バックアップロケーションの前提条件:
- Velero 用に S3 オブジェクトストレージを設定する必要があります。
-
DataProtectionApplicationCR でバックアップの場所を設定する必要があります。
スナップショットの場所の前提条件:
- クラウドプロバイダーには、ネイティブスナップショット API が必要であるか、Container Storage Interface (CSI) スナップショットをサポートしている必要があります。
-
CSI スナップショットの場合、CSI ドライバーを登録するために
VolumeSnapshotClassCR を作成する必要があります。 -
DataProtectionApplicationCR でボリュームの場所を設定する必要があります。
手順
次のコマンドを入力して、
backupStorageLocationsCR を取得します。$ oc get backupstoragelocations.velero.io -n openshift-adp出力例
NAMESPACE NAME PHASE LAST VALIDATED AGE DEFAULT openshift-adp velero-sample-1 Available 11s 31m次の例のように、
BackupCR を作成します。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: 720h0m0s5 labelSelector:6 matchLabels: app: <label_1> app: <label_2> app: <label_3> orLabelSelectors:7 - matchLabels: app: <label_1> app: <label_2> app: <label_3>- 1
- バックアップする namespace の配列を指定します。
- 2
- オプション: バックアップに含めるリソースの配列を指定します。リソースは、短縮名 ('pods' は 'po' など) または完全修飾名で指定できます。指定しない場合、すべてのリソースが含まれます。
- 3
- オプション: バックアップから除外するリソースの配列を指定します。リソースは、短縮名 ('pods' は 'po' など) または完全修飾名で指定できます。
- 4
backupStorageLocationsCR の名前を指定します。- 5
ttlフィールドは、作成されたバックアップの保持期間とバックアップされたデータのバックアップを定義します。たとえば、バックアップツールとして Restic を使用している場合、バックアップの有効期限が切れるまで、バックアップされたデータ項目と永続ボリューム(PV)のデータコンテンツが保存されます。ただし、このデータを保存すると、ターゲットのバックアップの場所により多くの領域が使用されます。追加のストレージは、頻繁なバックアップで消費されます。バックアップは、他の期限切れでないバックアップがタイムアウトする前でも作成されます。- 6
- 指定したラベルを すべて 持つバックアップリソースの {key,value} ペアのマップ。
- 7
- 指定したラベルを 1 つ以上 持つバックアップリソースの {key,value} ペアのマップ。
BackupCR のステータスがCompletedしたことを確認します。$ oc get backups.velero.io -n openshift-adp <backup> -o jsonpath='{.status.phase}'
4.17.3. CSI スナップショットを使用した永続ボリュームのバックアップ リンクのコピーリンクがクリップボードにコピーされました!
Backup CR を作成する前に、クラウドストレージの VolumeSnapshotClass カスタムリソース (CR) を編集して、Container Storage Interface (CSI) スナップショットを使用して永続ボリュームをバックアップします。CSI ボリュームスナップショット を参照してください。
詳細は、バックアップ CR の作成 を参照してください。
前提条件
- クラウドプロバイダーは、CSI スナップショットをサポートする必要があります。
-
DataProtectionApplicationCR で CSI を有効にする必要があります。
手順
metadata.labels.velero.io/csi-volumesnapshot-class: "true"のキー: 値ペアをVolumeSnapshotClassCR に追加します。設定ファイルのサンプル
apiVersion: snapshot.storage.k8s.io/v1 kind: VolumeSnapshotClass metadata: name: <volume_snapshot_class_name> labels: velero.io/csi-volumesnapshot-class: "true"1 annotations: snapshot.storage.kubernetes.io/is-default-class: true2 driver: <csi_driver> deletionPolicy: <deletion_policy_type>3
次のステップ
-
これで、
BackupCR を作成できます。
4.17.4. File System Backup を使用してアプリケーションをバックアップする: Kopia または Restic リンクのコピーリンクがクリップボードにコピーされました!
OADP を使用して、Pod にアタッチされている Kubernetes ボリュームを、そのボリュームのファイルシステムからバックアップおよび復元できます。このプロセスは、File System Backup (FSB) または Pod Volume Backup (PVB) と呼ばれます。これは、オープンソースのバックアップツール Restic または Kopia のモジュールを使用して実行できます。
クラウドプロバイダーがスナップショットをサポートしていない場合、またはアプリケーションが NFS データボリューム上にある場合は、FSB を使用してバックアップを作成できます。
FSB と OADP の統合により、ほぼすべてのタイプの Kubernetes ボリュームをバックアップおよび復元するためのソリューションが提供されます。この統合は OADP の追加機能であり、既存の機能を置き換えるものではありません。
Backup カスタムリソース (CR) を編集して、Kopia または Restic で Kubernetes リソース、内部イメージ、および永続ボリュームをバックアップします。
DataProtectionApplication CR でスナップショットの場所を指定する必要はありません。
OADP バージョン 1.3 以降では、アプリケーションのバックアップに Kopia または Restic を使用できます。
ビルトイン DataMover の場合は、Kopia を使用する必要があります。
OADP バージョン 1.2 以前の場合、アプリケーションのバックアップには Restic のみ使用できます。
FSB は、hostPath ボリュームのバックアップをサポートしません。詳細は、FSB の制限事項 を参照してください。
…/.snapshot: read-only file system エラーで失敗する
…/.snapshot ディレクトリーは、複数の NFS サーバーによって使用されるスナップショットコピーディレクトリーです。このディレクトリーにはデフォルトで読み取り専用アクセスが設定されているため、Velero はこのディレクトリーに復元できません。
Velero に .snapshot ディレクトリーへの書き込みアクセス権を付与しないでください。また、このディレクトリーへのクライアントアクセスを無効にしてください。
前提条件
- OpenShift API for Data Protection (OADP) Operator をインストールしている。
-
DataProtectionApplicationCR でspec.configuration.nodeAgent.enableをfalseに設定して、デフォルトのnodeAgentインストールを無効にしていない。 -
DataProtectionApplicationCR でspec.configuration.nodeAgent.uploaderTypeをkopiaまたはresticに設定して、Kopia または Restic をアップローダーとして選択している。 -
DataProtectionApplicationCR がReady状態である。
手順
次の例のように、
BackupCR を作成します。apiVersion: velero.io/v1 kind: Backup metadata: name: <backup> labels: velero.io/storage-location: default namespace: openshift-adp spec: defaultVolumesToFsBackup: true1 ...- 1
- OADP バージョン 1.2 以降では、
defaultVolumesToFsBackup: true設定をspecブロック内に追加します。OADP バージョン 1.1 では、defaultVolumesToRestic: trueを追加します。
4.17.5. バックアップフックの作成 リンクのコピーリンクがクリップボードにコピーされました!
バックアップを実行する際に、バックアップされる Pod に基づいて、Pod 内のコンテナーで実行するコマンドを 1 つ以上指定できます。
コマンドは、カスタムアクション処理の前 (プリ フック)、またはすべてのカスタムアクションが完了し、カスタムアクションで指定された追加アイテムがバックアップされた後 (ポスト フック) に実行するように設定できます。
Backup カスタムリソース (CR) を編集して、Pod 内のコンテナーでコマンドを実行するためのバックアップフックを作成します。
手順
次の例のように、
BackupCR の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: [] - pods3 excludedResources: []4 labelSelector:5 matchLabels: app: velero component: server pre:6 - exec: container: <container>7 command: - /bin/uname8 - -a onError: Fail9 timeout: 30s10 post:11 ...- 1
- オプション: フックが適用される namespace を指定できます。この値が指定されていない場合、フックはすべての namespace に適用されます。
- 2
- オプション: フックが適用されない namespace を指定できます。
- 3
- 現在、Pod は、フックを適用できる唯一のサポート対象リソースです。
- 4
- オプション: フックが適用されないリソースを指定できます。
- 5
- オプション: このフックは、ラベルに一致するオブジェクトにのみ適用されます。この値が指定されていない場合、フックはすべてのオブジェクトに適用されます。
- 6
- バックアップの前に実行するフックの配列。
- 7
- オプション: コンテナーが指定されていない場合、コマンドは Pod の最初のコンテナーで実行されます。
- 8
- これは、追加される
initコンテナーのエントリーポイントです。 - 9
- エラー処理に許可される値は、
FailとContinueです。デフォルトはFailです。 - 10
- オプション: コマンドの実行を待機する時間。デフォルトは
30sです。 - 11
- このブロックでは、バックアップ後に実行するフックの配列を、バックアップ前のフックと同じパラメーターで定義します。
4.17.6. Schedule CR を使用したバックアップのスケジュール設定 リンクのコピーリンクがクリップボードにコピーされました!
スケジュール操作を使用すると、Cron 式で指定された特定の時間にデータのバックアップを作成できます。
Backup CR の代わりに Schedule カスタムリソース (CR) を作成して、バックアップをスケジュールします。
バックアップスケジュールでは、別のバックアップが作成される前にバックアップを数量するための時間を十分確保してください。
たとえば、namespace のバックアップに通常 10 分かかる場合は、15 分ごとよりも頻繁にバックアップをスケジュールしないでください。
前提条件
- OpenShift API for Data Protection (OADP) Operator をインストールしている。
-
DataProtectionApplicationCR がReady状態である。
手順
backupStorageLocationsCR を取得します。$ oc get backupStorageLocations -n openshift-adp出力例
NAMESPACE NAME PHASE LAST VALIDATED AGE DEFAULT openshift-adp velero-sample-1 Available 11s 31m次の例のように、
ScheduleCR を作成します。$ 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 defaultVolumesToFsBackup: true4 ttl: 720h0m0s5 EOF注記特定の間隔でバックアップをスケジュールするには、次の形式で
<duration_in_minutes>を入力します。schedule: "*/10 * * * *"引用符 (
" ") の間に分の値を入力します。- 1
- バックアップをスケジュールするための
cron式。たとえば、毎日 7:00 にバックアップを実行する場合は0 7 * * *です。 - 2
- バックアップを作成する namespace の配列。
- 3
backupStorageLocationsCR の名前。- 4
- オプション: OADP バージョン 1.2 以降では、Restic を使用してボリュームのバックアップを実行するときに、
defaultVolumesToFsBackup: trueキーと値のペアを設定に追加します。OADP バージョン 1.1 では、Restic でボリュームをバックアップするときに、defaultVolumesToRestic: trueのキーと値のペアを追加します。 - 5
ttlフィールドは、作成されたバックアップの保持期間とバックアップされたデータのバックアップを定義します。たとえば、バックアップツールとして Restic を使用している場合、バックアップの有効期限が切れるまで、バックアップされたデータ項目と永続ボリューム(PV)のデータコンテンツが保存されます。ただし、このデータを保存すると、ターゲットのバックアップの場所により多くの領域が使用されます。追加のストレージは、頻繁なバックアップで消費されます。バックアップは、他の期限切れでないバックアップがタイムアウトする前でも作成されます。
スケジュールされたバックアップの実行後に、
ScheduleCR のステータスがCompletedとなっていることを確認します。$ oc get schedule -n openshift-adp <schedule> -o jsonpath='{.status.phase}'
4.17.7. バックアップの削除 リンクのコピーリンクがクリップボードにコピーされました!
バックアップを削除するには、次の手順で説明するように、DeleteBackupRequest カスタムリソース (CR) を作成するか、velero backup delete コマンドを実行します。
ボリュームバックアップアーティファクトは、バックアップ方法に応じて、異なるタイミングで削除されます。
- Restic: アーティファクトは、バックアップが削除された後、次のフルメンテナンスサイクル中に削除されます。
- Container Storage Interface (CSI): アーティファクトは、バックアップが削除されると直ちに削除されます。
- Kopia: アーティファクトは、バックアップが削除されてから、Kopia リポジトリーのフルメンテナンスサイクルが 3 回実行された後に削除されます。
4.17.7.1. DeleteBackupRequest CR を作成してバックアップを削除する リンクのコピーリンクがクリップボードにコピーされました!
DeleteBackupRequest カスタムリソース (CR) を作成することで、バックアップを削除できます。
前提条件
- アプリケーションのバックアップを実行した。
手順
DeleteBackupRequestCR マニフェストファイルを作成します。apiVersion: velero.io/v1 kind: DeleteBackupRequest metadata: name: deletebackuprequest namespace: openshift-adp spec: backupName: <backup_name>1 - 1
- バックアップの名前を指定します。
DeleteBackupRequestCR を適用してバックアップを削除します。$ oc apply -f <deletebackuprequest_cr_filename>
4.17.7.2. Velero CLI を使用してバックアップを削除する リンクのコピーリンクがクリップボードにコピーされました!
Velero CLI を使用してバックアップを削除できます。
前提条件
- アプリケーションのバックアップを実行した。
- Velero CLI がダウンロード済みであり、クラスター内の Velero バイナリーにアクセスできる。
手順
バックアップを削除するには、次の Velero コマンドを実行します。
$ velero backup delete <backup_name> -n openshift-adp1 - 1
- バックアップの名前を指定します。
4.17.7.3. Kopia リポジトリーのメンテナンスについて リンクのコピーリンクがクリップボードにコピーされました!
Kopia リポジトリーのメンテナンスには次の 2 種類があります。
- クイックメンテナンス
- インデックス Blob の数 (n) を抑えるために 1 時間ごとに実行されます。インデックスの数が多いと、Kopia 操作のパフォーマンスに悪影響が及びます。
- 同じメタデータの別のコピーが存在することを確認してから、リポジトリーからメタデータを削除します。
- フルメンテナンス
- 不要になったリポジトリーコンテンツのガベージコレクションを実行するために、24 時間ごとに実行されます。
-
フルメンテナンスのタスクである
snapshot-gcが、スナップショットマニフェストからアクセスできなくなったすべてのファイルとディレクトリーリストを検索し、それらを削除済みとしてマークします。 - フルメンテナンスは、クラスター内でアクティブなすべてのスナップショット内のすべてのディレクトリーをスキャンする必要があるため、リソースを大量に消費する操作です。
4.17.7.3.1. OADP における Kopia のメンテナンス リンクのコピーリンクがクリップボードにコピーされました!
repo-maintain-job ジョブは、次の例に示すように、OADP がインストールされている namespace で実行されます。
pod/repo-maintain-job-173...2527-2nbls 0/1 Completed 0 168m
pod/repo-maintain-job-173....536-fl9tm 0/1 Completed 0 108m
pod/repo-maintain-job-173...2545-55ggx 0/1 Completed 0 48m
repo-maintain-job のログで、バックアップオブジェクトストレージ内のクリーンアップとアーティファクトの削除に関する詳細を確認できます。次の例に示すように、repo-maintain-job では、次のフルメンテナンスサイクルの予定日時に関する情報を確認できます。
not due for full maintenance cycle until 2024-00-00 18:29:4
バックアップオブジェクトストレージからオブジェクトを削除するには、フルメンテナンスサイクルを 3 回正常に実行する必要があります。つまり、バックアップオブジェクトストレージ内のすべてのアーティファクトが削除されるまでに、最大 72 時間かかると予想されます。
4.17.7.4. バックアップリポジトリーの削除 リンクのコピーリンクがクリップボードにコピーされました!
バックアップを削除し、関連するアーティファクトを削除する Kopia リポジトリーのメンテナンスサイクルが完了すると、そのバックアップはどのメタデータオブジェクトやマニフェストオブジェクトからも参照されなくなります。その後、backuprepository カスタムリソース (CR) を削除して、バックアップ削除プロセスを完了できます。
前提条件
- アプリケーションのバックアップを削除した。
- バックアップが削除されてから最大 72 時間待機した。この時間枠を確保することで、Kopia がリポジトリーのメンテナンスサイクルを実行できるようにします。
手順
バックアップのバックアップリポジトリー CR の名前を取得するために、次のコマンドを実行します。
$ oc get backuprepositories.velero.io -n openshift-adpバックアップリポジトリー CR を削除するために、次のコマンドを実行します。
$ oc delete backuprepository <backup_repository_name> -n openshift-adp1 - 1
- 前のステップのバックアップリポジトリーの名前を指定します。
4.17.8. Kopia について リンクのコピーリンクがクリップボードにコピーされました!
Kopia は、高速かつセキュアなオープンソースのバックアップおよび復元ツールです。これを使用して、データの暗号化されたスナップショットを作成し、そのスナップショットを選択したリモートストレージまたはクラウドストレージに保存できます。
Kopia は、ネットワークおよびローカルストレージの場所、および多くのクラウドまたはリモートストレージの場所をサポートしています。以下はその一部です。
- Amazon S3 および S3 と互換性のあるクラウドストレージ
- Azure Blob Storage
- Google Cloud Storage プラットフォーム
Kopia は、スナップショットにコンテンツアドレスを指定できるストレージを使用します。
- スナップショットは常に増分されます。すでに以前のスナップショットに含まれているデータは、リポジトリーに再アップロードされません。リポジトリーに再度アップロードされるのは、ファイルが変更されたときだけです。
- 保存されたデータは重複排除されます。同じファイルのコピーが複数存在する場合、そのうちの 1 つだけが保存されます。
- ファイルが移動された場合、またはファイルの名前が変更された場合、Kopia はそれらが同じコンテンツであることを認識し、それらを再度アップロードしません。
4.17.8.1. OADP と Kopia の統合 リンクのコピーリンクがクリップボードにコピーされました!
OADP 1.3 は、Pod ボリュームバックアップのバックアップメカニズムとして、Restic に加えて Kopia をサポートします。インストール時に、DataProtectionApplication カスタムリソース (CR) の uploaderType フィールドを設定して、どちらかを選択する必要があります。使用できる値は、restic または kopia です。uploaderType を指定しない場合、OADP 1.3 はデフォルトで Kopia をバックアップメカニズムとして使用します。データは統合リポジトリーに書き込まれ、統合リポジトリーから読み取られます。
Kopia クライアントを使用して Kopia バックアップリポジトリーを変更することはサポートされていません。変更すると、Kopia バックアップの整合性に影響が生じる可能性があります。OADP は Kopia リポジトリーへの直接接続をサポートしておらず、ベストエフォートでのみサポートを提供できます。
次の例は、Kopia を使用するように設定された DataProtectionApplication CR を示しています。
apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
name: dpa-sample
spec:
configuration:
nodeAgent:
enable: true
uploaderType: kopia
# ...