Translated message

A translation of this page exists in English.

OpenShift API for Data Protection (OADP) の FAQ

更新 -

Table of Contents

目次

免責事項: 外部の Web サイトへのリンクは、お客様の利便性のみを目的として提供しています。Red Hat はリンクの内容を確認しておらず、コンテンツまたは可用性について責任を負わないものとします。外部の Web サイトへのリンクを含めることは、Web サイトまたはそれらの法的主体、製品またはサービスについて Red Hat が承認したことを意味するものではありません。お客様は、外部サイトまたはコンテンツの使用 (または信頼) によって生じる損失または費用について、Red Hat が責任を負わないことに同意するものとします。

ビジネスおよびユーザーのワークロードをホストするために使用されるプラットフォームにおいて、データ保護は重要な部分となります。データ保護には、オンデマンドバックアップ、スケジュールされたバックアップ、および復元などの操作が含まれる場合があります。これらの操作により、クラスター内のオブジェクトをローカルまたはパブリッククラウド上のストレージプロバイダーにバックアップすることができ、障害発生時や定期メンテナンス時に、そのクラスターをバックアップから復元できます。

Red Hat は、この目的のために OpenShift API for Data Protection (OADP) を作成しました。OADP は、Red Hat パートナーが障害復旧およびデータ保護のソリューションの作成に活用できる API を OpenShift Container Platform にもたらします。

よくある質問

OADP とは何ですか?

OpenShift APIs for Data Protection (OADP) は、Red Hat が OpenShift クラスターでバックアップおよび復元 API を作成するために作成した Operator です。
OADP の詳細は、次のリンクを参照してください。
OADP ドキュメント
OADP カスタマーポータル: 検証済みのソリューション、記事、サポートとのディスカッション
OADP と OpenShift Virtualization を使い始める
OADP ブログ投稿
Red Hat エキスパート (別名 MOB、OADP ブログ)
OADP トラブルシューティングガイド
Backup OpenShift applications using the OpenShift API for Data Protection with Multicloud Object Gateway
Red Hat OADP トレーニング
Velero ドキュメント - 最新版
Velero Code Wiki

現在サポートされている OADP のバージョン

OADP の今後のバージョン

お客様およびパートナーの皆様は、OADP の今後のサポート対象バージョンについて理解を深めるため、Partners page を参照する必要があります。

AWS S3 互換バックアップストレージプロバイダー

  • サポートされている S3 オブジェクトストレージ

  • S3 プロバイダーと AWS SDKV1 および SDKV2 の違いにより、一部のお客様に問題が発生する可能性があります。 最新の OADP-1.4 リリースでは、aws と legacy-aws の両方のプラグインオプションが提供されます。詳細は ドキュメント を参照してください。

  • OADP はバックアップデータの不変性のための S3 設定をサポートしていません。詳細は ドキュメント を参照してください。

    • S3 オブジェクトロック
    • オブジェクトの保持
    • バケットのバージョン管理
    • Write Once Read Many (WORM) バケット

  • S3 プロバイダーの既知の問題

OADP のアップグレード方法

OADP のアップグレードについては公式ドキュメントを参照してください。

OADP のデバッグ、oadp-must-gather

OADP-1.5: oc adm must-gather --image=registry.redhat.io/oadp/oadp-mustgather-rhel9:v1.5 -- /usr/bin/gather --skip-tls
OADP-1.4: oc adm must-gather --image=registry.redhat.io/oadp/oadp-mustgather-rhel9:v1.4 -- /usr/bin/gather --skip-tls
OADP-1.3: oc adm must-gather --image=registry.redhat.io/oadp/oadp-mustgather-rhel9:v1.3 -- /usr/bin/gather --skip-tls

OADP がデプロイする各コンテナーの詳細を確認するにはどうすればいいですか?

Red Hat が OpenShift 向けに提供するすべてのコンテナーの詳細は、Red Hat Container Catalog で参照できます。

上記のリンクは、OADP でフィルタリングされた結果が表示されます。 OADP 1.3.0 以降のリリースは rhel9 UBI コンテナーイメージ (例: 'oadp/oadp-velero-plugin-for-csi-rhel9') 上にビルドされていることに注意してください。
ここでは、以下が提供されています。
- セキュリティー情報
- Git およびソース関連情報
- RPM パッケージ

OADP に UI が必要な場合

CloudCasa とのパートナーシップとコラボレーションを確認してみてください。 CloudCasa には、OADP と統合されたホスト型またはオンプレミスの Web ベースのユーザーインターフェイスがあります。 詳細は、パートナーページ を参照してください。

Operator が提供する API は何ですか?

