Skip to main content
日本語は機械翻訳による参考訳です。内容に矛盾や不一致があった場合には、英語の内容が優先されます。

Trident保護を使用したアプリケーションの保護

共同作成者 netapp-mwallis netapp-shwetav netapp-aruldeepa
PDF

自動保護ポリシーまたはアドホックベースでスナップショットとバックアップを作成することで、Trident protectで管理されているすべてのアプリケーションを保護できます。

メモ データ保護処理中にファイルシステムをフリーズおよびフリーズ解除するようにTrident保護を設定できます。"Trident protectを使用したファイルシステムのフリーズ設定の詳細"です。

オンデマンドスナップショットを作成します

オンデマンド Snapshot はいつでも作成できます。

メモ クラスタ対象のリソースがアプリケーション定義で明示的に参照されている場合、またはいずれかのアプリケーションネームスペースへの参照がある場合、バックアップ、Snapshot、またはクローンに含まれます。
CRを使用したスナップショットの作成
手順

  1. カスタムリソース（CR）ファイルを作成し、という名前を付け `trident-protect-snapshot-cr.yaml`ます。

  2. 作成したファイルで、次の属性を設定します。

    • * metadata.name*:（required）このカスタムリソースの名前。環境に適した一意の適切な名前を選択します。

    • * spec.applicationRef *：スナップショットを作成するアプリケーションのKubernetes名。

    • * spec.appVaultRef *：（required）スナップショットの内容（メタデータ）を格納するAppVaultの名前。

    • * spec.reclaimPolicy *：（_Optional _）スナップショットCRが削除されたときのスナップショットのAppArchiveの動作を定義します。つまり、に設定しても `Retain`Snapshotは削除されます。有効なオプション：

      • Retain （デフォルト）

      • Delete

        ---
apiVersion: protect.trident.netapp.io/v1
kind: Snapshot
metadata:
  namespace: my-app-namespace
  name: my-cr-name
spec:
  applicationRef: my-application
  appVaultRef: appvault-name
  reclaimPolicy: Delete

  3. ファイルに正しい値を入力したら trident-protect-snapshot-cr.yaml 、CRを適用します。

    kubectl apply -f trident-protect-snapshot-cr.yaml
CLIを使用したスナップショットの作成
手順

  1. スナップショットを作成し、括弧内の値を環境からの情報に置き換えます。例：

    tridentctl-protect create snapshot <my_snapshot_name> --appvault <my_appvault_name> --app <name_of_app_to_snapshot> -n <application_namespace>

オンデマンドバックアップの作成

アプリはいつでもバックアップできます。

メモ クラスタ対象のリソースがアプリケーション定義で明示的に参照されている場合、またはいずれかのアプリケーションネームスペースへの参照がある場合、バックアップ、Snapshot、またはクローンに含まれます。
作業を開始する前に

長時間実行されるs3バックアップ処理には、AWSセッショントークンの有効期限が十分であることを確認してください。バックアップ処理中にトークンの有効期限が切れた場合、処理が失敗することがあります。

CRを使用したバックアップの作成
手順

  1. カスタムリソース（CR）ファイルを作成し、という名前を付け `trident-protect-backup-cr.yaml`ます。

  2. 作成したファイルで、次の属性を設定します。

    • * metadata.name*:（required）このカスタムリソースの名前。環境に適した一意の適切な名前を選択します。

    • * spec.applicationRef *：（required）バックアップするアプリケーションのKubernetes名。

    • * spec.appVaultRef *：（required）バックアップ内容を格納するAppVaultの名前。

    • *spec.DataMover *:(Optional)バックアップ操作に使用するバックアップツールを示す文字列。有効な値（大文字と小文字が区別されます）：

      • Restic

      • Kopia （デフォルト）

    • * spec.reclaimPolicy *：（_Optional _）要求から解放されたバックアップの処理を定義します。有効な値：

      • Delete

      • Retain （デフォルト）

    • spec.snapshotRef: (オプション): バックアップのソースとして使用するスナップショットの名前。指定しない場合は、一時Snapshotが作成されてバックアップされます。

    • metadata.annotations.protect.trident.netapp.io/full-backup: (オプション) このアノテーションは、バックアップを非増分にするかどうかを指定するために使用されます。デフォルトでは、すべてのバックアップは増分バックアップです。ただし、このアノテーションがに設定されている場合、 `true`バックアップは非増分になります。指定しない場合、バックアップはデフォルトの増分バックアップ設定に従います。リストアに伴うリスクを最小限に抑えるために、フルバックアップを定期的に実行してから、フルバックアップの間に増分バックアップを実行することを推奨します。

      YAMLの例：

    ---
apiVersion: protect.trident.netapp.io/v1
kind: Backup
metadata:
  namespace: my-app-namespace
  name: my-cr-name
  annotations:
    protect.trident.netapp.io/full-backup: "true"
spec:
  applicationRef: my-application
  appVaultRef: appvault-name
  dataMover: Kopia

  3. ファイルに正しい値を入力したら trident-protect-backup-cr.yaml 、CRを適用します。

    kubectl apply -f trident-protect-backup-cr.yaml
