--- schema_version: "1" id: 59f1b1bf6bec686844330db2a53f80ae0117923a63fb21d06e41fd7c1b6d9014 title: Runtime Fabric のバックアップと復元 collection: mulesoft version: current locale: ja-jp portal_url: https://docs.salesforce.com/mulesoft/current/ja-jp/runtime-fabric/2.5/manage-backup-restore.md canonical_url: https://docs.mulesoft.com/jp/runtime-fabric/2.5/manage-backup-restore source_site: docs.mulesoft.com content_type: documentation content_hash: 73f768b21384c59163a6156ddb0f836970d69a1b232323267915a7f9eb9ba75d description: MuleSoft Documentation Site release: "2.5" latest: false --- # Runtime Fabric のバックアップと復元 Runtime Fabric サービスと、すべてのデプロイされたアプリケーションとその設定に必要な状態をバックアップして復元するには、次の手順を実行します。 Runtime Fabric の状態に関するデータは Kubernetes クラスターで分散されます。万一システム障害が発生してもアプリケーションが保持されるように、Runtime Fabric が自動的にバックアップされることを確認します。バックアップをスケジュールするときは、1 時間ごとのバックアップを設定してベストプラクティスに従ってください。Runtime Fabric クラスターの外部にある外部ストレージにバックアップを保存します。 ## [](#バックアップと復元のプロセスを使用する状況)バックアップと復元のプロセスを使用する状況 バックアップと復元のプロセスを使用する一般的なシナリオには次のものがあります。 - Runtime Fabric クラスターのノードをオペレーティングシステムの新しいバージョンに移行するなど、インフラストラクチャの大きなアップグレードを実行する。 - Runtime Fabric クラスターをオンプレミスからクラウドに移行したり、1 つのクラウドプロバイダーから別のクラウドプロバイダーに移行したりする。 - スタンバイクラスターへのフェールオーバーを実行する。

バックアップと復元のプロセスを使用して Runtime Fabric の同時実行インスタンスを作成しないでください。つまり、Runtime Fabric A をバックアップし、Runtime Fabric A がまだアクティブな間にそのバックアップを使用して新しい Runtime Fabric B を作成して、それらを同時に実行しないでください。これにより、アプリケーションデプロイメントの問題が発生します。
## [](#バックアップされるデータ)バックアップされるデータ Runtime Fabric のバックアッププロセスは Runtime Fabric クラスターにのみ影響します。コントロールプレーンのデータはバックアップされません。 通常の Kubernetes クラスターの場合、以下がバックアップされます。 - コントローラーやワーカーノードの設定など、Runtime Fabric クラスターの詳細 - クラスターレベルのセキュアプロパティ - デプロイメント、サービス、サービスアカウント、シークレット、イングレスリソース、ロールバインド、クラスターロール設定、ConfigMap 設定のデータなど、Runtime Fabric とアプリケーション名前空間のすべてのデータ - 現在の ​`rtfctl`​ バージョン - 現在の Runtime Fabric エージェントバージョン - 次のようなアプリケーション詳細: - ポッド、レプリカセット、アプリケーションメタデータ、テンプレートのアプリケーション設定 - Runtime Manager で設定されているアプリケーションプロパティ - 次のような他の MuleSoft 設定のデータ - オブジェクトストア - Edge - Anypoint Monitoring と外部ログフォワーダー OpenShift クラスターの場合、以下がバックアップされます。 - カスタムリソース - アプリケーションの名前空間と、それぞれの名前空間に関する次の情報: - シークレット - サービスアカウント - ConfigMap - サービス - CronJobs - DaemonSets - デプロイメント - イングレス - ロール - ロールバインディング - Runtime Fabric 名前空間からのイングレス ## [](#バックアップされないデータ)バックアップされないデータ - アプリケーションの状態に関するデータ - Ops Center のデータ - コントロールプレーンのデータ ### [](#バックアップ実行後の変更内容が復元されない)バックアップ実行後の変更内容が復元されない バックアップを実行した後の変更は、そのバックアップからクラスターを復元すると存在しなくなります。たとえば、バックアップを実行し、アプリケーションを削除した後、そのバックアップから復元した場合、削除したアプリケーションはクラスターに再作成されますが、Runtime Manager では削除済みとしてマークされています。この結果、アプリケーションの状況は Runtime Manager には ​**\[applying (適用中)\]**​ として表示されます。 バックアップを取った後で変更を行った場合、Runtime Fabric では次のコントロールプレーンの変更は復元されません。 - アプリケーションの作成 - アプリケーションの削除 - アプリケーション設定の更新 - エージェントのアップグレード バックアップを実行した後の変更はコントロールプレーンから再適用できないため、その変更を手動で再適用して不整合を解決する必要があります。 ## [](#バックアップを作成する)バックアップを作成する バックアップを作成するに、次の準備をしてください。 - Runtime Fabric が正しくインストールおよび設定されていることを確認します。 - `rtfctl`​ コマンドラインツールがバージョン 0.3.102 以降にアップグレードされていることを確認します。バージョンを確認するには、任意の Runtime Fabric ノードで ​`rtfctl version`​ を実行します。 - `rtfctl`​ バイナリが現在のディレクトリに存在し、​`kubectl`​ がユーザーの ​`$PATH`​ に存在することを確認します。さらに、Kubernetes (​`kubectl`​) コンテキストが目的のバックアップクラスターに設定されていることを確認します。