OADP は以下の API を提供します。

  • Backup
  • Restore
  • Schedule
  • BackupStorageLocation
  • VolumeSnapshotLocation

Red Hat は、Velero アップストリームプロジェクトでドキュメント化されているように、API を 追加、削除、または変更していません。Velero API Types の詳細については、Velero のサイトを参照してください。

OADP はクラスター全体をバックアップできますか?

いいえ。OADP は、OpenShift プラットフォーム上のお客様が使用するアプリケーションをバックアップすることを目的としています。 OADP は Operator または etcd を正常にバックアップおよび復元できません。 namespace やラベルを使用して不適切なリソースがバックアップされないように、バックアップをカスタマイズする方法はさまざまあります。

OADP のアップストリームプロジェクトはありますか?

はい、あります。OADP Operator は、oadp-operator アップストリームプロジェクトで開発されています。

OADP Operator のサポート状況はどうなっていますか?

OADP サポートポリシー を参照してください。

OADP は完全なエンドツーエンドのデータ保護ソリューションですか?

OpenShift API for Data Protection (OADP) 機能は、アプリケーションのバックアップと復元のオプションを提供します。OADP の機能に関する詳細は、当社の ドキュメント を参照してください。

OADP はどのようなデータを保護できますか?

OADP は、OpenShift クラスターリソース (yaml ファイル)、内部イメージ、および永続ボリュームデータをバックアップおよび復元するための API を提供します。

OADP Operator は何をインストールしますか?

OADP Operator は、バックアップおよび復元操作のために、Velero と、Velero が使用する OpenShift プラグインをインストールします。

同じクラスターに複数のバージョンの OADP をインストールできますか?

いいえ、OADP バージョンごとに異なる CustomResourceDefinitions を使用できます。同じクラスターに 複数の OADP バージョン がインストールされている場合、正常に動作するのは 1 つのバージョン の OADP のみです。
クラスターには OADP (および Velero) のバージョン 1 つをインストールすることを推奨します。OADP と Velero バージョンの関係 を参照してください

クラウドプロバイダーとハイパースケーラーの既知の問題

  • IBMCloud:
    • IBMCloud の k8s ホストパスはデフォルトで /var/data/kublet/pods に設定されています。詳細は次の問題を参照してください。
    • この問題により、OADP のノードエージェントがクラッシュします。
    • OADP は、OpenShift クラスターが IBMCloud 上で実行されていることを自動的に検出し、調整を行います。(詳細は下記を参照)[https://issues.redhat.com/browse/OADP-4623]
    • ホストパス設定を上書きするには、OADP csv 設定を確認して更新してください。
oc get csv oadp-operator.v1.4.1 -o yaml
oc get nodes
oc debug node/$node
  • $path/kublet/pods と $path/kublet/plugins へのパスを確認します。
  • 必要に応じて CSV の設定を調整します。
containers:
- args:
  - --leader-elect
  command:
  - /manager
  env:
  - name: WATCH_NAMESPACE
    valueFrom:
      fieldRef:
        fieldPath: metadata.annotations['olm.targetNamespaces']
  - name: RESTIC_PV_HOSTPATH
  - name: FS_PV_HOSTPATH
    value: /var/lib/kubelet/pods
  - name: PLUGINS_HOSTPATH
    value: /var/lib/kubelet/plugins
  • Huawei:
    • Huawei でも IBMCloud のホストパス設定と同様の問題があることが報告されています。 ノードエージェントを適切に動作させるには、同じタイプのカスタマイズが必要になる場合があります。

MTC と一緒に OADP をインストールできますか?

インストールする OADP のバージョンが、MTC が依存する OADP のバージョンと同じであれば、実行できます。
たとえば、OADP 1.0 を必要とする MTC 1.7 をインストールしたり、OADP 1.1 をインストールしたりできません。このシナリオでは、OADP 1.0 のみをインストールできます。

OADP は CSI スナップショットをサポートしますか?

はい、ドキュメント を参照してください

仮想マシン (VM) のバックアップが virt-freeze で失敗します

通常、Windows 仮想マシンでは、virt-freeze コマンドが断続的に失敗することがあります。 現時点では唯一の回避策は、再試行することです。
以下の課題を参照してください。CNV-56743、CNV-75370
KCS: OpenShift Virtualization: OADP or Cohesity backup freezes VM during backup
Overview of Processing a Backup Under VSS
非公式かつサポートされていない回避策: こちら
非公式かつサポートされていない ACM ポリシー: こちら

OADP にデータムーバーを追加する予定はありますか?

data mover は OADP 1.3.0 以降で完全にサポートされています

ユーザーは独自のバックアップを作成できますか?つまり、クラスター管理者以外のユーザーがバックアップと復元を作成できますか?

はい、OADP-1.5.0 以降、OADP はお客様向けのセルフサービスサポートに対応しています。セルフサービスドキュメント

Velero バックアップ [logs,describe] コマンドで "tls: failed to verify certificate: x509" エラーが発生します

DPA 証明書設定では、クライアントマシンから実行された場合の velero cli の動作は変更されません。 velero backup logs コマンドの --help を確認します。

Usage:
  velero backup logs BACKUP [flags]

Flags:
      --cacert string              Path to a certificate bundle to use when verifying TLS connections.
  -h, --help                       help for logs
      --insecure-skip-tls-verify   If true, the object store's TLS certificate will not be checked for validity. This is insecure and susceptible to man-in-the-middle attacks. Not recommended for production.

The --cacert and --insecure-skip-tls-verify flags should ONLY be used with the following velero commands.
* velero backup describe
* velero backup download
* velero backup logs
* velero restore describe
* velero restore logs

このコマンドで cacert を使用する場合は、次のように velero デプロイメントに cert を追加できます。

$ oc get dataprotectionapplications.oadp.openshift.io <dpa-name> -o jsonpath='{.spec.backupLocations[0].velero.objectStorage.caCert}' | base64 -d | oc exec -i deploy/velero -c velero -- bash -c "cat > /tmp/your-cacert.txt"

インストールされている Velero OADP のバージョンを確認するにはどうすればよいですか?

OADP インストール後、velero デプロイメントにはイメージのタグが含まれます。デフォルトの設定で OADP をインストールすると、デプロイメントで呼び出されたバージョンのアップストリームのタグ付きイメージを使用することになります。また、バージョンマトリクス を確認することもできます。

バックアップ/復元に OADP API を使用する例はどこにありますか?

アップストリームの oadp-operator プロジェクトの OADP Operator ページに、使用方法に関する 例 が記載されています。 サンプルアプリケーション も提供しています

関連付けられたリージョンのない S3 互換ストレージを使用します

リージョンを設定する必要のない S3 互換のストレージ実装があります。 このようなケースでは、DPA YAML 設定の該当箇所に "us-east-1" などの有効な AWS リージョンを代入します。 たとえば、OADP with MCG ドキュメントなどです。 velero の 課題 を参照してください。

  • ユーザーは以下を指定する必要があります。
    • s3Url: https://foo/storage
    • region: us-east-1
 backupLocations:
    - velero:
        config:
          profile: "default"
          region: us-east-1
          s3Url:  https://foo/storage <s3 endpoint>
          insecureSkipTLSVerify: "true"
          s3ForcePathStyle: "true"
        provider: aws
        default: true
        credential:
          key: cloud
          name: cloud-credentials 
        objectStorage:
          bucket: <bucket_name> 
          prefix: <prefix>

Kopia リポジトリーの操作

  • ユーザーは、kopia クライアントを使用して、s3 内のバックアップリポジトリーに接続できます。
export S3_BUCKET=<your bucket name>
export S3_REPOSITORY_PATH=<path without S3_BUCKET>
export S3_ACCESS_KEY=<s3 access key>
export S3_SECRET_ACCESS_KEY=<s3 secret access key>

"static-passw0rd" is the default password

kopia repository connect s3 \
    --bucket="$S3_BUCKET" \
    --prefix="$S3_REPOSITORY_PATH" \
    --access-key="$S3_ACCESS_KEY" \
    --secret-access-key="$S3_SECRET_ACCESS_KEY" \
    --password=static-passw0rd

kopia クライアント: https://kopia.io/docs/reference/command-line/
kopia の一般的なコマンド: https://kopia.io/docs/reference/command-line/common/
kopia 高度なコマンド: https://kopia.io/docs/reference/command-line/advanced/

増分バックアップ

現時点では、OADP の増分バックアップでどれだけ節約されているかを明確に可視化できていません。この点に関しては改善が行われています。
各増分バックアップの詳細を確認する方法の例については、次のリンクを参照してください。
* kopia のトラブルシューティング

注記: new-data、new-files キーからの出力は以下のとおりです。

2025-09-26 15:35:53 UTC kc492e2ac155921724d6c61c8f4be240b 108.3 MB dgrwxrwxr-x files:101 dirs:6 new-data:15.9 MB new-files:83 new-dirs:6 compression:0.0% (latest-2) pins:velero-pin
2025-09-26 15:38:04 UTC k8d3195f8fb0c0ee9ccc45f4a2be4f34e 108.3 MB dgrwxrwxr-x files:104 dirs:6 new-data:68 B new-files:1 new-dirs:1 compression:0% latest-1,hourly-1,daily-1,weekly-1,monthly-1,annual-1) pins:velero-pin

OADP は復元クラスターからベースドメインを使用してルートを復元できますか?

OADP は、復元されるルートが生成されたルートである場合、復元クラスターからベースドメインを使用してルートを復元します。

生成されたルートとは、作成時に route.spec.host を指定せず、OpenShift にルートのホスト名を生成させるルートです。生成されたルートには、アノテーション "openshift.io/host.generated: 'true'" が付きます。このアノテーションをルートに手動で追加すると、復元中に予期しない動作が発生する可能性があります。ホストの値を生成された値から変更した場合、復元したときにそのホストの値が失われる可能性があります。

現時点では、OADP には、生成されていないルートのクラスターベースドメイン名に基づいてルートホスト値を動的に設定するメカニズムはありません。

同様に、生成されたルートの場合、ホスト値は oadp-operator によって削除され、復元クラスターで再生成されます。生成されたルートの .spec.host への変更は復元時に失われます。

内部レジストリーイメージのバックアップをオフにできますか?

内部レジストリーイメージ (イメージストリーム) のバックアップに関連するエラーが原因で、バックアップまたは復元中に問題が発生した場合は、DataProtectionApplication 仕様でイメージバックアップ機能をオフにできます。

spec:
  backupImages: false // set this to disable image backup/restore

バックアップの有効期限を設定します

バックアップを作成するときに、フラグ --ttl を追加して TTL (存続時間) を指定できます。Velero は、既存のバックアップリソースの有効期限が切れていることを検出すると、以下を削除します。

  • バックアップリソース
  • クラウドオブジェクトストレージからのバックアップファイル
  • すべての PersistentVolume スナップショット
  • 関連するすべての復元

詳細なアップストリームドキュメント

OADP バックアップの復元に関する問題: アプリケーションがデータにアクセスできません

OpenShift で namespace が作成されると、一意のユーザー ID (UID) 範囲、補助グループ (GID) 範囲、および一意の SELinux MCS ラベルが割り当てられます。この情報は、namespace の metadata.annotations フィールドに保存されます。新しい namespace が作成されるたびに、OpenShift は利用可能な UID プールから新しい範囲を割り当て、割り当てた値を反映するように metadata.annotations フィールドを更新します。これらのアノテーションを SCC (SecurityContextConstaints) アノテーションと呼びます。

ただし、Namespace リソースにすでにこれらのアノテーションが設定されている場合、OpenShift は Namespace に新しい値を再割り当てしません。代わりに、既存の値が有効であると想定して先に進みます。

以下は OpenShift namespace の SCC アノテーションです。
* openshift.io/sa.scc.mcs
* openshift.io/sa.scc.supplemental-groups
* openshift.io/sa.scc.uid-range

復元後にワークロードがデータにアクセスできない可能性がある場合
* 別のクラスターなど、バックアップ時とは SCC アノテーションが異なる namespace がすでにある場合、OADP は既存の namespace を再利用します。
* バックアップでラベルセレクターが使用され、ワークロードが実行される namespace にラベルがありません。OADP は namespace をバックアップしませんが、復元中に以前の namespace アノテーションなしで新しい namespace を作成し、新しい UID 範囲を namespace に割り当てることになります。

OpenShift は namespace のアノテーションに基づいて Pod の securityContext UID を割り当てます。ただし、この場合、永続ボリュームデータがバックアップされた時点から変更されているため、これが現在使用するワークロードでは問題になる可能性があります。
* コンテナーの UID がファイル所有者の UID と一致しなくなりました。
* アプリケーションは、異なる UID が所有するデータを読み書きできないというエラーを報告します。

単純な緩和策として以下が挙げられます。
* ラベルセレクターを使用してバックアップに含めるオブジェクトをフィルタリングするときに、ワークロードを含む namespace にラベルセレクターを追加します。
* 復元前に既存の namespace を削除します。

高度な緩和策
* 移行後の UID 範囲の修正 の手順 2-4 に従って、復元されたクラスター内のファイルの所有者を更新します。

バックアップから新しいクラスターの namespace を復元すると、別の namespace との UID 範囲の競合の可能性など、リスクが伴います。これらのリスクを軽減するために、お客様は任意で 移行後の UID 範囲の修正 の手順 1-4 に従うことができます。

OpenShift の UID/GID 範囲の詳細は、OpenShift と UID のガイド を参照してください。

あるクラスターからデータをバックアップし、別のクラスターに復元します

  • 2 つの異なるクラスターにデータを正常にバックアップおよび復元するには、両方のクラスターの DPA 設定で次の点を確認してください。
    • OpenShift のドキュメント
    • バックアップストアの場所 (BSL) とボリュームスナップショットの場所の名前とパスは同じで、リソースを別のクラスターに復元します。
    • 同じオブジェクトストレージの場所の認証情報をクラスター間で共有する必要があります。
    • この場合、アップストリームの Velero ドキュメント が役立ちます。
    • ボリュームのバックアップと復元については、最新の OADP ドキュメントと datamover のセクションを参照してください。
    • 最適な結果を得るには、OADP が宛先クラスター上に namespace を作成できるように許可してください。
    • ボリュームがすでに存在する namespace に PVC を復元する場合は、復元の前に、更新する必要がある PVC をまず削除する必要があります。Restic のユースケースでは、復元されるバックアップにデプロイメントも含まれていると仮定して、マウント Pod のデプロイメント (または DC など) も削除する必要があります。

障害復旧 - スケジュールと読み取り専用バックアップ保存場所を使用します

障害復旧時には、復元プロセス中にバックアップ保存場所への追加/削除を防ぐために、バックアップ場所の accessMode を ReadOnly に設定することを推奨します。

DataProtectionApplication 仕様では、accessMode を readOnly に設定します。

...
spec:
  backupLocations:
    - velero:
        accessMode: ReadOnly
...

バックアップからの復元に進みます。

ArgoCD で OADP の復元に失敗します

復元中に ArgoCD が使用されている場合、復元が失敗する可能性があります。これは、ArgoCD app.kubernetes.io/instance で使用されるラベルが原因である可能性があります。このラベルは、ArgoCD が管理する必要があるリソースを識別するために使用されます。これにより、復元時に OADP が管理するリソースとの競合が発生する可能性があります。

この問題を解決するには、ArgoCD yaml の .spec.resourceTrackingMethod を annotation+label または annotation に設定します。 それでも問題が解決しない場合は、復元前に ArgoCD を無効にし、復元が完了したら再度有効にします。

関連情報:
- Add Backup warning for inclusion of NS managed by ArgoCD
- Volumesnapshot getting deleted during backup (argocd)
- OADP + OpenShift GitOps - An approach to implementing application disaster recovery

エラーが発生した場合は 連絡 してください。問題の解決に努めます。

OADP を複数の OpenShift プロジェクトにインストールしてプロジェクト所有者を有効化できますか?

近日中にこのユースケースを説明したドキュメントを追加する予定です。OADP-3931 で追跡されている github.com/migtools/oadp-non-admin でこのユースケースに積極的に対応していますが、こちらでも記載しておきます。 OADP を複数の namespace にインストールして、複数のクラスター管理者が独自の OADP インスタンスを管理できるようにできます。 OADP はクラスター内ですべて同一バージョンを使用する必要があります。異なるバージョンの共存はサポートされていません。

  • OADP の個々のデプロイメントごとに、一意の認証情報セットと BackupStorageLocation 設定が必要です。 ワークフローは Restic と CSI で検証されています。
  • デフォルトでは、各 OADP デプロイメントには namespace 全体にわたるクラスターレベルのアクセス権があることに注意してください。

ROSA クラスターで OADP を使用しようとしており、サポートが必要です

最近、ROSA クラスターで OADP をインストールおよび設定するためのドキュメントが更新されました。 こちら のドキュメントを参照してください。

バックアップの TTL を非常に短く設定しましたが、TTL が期限切れになった後もデータが残っています

有効期限はすぐ適用されるのではなく、GC コントローラーが 1 時間ごとにリコンシリエーションループを実行するときに適用されます。

OADP-1.2.x Datamover 対応のバックアップ/リストアが WaitingForPluginOperations で停止します

  • バックアップが待機状態のまま停止する原因の 1 つとして、restic ロックが考えられます。 根本原因が restic ロックであるかどうかを判断するには、次のコマンドを使用して vsb を循環します。
 oc get vsb -n <protected-ns> -o yaml | grep resticrepository
  • restic ロックを参照するエラー (Fatal: unable to create lock in backend: repository is already locked) を探します。
  • バックアップ/復元を成功させるには、ロックを解除する必要があります。
  • 以下を参照してください。
    • https://restic.readthedocs.io/en/stable/100_references.html?highlight=lock#locks
    • https://forum.restic.net/t/detecting-stale-locks/1889/15
    • https://github.com/restic/restic/issues/1450

注記:OADP 1.1 の Datamover バックアップは、スケジュール実行時、または繰り返し実行時に vsb クリーンアップが必要です

datamover を有効にして velero スケジューラー経由で velero バックアップを実行している場合は、velero リストアでコンテンツの不整合を回避するために vsb を削除する必要があります。 これは、手動またはプログラムによって実行される繰り返しのバックアップにも適用されます。 このドキュメントの vsb クリーンアップ手順を参照してください。

