バックアップの復元—ArcGIS Enterprise on Kubernetes

ArcGIS Enterprise Manager を使用して、バックアップから ArcGIS Enterprise on Kubernetes 組織サイトを復元できます。すべての構成データ、設定、サービス、およびインフラストラクチャーオブジェクトが復元されます。登録済みデータストア内のデータを参照するサービスは再作成されます。

組織が管理 API を介してボリュームを使用してサービスを構成しており、バックアップが作成されたためにボリュームが変更された場合は、復元を実行する前に、Released 状態にあるすべての関連する永続ボリューム (PVs) にパッチを適用して Available にします。これを完了していない場合、サービスは更新に失敗する可能性があり、PVC が既存の PV にバインドした後に再起動する必要が生じます。関連付けられている PV にパッチを適用するには、次のコマンドを実行します。

kubectl patch pv <pv name> -p '{"spec": {"claimRef": {"uid": null}}}'

バックアップの復元方法は、復元したいバックアップと互換性のある既存の組織が存在するかどうかによって異なります。

インプレースプロセスによるバックアップの復元

インプレース復元プロセスは、ArcGIS Enterprise on Kubernetes のアンデプロイと再デプロイを行わずに、バックアップから組織を復元するために使用されます。データ破損またはデータ損失が発生しても、バックアップが既存の組織と互換性があれば、インプレース復元プロセスを使用できます。元の組織サイトはすべてのバックアップの記録を維持しており、ArcGIS Enterprise Manager を使用して、バックアップの 1 つから復元することができます。

インプレースプロセスを使用してバックアップを復元するには、次の手順を実行します:

組織の管理者として ArcGIS Enterprise Manager にサインインします。
[バックアップ] ボタンをクリックします。
バックアップページから、復元先のバックアップを決定し、オプションボタンをクリックします。
[元に戻す] をクリックします。
バックアップの作成に使用された暗号化パスフレーズを入力します。
[元に戻す] をクリックします。

復元操作を開始すると、この操作を管理するジョブが作成され、復元ページが表示され、復元操作の進行状況が表示されます。組織サイトは、バックアップが作成された時点に復元され、復元が完了するまでアクセスできなくなります。

インプレース復元プロセスでは、オブジェクトデータストア、リレーショナルデータストア、および時空間データストアのポッドの配置ポリシーは、現在の構成から保持され、バックアップからは無視されます。これにより、データストアの StatefulSets の再起動を回避できるとともに、復元操作中に現在のクラスター構成との潜在的な競合も防ぐことができます。システム、ユーティリティー、およびユーザーが公開したサービスで、デプロイメントが正常に更新されない場合、デプロイメント ID が結果に記録され、警告付きで正常に完了したことが操作によって報告されます。管理者は、復元操作の後にそれぞれの配置ポリシーを修正する必要があります。

アウトオブプレースプロセスによるバックアップの復元

元の組織にアクセスできない場合、またはバックアップが現在の組織とは異なるバージョンや、別のリレーショナルストアタイプで作成された場合に、アウトオブプレースの復元プロセスを使用してバックアップを復元できます。

アウトオブプレース復元プロセスを使用する前に、既存の組織をアンデプロイし、新しい組織を再デプロイします。新しいバックアップストアを登録するときにラベルセレクターの一部として使用できるラベルが元の永続ボリューム (PV) に含まれていることを確認します。また、ソースとターゲットの環境で次の設定が同一であることも確認する必要があります。