VM スナップショットを使用するなど、ノードごとのバックアップの作成はサポートされていません。
バックアップを作成するには、次のコマンドを実行します。 ```copy ./rtfctl backup ``` このコマンドにより、現在のシステム状態のバックアップが ​``​ に作成されます。このパスには、書き込みアクセス権のあるファイルシステム内の任意のパスを指定できます (例: `/opt/anypoint/runtimefabric/backup.tar.gz`​)。 ## [](#復元を実行する)復元を実行する

クラスターを復元する前に、次の情報を確認してください。

  • Runtime Manager にリストされているのと同じ Runtime Fabric クラスター (コントロールプレーン内の同じクラスター) 上で復元を実行する必要があります。

  • バックアップ後に行われたデプロイ済みのアプリケーションおよび管理サービスに対する設定変更は復元されません。

  • アプリケーション監視メトリクスは復元されません。

  • 既存の Runtime Fabric クラスターで復元するには、バックアップを作成するために使用したのと同じバージョンの ​rftctl​ コマンドラインユーティリティを使用します。
Runtime Fabric では、バックアップからクラスターを復元するときに 2 つの対象のオプションが用意されています。 - 既存の Runtime Fabric クラスターを使用する。 - バックアップクラスターと同じ設定で新規の Kubernetes クラスターを作成する。これには、同じ数のサーバーやディスクなどが含まれます。 Runtime Fabric でクラスターを復元する場合は、​`rtfctl`​ インストールコマンドを実行​**せずに**​クラスターを作成してください。クラスターを作成したら、復元プロセスを完了します。 1. クラスターを復元するための対象オプションを選択します。 2. クラスターに ​`rftctl`​ がインストールされていることを確認します。 3. 作成してあるバックアップファイルをコピーして、​`rtfctl`​ で使用できるようにします。 4. Kubernetes (kubectl) コンテキストがバックアップしたクラスターに設定されていることを確認し、元のバックアップしたクラスターですべての Runtime Fabric コンポーネントをスケールダウンします。 ```copy kubectl scale --replicas=0 -n rtf deployment.apps/agent ``` 5. バックアップからクラスターを復元します。 ./rtfctl restore このプロセスは、完了するまで数分かかる場合があります。 Runtime Fabric の場合、​`rtfctl`​ バイナリが現在のディレクトリに存在し、Kubernetes (kubectl) コンテキストが復元先のクラスターに設定されていることを確認します。 ## [](#openshift-クラスターのバックアップを作成して復元する)OpenShift クラスターのバックアップを作成して復元する 次の例の Runtime Fabric には、OpenShift クラスター内のクラスター (​`cluster-1`​) にデプロイされた Mule アプリケーションと設定のセットがあります。バックアップを作成して復元を実行する手順は、次のとおりです。 1. Backup コマンドを実行します。 ```copy ./rtfctl backup -n ```
MuleSoft は、検出されたクラスターに基づいてバックアップを実行します。ただし、​--backup-type​ フラグを使用して、実行するバックアップの種別を手動で指定することもできます。フラグのオプションは ​auto​、​openshift​、​full​ です。デフォルトの ​auto​ フラグオプションを使用すると、MuleSoft は自動的にインフラストラクチャクラスタープロバイダーを検出してバックアップを実行します。
2. `cluster-1`​ をシャットダウンします。 3. 次のコマンドを実行して、すべての Mule アプリケーションのデプロイメントを削除します。 ```copy kubectl delete ns ``` Runtime Manager UI からアプリケーションを削除しないでください。 4. Runtime Fabric をアンインストールします。 5. OpenShift クラスターから Runtime Fabric Operator を削除します (省略可能)。 6. 管理プレーン API エンドポイントに ​`curl`​ コマンドを送信して、アクティベーション ID を再生成します。 Runtime Fabric のアクティベーションの準備ができていることが表示されます。新しい OpenShift クラスターに Runtime Fabric を再度インストールしてアクティベーションすることができます。 ```copy curl --location --request PATCH 'https://anypoint.mulesoft.com/runtimefabric/api/organizations/{org-id}/fabrics/{fabric-id}/regenerateActivationData' \ --header 'Authorization: Bearer {bearer-token} ``` 7. 再生成されたアクティベーションデータ ID を使用して、​`cluster-2`​ に Runtime Fabric Operator をインストールします。 インストールは同じ Runtime Fabric 名前空間で行う必要があります。バックアップのすべての表示ラベルは、そのインストールを指し示しています。 8. restore コマンドを実行してリソースのセットを選択し、クラスターに復元します。 ```copy ./rtfctl restore -n ``` 9. Runtime Fabric デプロイメントの状況を確認します。