この問題の修正は OADP 1.1.x ではリリースされません。 OADP 1.2.x にアップグレードして問題を修正する必要があります。

velero スケジューラーの問題を回避するには、バックアップコマンドと vsb クリーンアップを含む k8s cron job で velero バックアップを実行することを推奨します。

OADP 1.1 の Datamover バックアップクリーンアップ

OADP 1.1 では、datamover により、一部のリソースが残る可能性があります。

バケット内のスナップショットを削除します

/<protected-ns> の DPA .spec.backupLocation.objectStorage.bucket で指定されたバケットにスナップショットがあります。
- このフォルダーを削除すると、バケット内の すべて のスナップショットが削除されます。

/<protected-ns> フォルダーには、/<volumeSnapshotContent name>-pvc という接頭辞が付いた追加のフォルダーがあります。ここで、volumeSnapshotContent 名は、PVC ごとに datamover によって作成された volumeSnapshotContent です。
- バケット内のスナップショットを 1 つ 削除するには、このフォルダーを削除します。

クラスターリソースを削除します。主なシナリオは 2 つあります。

1.datamover が完了する。volumeSnapshotBackup/volumeSnapshotRestore CR はアプリケーション namespace にまだ存在します。

datamover のバックアップ:
oc delete vsb -n <app-ns> --all

datamover の復元:
oc delete vsr -n <app-ns> --all

  • 注記:必要に応じて削除できる volumeSnapshotContents もあります。
    oc delete volumesnapshotcontent --all

2.Datamover が一部失敗または失敗する。VSB/VSR CR は、これらのコントローラーによって作成された追加のリソースと同様に、アプリケーション namespace に存在します。

datamover のバックアップ:

oc delete vsb -n <app-ns> --all

oc delete volumesnapshot -A --all

oc delete volumesnapshotcontent --all

oc delete pvc -n <protected-ns> --all

oc delete replicationsource -n <protected-ns> --all

datamover の復元:

oc delete vsr -n <app-ns> --all

oc delete volumesnapshot -A --all

oc delete volumesnapshotcontent --all

oc delete replicationdestination -n <protected-ns> --all

VolumeSnapshotContent オブジェクト内のスナップショットコンテンツの確認と更新に失敗しました

バックアップ中にボリュームごとに VolumeSnapShotContent オブジェクトが作成される場合があります。 また、VolumeSnapShotContents オブジェクトが次のようなエラー状態になっている場合もあります。 これは既知の一時的な問題であり、OpenShift が VSC を調整すると解決されるはずです。 詳細は、以下を参照してください。ボリュームスナップショットの作成時にエラーが発生する

      Failed to check and update snapshot content: failed to remove
      VolumeSnapshotBeingCreated annotation on the content
      snapcontent-6cd696d3-2cf4-4c4d-8d96-439dc090b10b: "snapshot controller
      failed to update snapcontent-6cd696d3-2cf4-4c4d-8d96-439dc090b10b on API
      server: Operation cannot be fulfilled on
      volumesnapshotcontents.snapshot.storage.k8s.io
      \"snapcontent-6cd696d3-2cf4-4c4d-8d96-439dc090b10b\": the object has been
      modified; please apply your changes to the latest version and try again"

OADP の CSI スナップショット用 data mover はどのように機能しますか?

OADP datamover がどのように動作するかを詳しく説明した ブログ記事 があります。 公開ドキュメント も参照してください。

VolumeSnapContent が Failed 状態です

次のエラーが発生し、バックアップに通常よりも時間がかかったり、最終的に失敗したりする場合があります。

snapshot controller failed to update or failed to remove...xxxxx
the object has been modified; please apply your changes to the latest version and try again
  • これは 既知の問題 であり、修正が提供されています。
  • 障害が発生したボリュームスナップショットコンテンツオブジェクトを削除できる可能性があります。オブジェクトは自動的に再作成されるはずです。 このような場合には、正しいデータでバックアップを正常に復元できることを確認してください。

BuildConfig アプリケーションのバックアップが部分的に失敗します

完了済みのビルド Pod がバックアップ対象に含まれている場合、バックアップが部分的に失敗する可能性があります。

回避策としては、ビルド Pod に次のアノテーションを追加して、ボリュームをビルド Pod のバックアップから除外します (backup.velero.io/backup-volumes-excludes=buildworkdir,container-storage-root,build-blob-cache)。

ビルド Pod はラベルまたはアノテーション openshift.io/build.name=somebuildname で識別できます。

ビルド Pod にアノテーションを付けるコマンド

NS=<backup-includedNamespace> && oc annotate -n $NS $(oc get pods -n $NS -oname -l openshift.io/build.name=<buildName>) backup.velero.io/backup-volumes-excludes=buildworkdir,container-storage-root,container-storage-run,build-blob-cache

