Skip to main content
すべてのクラウドプロバイダ
  • Amazon Web Services の
  • Google Cloud
  • Microsoft Azure
  • すべてのクラウドプロバイダ
日本語は機械翻訳による参考訳です。内容に矛盾や不一致があった場合には、英語の内容が優先されます。

アプリケーションのリストア

共同作成者
PDF

Astra Control を使用すると、スナップショットまたはバックアップからアプリケーションをリストアできます。同じクラスタにアプリケーションをリストアする場合、既存の Snapshot からのリストアは高速です。Astra Control UI またはを使用できます "Astra Control API" アプリを復元するには、

メモ リストアまたはクローン処理のあとに実行される実行フックにネームスペースフィルタを追加し、リストアまたはクローンのソースとデスティネーションが異なるネームスペースにある場合、ネームスペースフィルタはデスティネーションネームスペースにのみ適用されます。
作業を開始する前に

  • 最初にアプリケーションを保護する:アプリケーションを復元する前に、アプリケーションのスナップショットまたはバックアップを作成することを強くお勧めします。これにより、リストアに失敗した場合に、スナップショットまたはバックアップからクローンを作成できます。

  • デスティネーションボリュームの確認：別のストレージクラスにリストアする場合は、ストレージクラスで同じ永続ボリュームアクセスモード（ReadWriteManyなど）が使用されていることを確認してください。デスティネーションの永続ボリュームアクセスモードが異なると、リストア処理は失敗します。たとえば、ソースの永続ボリュームがRWXアクセスモードを使用している場合は、Azure Managed Disks、AWS EBS、Google Persistent Disk、など、RWXを提供できないデスティネーションストレージクラスを選択します `ontap-san`を指定すると、リストア処理は失敗します。原因は失敗します。永続ボリュームのアクセスモードの詳細については、を参照してください "Kubernetes" ドキュメント

  • 必要なスペースを確保するための計画：NetApp ONTAP ストレージを使用するアプリケーションのインプレースリストアを実行すると、リストアしたアプリケーションで使用されるスペースが2倍になることがあります。In Placeリストアを実行したあとに、リストアしたアプリケーションから不要なSnapshotを削除して、ストレージスペースを解放します。

  • サポートされるストレージクラスドライバ：Astra Controlでは、次のドライバに基づくストレージクラスを使用したバックアップのリストアがサポートされます。

    • ontap-nas

    • ontap-nas-economy

    • ontap-san

    • ontap-san-economy

  • （ontap-nas-economyドライバのみ）バックアップとリストア： ontap-nas-economy ドライバを使用して、 "ONTAPストレージバックエンドのSnapshotディレクトリが非表示になっている"。このディレクトリを非表示にしないと、アプリケーション（特にNFSv3を使用している場合）へのアクセスが失われる可能性があります。

注意

