Anthos clusters on bare metal はベアメタル向け Google Distributed Cloud（ソフトウェアのみ）になりました。詳細については、プロダクトの概要をご覧ください。

bmctl を使用したクラスタのバックアップと復元

このページでは、Google Distributed Cloud で作成したクラスタを bmctl を使用してバックアップおよび復元する方法について説明します。以下の手順は、Google Distributed Cloud でサポートされているすべてのクラスタタイプに適用されます。

bmctl のバックアップと復元のプロセスには永続ボリュームは含まれません。ローカルボリュームプロビジョナー（LVP）によって作成された Volume は、変更されません。

さらにサポートを必要とされる場合は、Cloud カスタマーケアにお問い合わせください。

クラスタをバックアップする

bmctl backup cluster コマンドは、etcd ストアからのクラスタ情報と、指定したクラスタの PKI 証明書を tar ファイルに追加します。etcd ストアは、すべてのクラスタデータ用の Kubernetes バッキングストアであり、クラスタの状態の管理に必要なすべての Kubernetes オブジェクトとカスタムオブジェクトを格納しています。PKI 証明書は TLS での認証に使用されます。このデータは、クラスタのコントロールプレーンか、高可用性（HA）デプロイメントのコントロールプレーンの 1 つからバックアップされます。

バックアップ tar ファイルには、サービスアカウントキーと SSH 認証鍵を含む機密性の高い認証情報が含まれています。バックアップファイルを安全な場所に保存してください。意図しないファイルの公開を防ぐため、Google Distributed Cloud のバックアッププロセスでは、メモリ内ファイルのみが使用されます。

クラスタは定期的にバックアップして、スナップショットデータが比較的新しくなるようにしてください。バックアップの頻度は、クラスタへの大きな変更の頻度が反映されるように調整します。

クラスタのバックアップに使用する bmctl バージョンは、管理するクラスタのバージョンと一致する必要があります。

クラスタをバックアップするには:

すべてのノードでの使用中の認証情報と SSH 接続で、クラスタが正常に動作していることを確認します。

バックアッププロセスの目的は、既知の正常な状態にあるクラスタをキャプチャして、重大な障害が発生した場合に運用を再開できるようにすることです。

次のコマンドを使用してクラスタを確認します。
```
bmctl check cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
```
次のように置き換えます。
- CLUSTER_NAME: バックアップを計画するクラスタの名前。
- ADMIN_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス。
次のコマンドを実行して、ターゲットクラスタが整合化状態ではないことを確認します。
```
kubectl describe cluster CLUSTER_NAME -n CLUSTER_NAMESPACE --kubeconfig ADMIN_KUBECONFIG
```
次のように置き換えます。
- CLUSTER_NAME: バックアップするクラスタの名前。
- CLUSTER_NAMESPACE: クラスタの名前空間。デフォルトでは、Google Distributed Cloud のクラスタ名前空間は、先頭に cluster- が付いたクラスタの名前です。たとえば、クラスタに test という名前を付けると、名前空間の名前は cluster-test のようになります。
- ADMIN_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス。

コマンド出力の Status セクションで、Conditions のタイプ Reconciling を確認します。

次の例に示すように、これらの Conditions のステータスが False であれば、クラスタが安定していてバックアップの準備ができていることを意味します。

...
Status:
  ...
  Cluster State:  Running
  ...
  Control Plane Node Pool Status:
    ...
    Conditions:
      Last Transition Time:  2023-11-03T16:37:15Z
      Observed Generation:   1
      Reason:                ReconciliationCompleted
      Status:                False
      Type:                  Reconciling
  ...

次のコマンドを実行してクラスタをバックアップします。
```
bmctl backup cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
```
次のように置き換えます。
- CLUSTER_NAME: バックアップするクラスタの名前。
- ADMIN_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス。
デフォルトでは、管理ワークステーションのワークスペースディレクトリ（デフォルトでは bmctl-workspace）に保存されたバックアップ tar ファイルです。tar ファイルの名前は CLUSTER_NAME_backup_TIMESTAMP.tar.gz です。ここで、CLUSTER_NAME はバックアップされるクラスタの名前、TIMESTAMP はバックアップが実行された日時です。たとえば、クラスタ名が testuser の場合、バックアップファイルの名前は testuser_backup_2006-01-02T150405Z0700.tar.gz のようになります。