OADP を使用して 3scale API Mgmt をバックアップすることは可能ですか?

こちらの 記事 を参照してください

ソースファイルが見つかりません (at least one source file could not be read エラー)

  • ファイルシステムレベルのボリュームバックアップ (FSB) を使用する場合、バックアップで同様の現象が見られます。
    以下のようにログに記録されます。
time="2023-09-06T06:04:37Z" level=error msg="Error backing up item" backup=openshift-adp/schedule-202309045804985 error="pod volume backup failed: running Restic backup, stderr={\"message_type\":\"error\",\"error\":{\"Op\":\"lstat\",\"Path\":\"application-name-77d8987g765v-76vqv_2023-08-09-22-04.log\",\"Err\":2},\"during\":\"archival\",\"item\":\"/host_pods/3dfghjkytdcvb-rfbijn-47b85-ftrv3i-34567ng4i/volumes/kubernetes.io~azure-file/pvc-45678-dfgjy6-dfjg6vft-7657fv654c/application-name-77d89cf56c-76vqv_2023-08-09-22-04.log\"}
  • または
\"error\":{\"Op\":\"lstat\",\"Path\":\"indices/IF-3KSDFGHG3-
Zy/0/index/_2x79j_1_Lucene91_1.dvm\",\"Err\":2},\"during\":\"archival\",\"item\":\"/
host_pods/41ce-a170-28casfdafdg/volumes/kubernetes.io~csi/
pvc-4a8ba939-8bd0-443b-91aa-cb0a36066586/mount/indices/IF-3K2QkQLSG3-ZyKKa1Nw/0/index/
_2x79j_1_Lucene91_1.dvm\"}\nWarning: at least one source file could not be read\n: error
running restic

これは、ファイルシステムに変更があり、Pod ボリュームのバックアップの実行中にファイルが存在しなくなった場合に発生します。このファイルは、restic によるボリュームの初期スキャン中には存在していたものの、実際に restic ストアにバックアップされた時点で削除された可能性があります。
- CSI バックアップの使用を検討する
- ボリュームを除外することを検討する

"podvolumerestores.velero.io" の新しい CRD スキーマに対して既存の CR を検証中にエラーが発生します

以前のバージョンから OADP 1.2 以降にアップグレードする時に installplan エラーが発生する場合は、アップグレード前に復元を作成しているはずです。

restic が有効な状態で Velero による復元を実行すると、永続ボリュームデータの復元時に podvolumerestore カスタムリソースが作成されます。

OADP 1.2 では、podvolumerestores オブジェクトに、OADP 1.1 podvolumerestore オブジェクトにはない新しい必須フィールドがあります。podvolumerestores が進行中でない限り、別の復元が作成されるときに新しいものが再生成されるため、削除しても安全です。

アップグレードを続行するには、すべての podvolumerestores を削除します。

velero デプロイメント経由でエイリアスされた velero コマンドで cacert を使用します

ユーザーによっては、velero CLI をローカルのシステムにインストールせずに使用する場合があります。

以下のように、エイリアスされた velero コマンドを使用してこれを行うことができます。

alias velero='oc -n openshift-adp exec deployment/velero -c velero -it -- ./velero'

このコマンドで cacert を使用する場合は、次のように velero デプロイメントに cert を追加できます。

$ oc get dataprotectionapplications.oadp.openshift.io <dpa-name> -o jsonpath='{.spec.backupLocations[0].velero.objectStorage.caCert}' | base64 -d | oc exec -i deploy/velero -c velero -- bash -c "cat > /tmp/your-cacert.txt"

velero describe backup <backup-name> --details --cacert /tmp/your-cacert.txt

OADP の今後のバージョンでは、利便性向上のため、velero Pod に証明書をマウントし、上記の追加手順を省略できる場合があります。

BSL 設定で checksumAlgorithm が設定されていない場合に s3 互換 (MCG/ODF/IBM) BackupStorageLocation (BSL) でバックアップが失敗します

バックアップ場所として Noobaa を使用してアプリケーションのバックアップを実行するときに、checksumAlgorithm 設定パラメーターが設定されていない場合、バックアップは失敗します。この値を指定していない場合は、バックアップストレージロケーション (BSL) 設定に checksumAlgorithm の空の値を追加して、この問題を回避します。
空の値は、Data Protection Application (DPA) カスタムリソース (CR) を使用して作成された BSL に対してのみ追加され、他の方法を使用して BSL が作成された場合、この値は追加されません。これは OADP 1.4 以降に適用されます。

S3 バケットのバージョン管理

