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

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

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

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

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

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

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

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

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

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

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

次のコマンドを使用してクラスタを確認します。
```
bmctl check cluster -c CLUSTER_NAME
```
CLUSTER_NAME は、バックアップするクラスタの名前に置き換えます。
次のコマンドを実行して、ターゲットクラスタが整合化状態ではないことを確認します。
```
kubectl describe cluster CLUSTER_NAME -n CLUSTER_NAMESPACE
```
次のように置き換えます。
- CLUSTER_NAME: バックアップするクラスタの名前。
- CLUSTER_NAMESPACE: クラスタの名前空間。デフォルトでは、ベアメタル版 Anthos クラスタのクラスタ名前空間は、先頭に cluster- が付いたクラスタの名前です。たとえば、クラスタに test という名前を付けると、名前空間の名前は cluster-test のようになります。
「調整中」タイプの status.conditions のコマンド出力を確認します。

これらの status.conditions のステータスが「False」の場合、クラスタは安定していて、バックアップの準備が整っています。
次のコマンドを実行して、クラスタをバックアップします。
```
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 認証鍵を含む機密性の高い認証情報が含まれています。意図しないファイルの公開を防ぐため、ベアメタル版 Anthos クラスタの復元ではメモリ内ファイルのみを使用します。

クラスタの復元に使用する 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 ファイルが生成されます。