1.7. OADP のバックアップ
1.7.1. アプリケーションのバックアップ リンクのコピーリンクがクリップボードにコピーされました!
頻繁にバックアップを行うと、Backup Storage Location のストレージが消費される可能性があります。S3 バケットなどの非ローカルバックアップを使用する場合は、バックアップの頻度、保持期間、永続ボリューム (PV) のデータ量を確認してください。取得したバックアップはすべて期限が切れるまで残るため、スケジュールの有効期限 (TTL) 設定も確認してください。
Backup カスタムリソース (CR) を作成することで、アプリケーションをバックアップできます。詳細は、バックアップ CR の作成 を参照してください。Backup CR のさまざまなバックアップタイプは次のとおりです。
Backup CR は、Kubernetes リソースと内部イメージのバックアップファイルを S3 オブジェクトストレージに作成します。
1.7.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 を使用したバックアップのスケジュール設定 を参照してください。
1.7.1.2. 既知の問題 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenShift Service on AWS 4 は、Restic 復元プロセス中に Pod の準備を妨げる可能性のある Pod セキュリティーアドミッション (PSA) ポリシーを適用します。
この問題は OADP 1.1.6 および OADP 1.2.2 リリースで解決されており、これらのリリースにアップグレードすることが推奨されます。
1.7.3. バックアップフックの作成 リンクのコピーリンクがクリップボードにコピーされました!
バックアップを実行する際に、バックアップされる 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
- このブロックでは、バックアップ後に実行するフックの配列を、バックアップ前のフックと同じパラメーターで定義します。
1.7.4. 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: 720h0m0s EOF
- 1
- バックアップをスケジュールするための
cron式。たとえば、毎日 7:00 にバックアップを実行する場合は0 7 * * *です。注記特定の間隔でバックアップをスケジュールするには、次の形式で
<duration_in_minutes>を入力します。schedule: "*/10 * * * *"引用符 (
" ") の間に分の値を入力します。 - 2
- バックアップを作成する namespace の配列。
- 3
backupStorageLocationsCR の名前。- 4
- オプション: OADP バージョン 1.2 以降では、Restic を使用してボリュームのバックアップを実行するときに、
defaultVolumesToFsBackup: trueキーと値のペアを設定に追加します。OADP バージョン 1.1 では、Restic でボリュームをバックアップするときに、defaultVolumesToRestic: trueのキーと値のペアを追加します。
検証
スケジュールされたバックアップの実行後に、
ScheduleCR のステータスがCompletedとなっていることを確認します。$ oc get schedule -n openshift-adp <schedule> -o jsonpath='{.status.phase}'
1.7.5. バックアップの削除 リンクのコピーリンクがクリップボードにコピーされました!
バックアップを削除するには、次の手順で説明するように、DeleteBackupRequest カスタムリソース (CR) を作成するか、velero backup delete コマンドを実行します。
ボリュームバックアップアーティファクトは、バックアップ方法に応じて、異なるタイミングで削除されます。
- Restic: アーティファクトは、バックアップが削除された後、次のフルメンテナンスサイクル中に削除されます。
- Container Storage Interface (CSI): アーティファクトは、バックアップが削除されると直ちに削除されます。
- Kopia: アーティファクトは、バックアップが削除されてから、Kopia リポジトリーのフルメンテナンスサイクルが 3 回実行された後に削除されます。
1.7.5.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>
1.7.5.2. Velero CLI を使用してバックアップを削除する リンクのコピーリンクがクリップボードにコピーされました!
Velero CLI を使用してバックアップを削除できます。
前提条件
- アプリケーションのバックアップを実行した。
- Velero CLI がダウンロード済みであり、クラスター内の Velero バイナリーにアクセスできる。
手順
バックアップを削除するには、次の Velero コマンドを実行します。
$ velero backup delete <backup_name> -n openshift-adp1 - 1
- バックアップの名前を指定します。
1.7.5.3. Kopia リポジトリーのメンテナンスについて リンクのコピーリンクがクリップボードにコピーされました!
Kopia リポジトリーのメンテナンスには次の 2 種類があります。
- クイックメンテナンス
- インデックス Blob の数 (n) を抑えるために 1 時間ごとに実行されます。インデックスの数が多いと、Kopia 操作のパフォーマンスに悪影響が及びます。
- 同じメタデータの別のコピーが存在することを確認してから、リポジトリーからメタデータを削除します。
- フルメンテナンス
- 不要になったリポジトリーコンテンツのガベージコレクションを実行するために、24 時間ごとに実行されます。
-
フルメンテナンスのタスクである
snapshot-gcが、スナップショットマニフェストからアクセスできなくなったすべてのファイルとディレクトリーリストを検索し、それらを削除済みとしてマークします。 - フルメンテナンスは、クラスター内でアクティブなすべてのスナップショット内のすべてのディレクトリーをスキャンする必要があるため、リソースを大量に消費する操作です。
1.7.5.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 時間かかると予想されます。
1.7.5.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
- 前のステップのバックアップリポジトリーの名前を指定します。