CLIを使用したバックアップの作成
手順

  1. バックアップを作成します。角かっこ内の値は、使用している環境の情報に置き換えます。例：

    tridentctl-protect create backup <my_backup_name> --appvault <my-vault-name> --app <name_of_app_to_back_up> --data-mover <Kopia_or_Restic> -n <application_namespace>

    オプションで、フラグを使用して、バックアップを非増分にするかどうかを指定できます --full-backup。デフォルトでは、すべてのバックアップは増分バックアップです。このフラグを使用すると、バックアップは非増分になります。リストアに伴うリスクを最小限に抑えるために、フルバックアップを定期的に実行してから、フルバックアップの間に増分バックアップを実行することを推奨します。

データ保護スケジュールを作成

保護ポリシーは、定義されたスケジュールでスナップショット、バックアップ、またはその両方を作成することによってアプリを保護します。スナップショットとバックアップを時間ごと、日ごと、週ごと、月ごとに作成するように選択でき、保持するコピーの数を指定できます。 full-backup-rule アノテーションを使用して、増分以外の完全バックアップをスケジュールできます。デフォルトでは、すべてのバックアップは増分バックアップになります。定期的に完全バックアップを実行し、その間に増分バックアップを実行すると、復元に関連するリスクを軽減できます。

メモ

  • スナップショットのスケジュールを作成するには、以下を設定します。 `backupRetention`ゼロにし、 `snapshotRetention`ゼロより大きい値にします。設定 `snapshotRetention`ゼロに設定すると、スケジュールされたバックアップではスナップショットが作成されますが、それらは一時的なものであり、バックアップが完了するとすぐに削除されます。

  • クラスタ対象のリソースがアプリケーション定義で明示的に参照されている場合、またはいずれかのアプリケーションネームスペースへの参照がある場合、バックアップ、Snapshot、またはクローンに含まれます。
CRを使用したスケジュールの作成
手順

  1. カスタムリソース（CR）ファイルを作成し、という名前を付け `trident-protect-schedule-cr.yaml`ます。

  2. 作成したファイルで、次の属性を設定します。

    • * metadata.name*:（required）このカスタムリソースの名前。環境に適した一意の適切な名前を選択します。

    • *spec.DataMover *:(Optional)バックアップ操作に使用するバックアップツールを示す文字列。有効な値（大文字と小文字が区別されます）：

      • Restic

      • Kopia （デフォルト）

    • * spec.applicationRef *：バックアップするアプリケーションのKubernetes名。

    • * spec.appVaultRef *：（required）バックアップ内容を格納するAppVaultの名前。

    • spec.backupRetention: 保持するバックアップの数。ゼロは、バックアップを作成しないことを示します (スナップショットのみ)。

    • * spec.snapshotRetention *：保持するSnapshotの数。ゼロは、スナップショットを作成しないことを示します。

    • * spec.granularity*:スケジュールを実行する頻度。指定可能な値と必須の関連フィールドは次のとおりです。

      • Hourly（指定する必要があります spec.minute）

      • Daily（指定する必要があります spec.minute`そして `spec.hour）

      • Weekly（指定する必要があります spec.minute, spec.hour、 そして spec.dayOfWeek）

      • Monthly（指定する必要があります spec.minute, spec.hour、 そして spec.dayOfMonth）

      • Custom

    • spec.dayOfMonth: (オプション) スケジュールを実行する月の日付 (1 - 31)。粒度が「」に設定されている場合、このフィールドは必須です。 Monthly 。値は文字列として提供する必要があります。

    • spec.dayOfWeek: (オプション) スケジュールを実行する曜日 (0 - 7)。値 0 または 7 は日曜日を示します。粒度が「」に設定されている場合、このフィールドは必須です。 Weekly 。値は文字列として提供する必要があります。

    • spec.hour: (オプション) スケジュールを実行する時刻 (0 - 23)。粒度が「」に設定されている場合、このフィールドは必須です。 Daily 、 Weekly 、 または Monthly。値は文字列として提供する必要があります。

    • spec.minute: (オプション) スケジュールを実行する分 (0 - 59)。粒度が「」に設定されている場合、このフィールドは必須です。 Hourly 、 Daily 、 Weekly 、 または Monthly。値は文字列として提供する必要があります。

    • * metadata.annotations.protect.trident.netapp.io/full-backup-rule*:（Optional）このアノテーションは、フルバックアップのスケジュールを設定するルールを指定する場合に使用します。に設定して定期的なフルバックアップを実行することも、要件に応じてカスタマイズすることもできます always。たとえば、日単位を選択した場合は、フルバックアップを実行する曜日を指定できます。

      バックアップとスナップショットのスケジュールの YAML の例:

      ---
apiVersion: protect.trident.netapp.io/v1
kind: Schedule
metadata:
  namespace: my-app-namespace
  name: my-cr-name
  annotations:
    protect.trident.netapp.io/full-backup-rule: "Monday,Thursday"
spec:
  dataMover: Kopia
  applicationRef: my-application
  appVaultRef: appvault-name
  backupRetention: "15"
  snapshotRetention: "15"
  granularity: Daily
  hour: "0"
  minute: "0"

      スナップショットのみのスケジュールの YAML の例:

    ---
apiVersion: protect.trident.netapp.io/v1
kind: Schedule
metadata:
  namespace: my-app-namespace
  name: my-snapshot-schedule
spec:
  applicationRef: my-application
  appVaultRef: appvault-name
  backupRetention: "0"
  snapshotRetention: "15"
  granularity: Daily
  hour: "2"
  minute: "0"

  3. ファイルに正しい値を入力したら trident-protect-schedule-cr.yaml 、CRを適用します。

    kubectl apply -f trident-protect-schedule-cr.yaml
CLIを使用してスケジュールを作成する
手順

  1. 保護スケジュールを作成し、角かっこ内の値を環境からの情報に置き換えます。例：

    メモ を使用すると、このコマンドの詳細なヘルプ情報を表示できます tridentctl-protect create schedule --help。 
    tridentctl-protect create schedule <my_schedule_name> --appvault <my_appvault_name> --app <name_of_app_to_snapshot> --backup-retention <how_many_backups_to_retain> --data-mover <Kopia_or_Restic> --day-of-month <day_of_month_to_run_schedule> --day-of-week <day_of_month_to_run_schedule> --granularity <frequency_to_run> --hour <hour_of_day_to_run> --minute <minute_of_hour_to_run> --recurrence-rule <recurrence> --snapshot-retention <how_many_snapshots_to_retain> -n <application_namespace> --full-backup-rule <string>

    定期的なフルバックアップのフラグをに always`設定することも、要件に基づいてカスタマイズすることもできます `--full-backup-rule。たとえば、日単位を選択した場合は、フルバックアップを実行する曜日を指定できます。たとえば、月曜日と木曜日にフルバックアップをスケジュールする場合に使用し `--full-backup-rule "Monday,Thursday"`ます。

    スナップショットのみのスケジュールの場合は、 --backup-retention 0 0より大きい値を指定する --snapshot-retention。

Snapshot を削除します

不要になったスケジュール済みまたはオンデマンドの Snapshot を削除します。

手順

  1. Snapshotに関連付けられているSnapshot CRを削除します。

    kubectl delete snapshot <snapshot_name> -n my-app-namespace

バックアップを削除します

不要になったスケジュール済みまたはオンデマンドのバックアップを削除します。

メモ 回収ポリシーが設定されていることを確認する `Delete`オブジェクトストレージからすべてのバックアップデータを削除します。このポリシーのデフォルト設定は `Retain`偶発的なデータ損失を防ぐためです。ポリシーが変更されていない場合は、 `Delete`バックアップ データはオブジェクト ストレージに残り、手動で削除する必要があります。
手順

  1. バックアップに関連付けられているバックアップCRを削除します。

    kubectl delete backup <backup_name> -n my-app-namespace

バックアップ処理のステータスの確認

コマンドラインを使用して、実行中、完了、または失敗したバックアップ処理のステータスを確認できます。

手順

  1. 次のコマンドを使用してバックアップ処理のステータスを取得し、角かっこ内の値を環境の情報に置き換えます。

    kubectl get backup -n <namespace_name> <my_backup_cr_name> -o jsonpath='{.status}'

azure-anf-files NetApp（ANF）処理のバックアップとリストアを実現

Trident protectをインストールしている場合はNetApp、Trident 24.06より前に作成されたazure-lun-filesストレージクラスを使用するストレージバックエンドに対して、スペース効率に優れたバックアップおよびリストア機能を有効にすることができます。この機能はNFSv4ボリュームで機能し、容量プールから追加のスペースを消費することはありません。

作業を開始する前に

次の点を確認します。

  • Trident protectをインストールしておきます。

  • Trident保護でアプリケーションを定義しました。この手順を完了するまで、このアプリケーションの保護機能は制限されます。

  • ストレージバックエンドのデフォルトのストレージクラスとしてを選択しまし azure-netapp-files た。

構成手順用に展開

  1. Trident 24.10にアップグレードする前にANFボリュームを作成した場合は、Tridentで次の手順を実行します。

    1. アプリケーションに関連付けられているNetAppファイルベースの各PVのSnapshotディレクトリを有効にします。

      tridentctl update volume <pv name> --snapshot-dir=true -n trident

    2. 関連付けられている各PVに対してSnapshotディレクトリが有効になっていることを確認します。

      tridentctl get volume <pv name> -n trident -o yaml | grep snapshotDir

      応答：

    snapshotDirectory: "true"

    +
    Snapshotディレクトリが有効になっていない場合、Trident保護は通常のバックアップ機能を選択します。この機能は、バックアッププロセス中に一時的に容量プールのスペースを消費します。この場合は、バックアップするボリュームと同じサイズの一時ボリュームを作成するための十分なスペースが容量プールに確保されていることを確認してください。

結果

これで、Trident保護を使用したアプリケーションのバックアップとリストアが可能になります。各PVCは、他のアプリケーションでバックアップおよびリストアに使用することもできます。