S3 バケットのバージョン管理を使用すると、OADP バックアップで障害が発生することが知られています。 OADP チームは、S3 バケットのバージョン管理の使用を推奨しません。
参考資料:
- AWS バケットのバージョン管理
- Minio バケットのバージョン管理
- GCP バケットのバージョン管理

エラーには次のようなものがあります。
- "unable to write blobcfg blob:PutBlob() failed for "kopia.blobcfg": unable to complete PutBlob"

復元後、NFS ボリュームを持つ Pod は準備が完了せずに restore-wait という名前のコンテナーを待機しています

PodVolumeRestore は ".../.snapshot: read-only file system" エラーで Failed の状態になります

".../.snapshot" ディレクトリーは、複数の NFS サーバーが使用するスナップショットのコピーを格納するディレクトリーです。これらは読み取り専用であり、velero はこのパスに対して復元できません。また、velero にこのディレクトリーへの書き込みアクセス権を付与することもできません。

このスナップショットのコピーを格納するディレクトリーへのクライアントアクセスを無効にする必要があります。

NetApp ontap: Show the Snapshot copies directory to clients または Allow clients to access Snapshot copies directory. の選択を解除します (https://docs.netapp.com/us-en/ontap/enable-snapshot-dir-access-task.html)。
Portworx Flashblade: スナップショットオプションのチェックを外します (https://docs.portworx.com/portworx-backup-on-prem/reference/restore-with-fb)。

Azure Files CSI ドライバーと復元

AzureFile CSI ドライバーはスナップショットの取得のみをサポートし、復元はサポートしません。 この問題を回避するために、OADP では次の点を確認することを推奨しています。
- CloudCasa CloudCasa は OADP または標準の Velero と統合します。
- Red Hat ナレッジベースの記事

NodeAgent と Node Labels を設定します

OADP の DPA は、k8s nodeSelector を使用して、nodeAgent を実行できるノードを選択します。 指定されたラベルは各ノード上のラベルと同じでなければなりません。
- 以下の例は非推奨の構成 (アンチパターン) であり、両方のラベルがノードに設定されていないと動作しません。

 28   configuration:
 29     nodeAgent:
 30       enable: true
 31       podConfig:
 32         nodeSelector:
 33           'node-role.kubernetes.io/infra: ""'
 34           'node-role.kubernetes.io/worker: ""'
  • 任意のノードで適切な方法で nodeAgent を実行するには、ノードにカスタムラベルを付けます。
    • 'node-role.kubernetes.io/nodeAgent: ""
 28   configuration:
 29     nodeAgent:
 30       enable: true
 31       podConfig:
 32         nodeSelector:
 33           'node-role.kubernetes.io/nodeAgent: ""'

Windows 仮想マシンのバックアップと復元

既知の問題:
- OADP backup of Windows VMs ends with PartiallyFailed status due to guest-agent

仮想ホストスタイルのバケットはファイルシステムバックアップでは機能しません

既知の問題: https://github.com/vmware-tanzu/velero/issues/8739
Tencent Cloud Object Storage (Tencent COS) への影響

  • 以下は、CSI スナップショットを介して pv/pvc データのみをバックアップする例です。
apiVersion: velero.io/v1
kind: Backup
metadata:
  

\# A name for your backup
  name: my-pvc-only-backup
  

\# The namespace where OADP/Velero is installed
  namespace: openshift-adp
spec:
  

\# A list of namespaces to include in the backup.
  includedNamespaces:
  - ecm-adt02

  

\# A list of resource types to include in the backup.
  

\# Only these resources will be backed up from the included namespaces.
  includedResources:
  - persistentvolumeclaims

  

\# The name of the backup storage location where this backup should be stored.
  storageLocation: ecm

  

\# The amount of time before this backup is considered expired and eligible
  

\# for garbage collection.
  ttl: 720h0m0s

注記:
- csi プラグインとともに Velero がインストールされている必要があります。この要件が満たされるようにします (https://docs.redhat.com/en/documentation/openshift_container_platform/4.18/html/backup_and_restore/oadp-application-backup-and-restore#oadp-enabling-csi-dpa_installing-oadp-aws)。
- CSI スナップショットバックアップのすべての前提条件を満たす必要があります (https://docs.redhat.com/en/documentation/openshift_container_platform/4.18/html/backup_and_restore/oadp-application-backup-and-restore#oadp-backing-up-pvs-csi-doc)。

Openshift Data Foundation/OpenShift Container Storage における SELinux のラベルの再設定

仮想マシンを復元した後に Ceph の容量が予想よりも高くなります

Data Mover 用の CephFS PVC の設定

OpenShift API for Data Protection (OADP) operator version is higher than the supported OpenShift cluster version

Comments