リレーショナルストアのストレージタイプ (永続ボリュームまたはクラウドサービス)
ArcGIS Enterprise on Kubernetes バージョン
完全修飾ドメイン名 (FQDN) とコンテキストパス (https://dnsalias.domain.com/context)
Kubernetes 名前空間 (arcgis)
Kubernetes クラスタードメイン (cluster.local)
Kubernetes サービス DNS の接尾辞 (svc.cluster.local)
FSGroup および補足グループ ID (カスタム値を使用して配置されている場合)

注意:

これらの設定は、デプロイメント時に指定しました。

既存の PV の静的バインド用の準備

ArcGIS Enterprise on Kubernetes をアンデプロイすると、元の PV のステータスはリリース済みに設定されます。新しい組織サイトが作成されるまで、既存の PV にパッチをあてないでください。新しい組織サイトが利用可能になったら、PV の claimRef を削除して、ラベルセレクターを使用してバインドできるようにする必要があります。適切なラベルを追加して、PV が新しい組織サイトの PVC でバインドできるようにするには、次の手順を実行します。

kubectl を使用して、以前のバックアップストアに使用された PV を特定します。
```
kubectl get pv
```
kubectl を使用して PV の仕様を取得します。
```
kubectl get pv <PV> -o yaml
```
これらの値は、バックアップストアの登録時に参照として使用できます。
注意:
前のバックアップストア名を忘れた場合は、PV の spec.claimRef.name を分解することで取得できます。たとえば、PV の spec.claimRef.name が data-volume-arcgis-backup-store-backups-111-backups-main-0 の場合、前のバックアップストア名は backups-111 になります。
kubectl を使用して、ラベルを PV に割り当てます。
これは、PV を新しいバックアップストアポッドにバインドするために使用されます。
```
kubectl label pv <pv name> <key>=<value>
```
たとえば、"arcgis/purpose":"backups" をラベルセレクターとして使用します。
```
kubectl label pv <pv name> arcgis/purpose=backups
```
PV にパッチを適用して、uid の値を claimRef フィールドから削除します。これは、新しいバックアップストアポッドにバインドできるようにするためです。
```
kubectl patch pv <pv name> -p '{"spec":{"claimRef":{"uid":null}}}'
```

別のバックアップストアがまだ存在しない場合、バックアップストアを登録します。

ステージングの場所およびバックアップストアを登録していない場合は、次の手順を実行して、新しいバックアップストアを登録し、それを既存の PV にバインドします。

組織の管理者として ArcGIS Enterprise Manager にサインインします。
[バックアップ] ボタンをクリックします。
バックアップページから、[バックアップストアの登録] をクリックします。
静的プロビジョニングを使用する場合は、ステージング場所の設定の定義に関する管理 API リファレンスをご参照ください。動的プロビジョニングを使用する場合は、ステージング場所に関する次の情報を入力してください。
- [サイズ (GiB)] - ステージング場所の PV のサイズを定義します。最小サイズは 16 GiB で、各ストアのバックアップを格納するのに十分に大きなサイズである必要があります。
- [ストレージクラス名] - ストレージクラス名を定義します。
登録対象のバックアップストアのタイプを選択します。
- Amazon S3
- Azure Blob
- Google クラウドストレージ
- システム管理ストレージ
1. Amazon S3 を使用している場合は、次の情報を入力します。
  - [バックアップストア名] - バックアップストアの名前。名前に使用できるのは、小文字のアルファベット、数字、およびハイフンだけで、先頭または末尾にハイフンを使用してはいけません。
  - [バケット名] - バックアップを保存するために Amazon S3 で作成されたバケットの名前。
  - [領域] - バケットが作成された領域を指定します。
  - [認証タイプ] - [アクセスキー] または [IAM ロール] を選択します。
  - 認証タイプとしてアクセスキーを使用するなら、次の情報を入力します。
    [アクセスキー] - IAM ユーザーのアクセスキーを貼り付けるか、入力します。
    [シークレットキー] - IAM ユーザーのシークレットキーを貼り付けるか、入力します。
2. Azure Blob を使用している場合は、次の情報を入力します。
  - [バックアップストア名] - バックアップストアの名前。名前に使用できるのは、小文字のアルファベット、数字、およびハイフンだけで、先頭または末尾にハイフンを使用してはいけません。
  - [コンテナー名] - バックアップ保存のために Azure で作成されたコンテナーの名前。
  - [ストレージアカウント] - コンテナーの上位に位置する親ストレージアカウントの名前。
  - [認証タイプ] - [ストレージアカウントキー] または [マネージド ID] を選択します。
  - 認証タイプとしてストレージアカウントキーを使用するなら、次の情報を入力します。
    [アカウントキー] - 関連付けられているストレージアカウントのプライマリーアカウントキーまたはセカンダリーアカウントキーを貼り付けるか、入力します。
3. Google Cloud ストレージを使用している場合は、次の情報を入力します。
  - [バックアップストア名] - バックアップストアの名前。名前に使用できるのは、小文字のアルファベット、数字、およびハイフンだけで、先頭または末尾にハイフンを使用してはいけません。
  - [バケット名] - バックアップを保存するために Google Cloud Storage で作成されたバケットの名前。
  - [アクセスキー] - サービスアカウントのアクセスキーを貼り付けるか、入力します。
  - [シークレットキー] - サービスアカウントのシークレットキーを貼り付けるか、入力します。
4. システム管理ストレージを使用するなら、次の情報を入力します。
  - [ボリュームの種類] - 既存の PV にバインドするには、[静的] を選択します。管理者は、バインドに必要なラベルが PV に含まれ、バインドできることを確認します。
  - [バックアップストア名] - バックアップストアの名前を定義します。これは、以前に登録されたバックアップストアの名前と一致する必要があります。この名前に使用できるのは、小文字のアルファベット、数字、およびハイフンだけで、先頭または末尾にハイフンを使用してはいけません。
  - [サイズ (GiB)] - バックアップストアの PV のサイズを定義します。最小サイズは 32 GiB で、静的バインドを使用する場合は、この値が既存の PV のサイズと一致する必要があります。この値が既存の PV のサイズよりも大きい場合、PVC は PV とバインドしません。
  - [ストレージクラス名] - ストレージクラスは既存の PV のストレージクラスと一致する必要があります。
  - [ラベルセレクター] - 静的プロビジョニングに必要で、ラベルは既存の PV のラベルと一致する必要があります。
[登録] をクリックします。

注意:

ストレージクラスが定義されていない事前作成済みの PV にバインドする場合は、ストレージクラス名を空白のままにしてください。クラスター内にデフォルトのストレージクラスが構成されている場合、DefaultStorageClass アドミッションコントローラーによってデフォルトのストレージクラスが追加され、PVC がバインドされないようにします。この場合、管理者は PV にストレージクラスの指定を追加するか、デフォルトのストレージクラスの構成を削除する必要があります。

バックアップストアが登録されると、バックアップストア内の既存のバックアップはすべてバックアップページにリストされますが、復元できるのは同じリリースのバックアップのみになります。

別のバックアップストアがすでに存在する場合、バックアップストアを登録します。

ステージングの場所およびバックアップストアが登録済みの場合は、次の手順を実行します。

組織の管理者として ArcGIS Enterprise Manager にサインインします。
[バックアップ] ボタンをクリックします。
バックアップページから、[バックアップストア] をクリックします。
[ストアを登録] をクリックします。
登録対象のバックアップストアのタイプを選択します。
- Amazon S3
- Azure Blob
- Google クラウドストレージ
- システム管理ストレージ
1. Amazon S3 を使用している場合は、次の情報を入力します。
  - [バックアップストア名] - バックアップストアの名前。名前に使用できるのは、小文字のアルファベット、数字、およびハイフンだけで、先頭または末尾にハイフンを使用してはいけません。
  - [バケット名] - バックアップを保存するために Amazon S3 で作成されたバケットの名前。
  - [領域] - バケットが作成された領域を指定します。
  - [認証タイプ] - [アクセスキー] または [IAM ロール] を選択します。
  - 認証タイプとしてアクセスキーを使用するなら、次の情報を入力します。
    [アクセスキー] - IAM ユーザーのアクセスキーを貼り付けるか、入力します。
    [シークレットキー] - IAM ユーザーのシークレットキーを貼り付けるか、入力します。
2. Azure Blob を使用している場合は、次の情報を入力します。
  - [バックアップストア名] - バックアップストアの名前。名前に使用できるのは、小文字のアルファベット、数字、およびハイフンだけで、先頭または末尾にハイフンを使用してはいけません。
  - [コンテナー名] - バックアップ保存のために Azure で作成されたコンテナーの名前。
  - [ストレージアカウント] - コンテナーの上位に位置する親ストレージアカウントの名前。
  - [認証タイプ] - [ストレージアカウントキー] または [マネージド ID] を選択します。
  - 認証タイプとしてストレージアカウントキーを使用するなら、次の情報を入力します。
    [アカウントキー] - 関連付けられているストレージアカウントのプライマリーアカウントキーまたはセカンダリーアカウントキーを貼り付けるか、入力します。
3. Google Cloud ストレージを使用している場合は、次の情報を入力します。
  - [バックアップストア名] - バックアップストアの名前。名前に使用できるのは、小文字のアルファベット、数字、およびハイフンだけで、先頭または末尾にハイフンを使用してはいけません。
  - [バケット名] - バックアップを保存するために Google Cloud Storage で作成されたバケットの名前。
  - [アクセスキー] - サービスアカウントのアクセスキーを貼り付けるか、入力します。
  - [シークレットキー] - サービスアカウントのシークレットキーを貼り付けるか、入力します。
4. システム管理ストレージを使用するなら、次の情報を入力します。
  - [ボリュームの種類] - 既存の PV にバインドするには、[静的] を選択します。管理者は、バインドに必要なラベルが PV に含まれ、バインドできることを確認します。
  - [バックアップストア名] - バックアップストアの名前を定義します。これは、以前に登録されたバックアップストアの名前と一致する必要があります。この名前に使用できるのは、小文字のアルファベット、数字、およびハイフンだけで、先頭または末尾にハイフンを使用してはいけません。
  - [サイズ (GiB)] - バックアップストアの PV のサイズを定義します。最小サイズは 32 GiB で、静的バインドを使用する場合は、この値が既存の PV のサイズと一致する必要があります。この値が既存の PV のサイズよりも大きい場合、PVC は PV とバインドしません。
  - [ストレージクラス名] - ストレージクラスは既存の PV のストレージクラスと一致する必要があります。
  - [ラベルセレクター] - 静的プロビジョニングに必要で、ラベルは既存の PV のラベルと一致する必要があります。
[登録] をクリックします。

注意: