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

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

04/23/2024 共同作成者

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

手順

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

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

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

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

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

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

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

復元されたアプリの名前を指定します。
リストアするアプリケーションのデスティネーションクラスタを選択します。

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

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

「 * 次へ * 」を選択します。
アプリの復元に使用するスナップショットまたはバックアップを選択します。
「 * 次へ * 」を選択します。
次のいずれかを選択します。
- 元のストレージクラスを使用してリストア：ターゲットクラスタに存在しない場合を除き、元々関連付けられていたストレージクラスがアプリケーションで使用されます。この場合、クラスタのデフォルトのストレージクラスが使用されます。
- 別のストレージクラスを使用したリストア：ターゲットクラスタに存在するストレージクラスを選択してください。元々関連付けられていたストレージクラスに関係なく、すべてのアプリケーションボリュームが、リストアの一環としてこの別のストレージクラスに移動されます。
「 * 次へ * 」を選択します。

フィルタするリソースを選択：
- すべてのリソースを復元：元のアプリケーションに関連付けられているすべてのリソースを復元します。
- リソースのフィルタ:元のアプリケーションリソースのサブセットを復元するルールを指定します。
  1. リストアされたアプリケーションにリソースを含めるか除外するかを選択します。
  2. または[除外ルールを追加]*のいずれかを選択し、アプリケーションのリストア時に正しいリソースをフィルタするようにルールを設定します。設定が正しくなるまで、ルールを編集したり削除したり、ルールを再度作成したりすることができます。
    
    includeルールとexcludeルールの設定については、を参照してくださいアプリケーションのリストア中にリソースをフィルタリングします。
「 * 次へ * 」を選択します。
リストア処理の詳細をよく確認し、プロンプトが表示されたら「restore」と入力して*[リストア]*を選択します。

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

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

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

手順

カスタムリソース（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[]

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

CRを使用したバックアップから元のネームスペースへのリストア

手順

カスタムリソース（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[]

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

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

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

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

手順

カスタムリソース（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[]

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

CRを使用したSnapshotから元のネームスペースへのリストア

手順

カスタムリソース（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[]

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

結果

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

データ保護処理（クローン、バックアップ、またはリストア）が完了して永続ボリュームのサイズを変更したあと、Web UIに新しいボリュームサイズが表示されるまでに最大20分かかります。データ保護処理にかかる時間は数分です。また、ストレージバックエンドの管理ソフトウェアを使用してボリュームサイズの変更を確認できます。

ネームスペースの名前/ IDまたはネームスペースのラベルでネームスペースの制約を受けているメンバーユーザは、同じクラスタの新しいネームスペース、または組織のアカウントに含まれる他のクラスタにアプリケーションをクローニングまたはリストアできます。ただし、同じユーザが、クローニングまたはリストアされたアプリケーションに新しいネームスペースからアクセスすることはできません。クローン処理またはリストア処理で新しいネームスペースが作成されたあと、アカウントの管理者/所有者はメンバーユーザアカウントを編集し、影響を受けるユーザのロールの制約を更新して、新しいネームスペースへのアクセスを許可できます。