リソースを共有するアプリケーションでIn Placeリストア処理を実行すると、予期しない結果が生じる可能性があります。アプリケーション間で共有されているリソースは、いずれかのアプリケーションでインプレースリストアが実行されると置き換えられます。
手順

  1. 「 * アプリケーション」を選択し、アプリケーションの名前を選択します。

  2. [オプション]メニューの[操作]列で、*[リストア]*を選択します。

  3. リストアタイプを選択します。

    • 元のネームスペースにリストア：この手順 を使用して、アプリケーションを元のクラスタにインプレースでリストアします。

      1. アプリをインプレースで復元するために使用するスナップショットまたはバックアップを選択します。これにより、アプリは以前のバージョンに戻ります。

      2. 「 * 次へ * 」を選択します。

        メモ 以前に削除したネームスペースにリストアすると、同じ名前の新しいネームスペースがリストアプロセスで作成されます。以前に削除したネームスペースでアプリケーションを管理する権限を持つユーザは、新しく作成したネームスペースに手動で権限を復元する必要があります。

    • 新しい名前空間に復元：この手順 を使用して、アプリを別のクラスタまたはソースとは異なる名前空間で別のクラスタに復元します。この手順を使用して、アプリケーションを別のストレージクラスに移行することもできます。

      1. 復元されたアプリの名前を指定します。

      2. リストアするアプリケーションのデスティネーションクラスタを選択します。

      3. アプリケーションに関連付けられている各ソースネームスペースのデスティネーションネームスペースを入力します。

        メモ Astra Controlは、このリストアオプションの一部として新しいデスティネーションネームスペースを作成します。指定するデスティネーションネームスペースがデスティネーションクラスタに存在していないことを確認してください。

      4. 「 * 次へ * 」を選択します。

      5. アプリの復元に使用するスナップショットまたはバックアップを選択します。

      6. 「 * 次へ * 」を選択します。

      7. 次のいずれかを選択します。

        • 元のストレージクラスを使用してリストア：ターゲットクラスタに存在しない場合を除き、元 々 関連付けられていたストレージクラスがアプリケーションで使用されます。この場合、クラスタのデフォルトのストレージクラスが使用されます。

        • 別のストレージクラスを使用したリストア：ターゲットクラスタに存在するストレージクラスを選択してください。元 々 関連付けられていたストレージクラスに関係なく、すべてのアプリケーションボリュームが、リストアの一環としてこの別のストレージクラスに移動されます。

      8. 「 * 次へ * 」を選択します。

  4. フィルタするリソースを選択：

    • すべてのリソースを復元：元のアプリケーションに関連付けられているすべてのリソースを復元します。

    • リソースのフィルタ:元のアプリケーションリソースのサブセットを復元するルールを指定します。

      1. リストアされたアプリケーションにリソースを含めるか除外するかを選択します。

      2. または[除外ルールを追加]*のいずれかを選択し、アプリケーションのリストア時に正しいリソースをフィルタするようにルールを設定します。設定が正しくなるまで、ルールを編集したり削除したり、ルールを再度作成したりすることができます。

        メモ includeルールとexcludeルールの設定については、を参照してください アプリケーションのリストア中にリソースをフィルタリングします。

  5. 「 * 次へ * 」を選択します。

  6. リストア処理の詳細をよく確認し、プロンプトが表示されたら「restore」と入力して*[リストア]*を選択します。

[テクニカルプレビュー]カスタムリソース（CR）を使用したバックアップからのリストア

カスタムリソース（CR）ファイルを使用して、別のネームスペースまたは元のソースネームスペースにバックアップからデータをリストアできます。

CRを使用したバックアップからのリストア
手順

  1. カスタムリソース（CR）ファイルを作成して名前を付けます。 astra-control-backup-restore-cr.yaml。カッコ内の値を、Astra Controlの環境とクラスタの構成に合わせて更新します。

    • <CR_NAME>：このCR操作の名前。環境に適した適切な名前を選択します。

    • <APPVAULT_NAME>：バックアップコンテンツが格納されているAppVaultの名前。

    • <BACKUP_PATH>：バックアップコンテンツが格納されているAppVault内のパス。例：

      ONTAP-S3_1343ff5e-4c41-46b5-af00/backups/schedule-20231213023800_94347756-9d9b-401d-a0c3

    • <SOURCE_NAMESPACE>：リストア処理のソースネームスペース。

    • <DESTINATION_NAMESPACE>：リストア処理のデスティネーションネームスペース。

      apiVersion: astra.netapp.io/v1
kind: BackupRestore
metadata:
  name: <CR_NAME>
  namespace: astra-connector
spec:
  appVaultRef: <APPVAULT_NAME>
  appArchivePath: <BACKUP_PATH>
  namespaceMapping: [{"source": "<SOURCE_NAMESPACE>", "destination": "<DESTINATION_NAMESPACE>"}]

<stdin>の未解決ディレクティブ-include::../_include/selective-restore-cr.adoc[]

  1. データを入力した後、 astra-control-backup-restore-cr.yaml 正しい値を持つファイルを作成し、CRを適用します。

    kubectl apply -f astra-control-backup-restore-cr.yaml
CRを使用したバックアップから元のネームスペースへのリストア
手順

  1. カスタムリソース（CR）ファイルを作成して名前を付けます。 astra-control-backup-ipr-cr.yaml。カッコ内の値を、Astra Controlの環境とクラスタの構成に合わせて更新します。

    • <CR_NAME>：このCR操作の名前。環境に適した適切な名前を選択します。

    • <APPVAULT_NAME>：バックアップコンテンツが格納されているAppVaultの名前。

    • <BACKUP_PATH>：バックアップコンテンツが格納されているAppVault内のパス。例：

      ONTAP-S3_1343ff5e-4c41-46b5-af00/backups/schedule-20231213023800_94347756-9d9b-401d-a0c3
      apiVersion: astra.netapp.io/v1