バックアップファイルに異なる名前と場所を指定するには、--backup-file フラグを使用します。

バックアップファイルは 1 年経つと期限切れになり、クラスタ復元プロセスは期限切れのバックアップファイルでは動作しません。

クラスタを復元する

バックアップからのクラスタの復元は最後の手段です。クラスタにおいて重大な障害が発生したため、他の方法ではサービスに戻ることができない場合に使用する必要があります。たとえば、etcd データが破損している、etcd Pod がクラッシュループの状態にある場合に使用します。

バックアップ tar ファイルには、サービスアカウントキーと SSH 認証鍵を含む機密性の高い認証情報が含まれています。意図しないファイルの公開を防ぐため、Google Distributed Cloud の復元プロセスは、メモリ内ファイルのみを使用します。

クラスタの復元に使用する bmctl バージョンは、管理するクラスタのバージョンと一致している必要があります。

クラスタを復元するには:

バックアップを作成したときにクラスタで使用可能だったすべてのノードマシンが正しく動作し、到達可能であることを確認します。
ノード間の SSH 接続がバックアップ時に使用された SSH 認証鍵で動作することを確認します。

これらの SSH 認証鍵は、復元プロセスの一環として復元されます。
バックアップ時に使用されたサービスアカウントキーがまだ有効であることを確認します。

これらのサービスアカウントキーは、復元されたクラスタのために復元されます。
管理クラスタ、ハイブリッドクラスタ、またはスタンドアロンクラスタを復元するには、次のコマンドを実行します。
```
bmctl restore cluster -c CLUSTER_NAME --backup-file BACKUP_FILE
```
次のように置き換えます。
- CLUSTER_NAME: 復元するクラスタの名前。
- BACKUP_FILE: 使用しているバックアップファイルのパスと名前。
ユーザークラスタを復元するには、次のコマンドを実行します。
```
bmctl restore cluster -c CLUSTER_NAME --backup-file BACKUP_FILE \
    --kubeconfig ADMIN_KUBECONFIG
```
次のように置き換えます。
- CLUSTER_NAME: 復元するクラスタの名前。
- BACKUP_FILE: 使用しているバックアップファイルのパスと名前。
- ADMIN_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス。

復元プロセスの最後には、復元されたクラスタ用に新しい kubeconfig ファイルが生成されます。

トラブルシューティング

バックアップまたは復元のプロセスに問題がある場合は、以降のセクションが問題のトラブルシューティングに役立つことがあります。

さらにサポートが必要な場合は、Google サポートにお問い合わせください。

バックアップまたは復元中のメモリ不足

バックアップや復元プロセス中に、次のステップで自明または明確でないエラーメッセージが表示されることがあります。bmctl コマンドを実行するワークステーションの RAM が不足している場合は、バックアップまたは復元プロセスを行うためのメモリが不足している可能性があります。

Google Distributed Cloud のバージョン 1.13 以降では、バックアップコマンドで --use-disk パラメータを使用できます。ファイル権限を保持するために、このパラメータによってファイルの権限が変更されるため、コマンドを実行するユーザーは root ユーザーである必要があります（または sudo を使用します）。

復元中にファイルへの権限がない

復元タスクが正常に終了すると、ブートストラップの削除が、次のようなエラーメッセージで失敗する場合があります。

Error: failed to restore node config files: sftp: "Failure" (SSH_FX_FAILURE)

このエラーによって、復元に必要な一部のディレクトリが書き込みできない可能性があります。

Google Distributed Cloud バージョン 1.14 以降では、書き込み可能なディレクトリに関するエラーメッセージがより明確になっています。報告されたディレクトリが書き込み可能であることを確認し、必要に応じてディレクトリの権限を更新してください。

バックアップ後に SSH 鍵を更新すると、復元プロセスが中断される

バックアップが行われたに SSH 認証鍵が更新されると、復元プロセス中の SSH 関連のオペレーションが失敗することがあります。この場合、復元プロセスで新しい SSH 認証鍵は無効になります。

この問題を解決するには、元の SSH 認証鍵を一時的に追加してから、復元を実行します。復元プロセスが完了したら、SSH 鍵をローテーションできます。