kind: BackupInplaceRestore
metadata:
  name: <CR_NAME>
  namespace: astra-connector
spec:
  appVaultRef: <APPVAULT_NAME>
  appArchivePath: <BACKUP_PATH>

<stdin>の未解決ディレクティブ-include::../_include/selective-restore-cr.adoc[]

  1. データを入力した後、 astra-control-backup-ipr-cr.yaml 正しい値を持つファイルを作成し、CRを適用します。

    kubectl apply -f astra-control-backup-ipr-cr.yaml

[テクニカルプレビュー]カスタムリソースを使用したSnapshotからのリストア（CR）

カスタムリソース（CR）ファイルを使用して、スナップショットから別のネームスペースまたは元のソースネームスペースにデータをリストアできます。

CRを使用したSnapshotからのリストア
手順

  1. カスタムリソース（CR）ファイルを作成して名前を付けます。 astra-control-snapshot-restore-cr.yaml。カッコ内の値を、Astra Controlの環境とクラスタの構成に合わせて更新します。

    • <CR_NAME>：このCR操作の名前。環境に適した適切な名前を選択します。

    • <APPVAULT_NAME>：バックアップコンテンツが格納されているAppVaultの名前。

    • <BACKUP_PATH>：バックアップコンテンツが格納されているAppVault内のパス。例：

      ONTAP-S3_1343ff5e-4c41-46b5-af00/backups/schedule-20231213023800_94347756-9d9b-401d-a0c3

    • <SOURCE_NAMESPACE>：リストア処理のソースネームスペース。

    • <DESTINATION_NAMESPACE>：リストア処理のデスティネーションネームスペース。

      apiVersion: astra.netapp.io/v1
kind: SnapshotRestore
metadata:
  name: <CR_NAME>
  namespace: astra-connector
spec:
  appArchivePath: <BACKUP_PATH>
  appVaultRef: <APPVAULT_NAME>
  namespaceMapping: [{"source": "<SOURCE_NAMESPACE>", "destination": "<DESTINATION_NAMESPACE>"}]

<stdin>の未解決ディレクティブ-include::../_include/selective-restore-cr.adoc[]

  1. データを入力した後、 astra-control-snapshot-restore-cr.yaml 正しい値を持つファイルを作成し、CRを適用します。

    kubectl apply -f astra-control-snapshot-restore-cr.yaml
CRを使用したSnapshotから元のネームスペースへのリストア
手順

  1. カスタムリソース（CR）ファイルを作成して名前を付けます。 astra-control-snapshot-ipr-cr.yaml。カッコ内の値を、Astra Controlの環境とクラスタの構成に合わせて更新します。

    • <CR_NAME>：このCR操作の名前。環境に適した適切な名前を選択します。

    • <APPVAULT_NAME>：バックアップコンテンツが格納されているAppVaultの名前。

    • <BACKUP_PATH>：バックアップコンテンツが格納されているAppVault内のパス。例：

      ONTAP-S3_1343ff5e-4c41-46b5-af00/backups/schedule-20231213023800_94347756-9d9b-401d-a0c3
      apiVersion: astra.netapp.io/v1
kind: SnapshotInplaceRestore
metadata:
  name: <CR_NAME>
  namespace: astra-connector
spec:
  appArchivePath: <BACKUP_PATH>
  appVaultRef: <APPVAULT_NAME>

<stdin>の未解決ディレクティブ-include::../_include/selective-restore-cr.adoc[]

  1. データを入力した後、 astra-control-snapshot-ipr-cr.yaml 正しい値を持つファイルを作成し、CRを適用します。

    kubectl apply -f astra-control-snapshot-ipr-cr.yaml
結果

Astra Control は、指定した情報に基づいてアプリケーションを復元します。アプリケーションをインプレースでリストアした場合、既存の永続ボリュームのコンテンツが、リストアしたアプリケーションの永続ボリュームのコンテンツに置き換えられます。

メモ データ保護処理（クローン、バックアップ、またはリストア）が完了して永続ボリュームのサイズを変更したあと、Web UIに新しいボリュームサイズが表示されるまでに最大20分かかります。データ保護処理にかかる時間は数分です。また、ストレージバックエンドの管理ソフトウェアを使用してボリュームサイズの変更を確認できます。
メモ ネームスペースの名前/ IDまたはネームスペースのラベルでネームスペースの制約を受けているメンバーユーザは、同じクラスタの新しいネームスペース、または組織のアカウントに含まれる他のクラスタにアプリケーションをクローニングまたはリストアできます。ただし、同じユーザが、クローニングまたはリストアされたアプリケーションに新しいネームスペースからアクセスすることはできません。クローン処理またはリストア処理で新しいネームスペースが作成されたあと、アカウントの管理者/所有者はメンバーユーザアカウントを編集し、影響を受けるユーザのロールの制約を更新して、新しいネームスペースへのアクセスを許可できます。

アプリケーションのリストア中にリソースをフィルタリングします

にフィルタルールを追加できます "リストア" リストアされたアプリケーションに含める、またはリストアされたアプリケーションから除外する既存のアプリケーションリソースを指定する処理。指定した名前空間、ラベル、またはGVK（GroupVersionKind）に基づいて、リソースを含めたり除外したりできます。

対象と除外のシナリオについて詳しくは、こちらをご覧ください

  • 元のネームスペースを使用する包含ルールを選択した場合（インプレースリストア）：ルールで定義した既存のアプリケーションリソースは削除され、リストアに使用する選択したSnapshotまたはバックアップのリソースで置き換えられます。includeルールで指定しないリソースは変更されません。

  • 新しい名前空間を持つincludeルールを選択した場合：このルールを使用して、リストアされたアプリケーションで使用する特定のリソースを選択します。対象ルールに指定しないリソースは、リストアされたアプリケーションには含まれません。

  • 元のネームスペースを含む除外ルールを選択した場合（インプレースリストア）：除外するように指定したリソースはリストアされず、変更されません。除外するように指定しないリソースは、スナップショットまたはバックアップからリストアされます。対応するStatefulSetがフィルタリングされたリソースに含まれている場合、永続ボリューム上のすべてのデータが削除されて再作成されます。

  • 新しい名前空間を持つ除外ルールを選択した場合:このルールを使用して、リストアされたアプリケーションから削除する特定のリソースを選択します。除外するように指定しないリソースは、スナップショットまたはバックアップからリストアされます。

ルールには、includeまたはexcludeタイプがあります。リソースの包含と除外を組み合わせたルールは使用できません。

手順

  1. リソースをフィルタするように選択し、[アプリケーションのリストア]ウィザードで[含める]または[除外するルールを追加する]を選択したら、*[除外するルールを追加する]*を選択します。

    メモ Astra Controlで自動的に追加されるクラスタ対象のリソースを除外することはできません。

  2. フィルタルールを設定します。

    メモ ネームスペース、ラベル、またはGVKを少なくとも1つ指定する必要があります。フィルタルールを適用したあとに保持するリソースがあれば、リストアしたアプリケーションを正常な状態に保つのに十分であることを確認してください。

    1. ルールの特定のネームスペースを選択します。選択しない場合は、すべての名前空間がフィルタで使用されます。

      メモ アプリケーションに複数のネームスペースが含まれていた場合、新しいネームスペースにリストアすると、リソースが含まれていなくてもすべてのネームスペースが作成されます。

    2. （オプション）リソース名を入力します。

    3. （任意）ラベルセレクタ：を含めます "ラベルセレクタ" をクリックしてルールに追加します。ラベルセレクタは、選択したラベルに一致するリソースのみをフィルタリングするために使用されます。

    4. （オプション）[Use GVK (GroupVersionKind) set]を選択してリソースをフィルタリング*し、追加のフィルタリングオプションを指定します。

      メモ GVKフィルタを使用する場合は、バージョンと種類を指定する必要があります。

      1. （オプション）* Group *：ドロップダウンリストからKubernetes APIグループを選択します。

      2. 種類：ドロップダウンリストから、フィルタで使用するKubernetesリソースタイプのオブジェクトスキーマを選択します。

      3. バージョン：Kubernetes APIのバージョンを選択します。

  3. エントリに基づいて作成されたルールを確認します。

  4. 「 * 追加」を選択します。

    ヒント ルールを含むリソースと除外するリソースは必要なだけ作成できます。処理を開始する前に、リストアアプリケーションの概要にルールが表示されます。