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

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

  • VM スナップショットを使用するなど、ノードごとのバックアップの作成はサポートされていません。
バックアップを作成するには、次のコマンドを実行します。 ./rtfctl backup このコマンドにより、現在のシステム状態のバックアップが ​``​ に作成されます。このパスには、書き込みアクセス権のあるファイルシステム内の任意のパスを指定できます (例: `/opt/anypoint/runtimefabric/backup.tar.gz`​)。 - VM/ベアメタルの Runtime Fabric の場合、​`rtfctl`​ バイナリは ​`/opt/anypoint/runtimefabric/`​ ディレクトリにあります。クラスター内のコントローラーノードで特権ユーザーとしてバックアップコマンドを実行していることを確認します。後で復元するためにバックアップを使用するには、バックアップファイルを Runtime Fabric に含まれていない別のマシン上のセキュアなストレージにコピーします。 たとえば、次のコマンドでは ​`scp`​ を使用してバックアップを別のドライブにコピーします。 scp your\_username@remotehost:/opt/anypoint/runtimefabric/backup.tar.gz /backup-path/to-restore.tar.gz - 自己管理型 Kubernetes の Runtime Fabric の場合、​`rtfctl`​ バイナリが現在のディレクトリに存在し、ユーザーの ​`$PATH`​ に ​`kubectl`​ が存在することを確認します。さらに、Kubernetes (​`kubectl`​) コンテキストが目的のバックアップクラスターに設定されていることを確認します。 ## [](#復元を実行する)復元を実行する

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

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

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

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

  • 既存の Runtime Fabric クラスターで復元するには、バックアップを作成するために使用したのと同じバージョンの ​rftctl​ コマンドラインユーティリティを使用します。

  • 自己管理型 Kubernetes 上の Runtime Fabric では、復元にコントロールプレーンは必要ありません。VM/ベアメタル上の Runtime Fabric では、最初にアプライアンスをインとする必要があるため、コントロールプレーンとの接続が必要です。
Runtime Fabric では、バックアップからクラスターを復元するときに 2 つの対象のオプションが用意されています。 - 既存の Runtime Fabric クラスターを使用する。 - バックアップクラスターと同じ設定で新規の Kubernetes クラスターを作成する。これには、同じ数のサーバーやディスクなどが含まれます。 Vm/ベアメタル上で Runtime Fabric アプライアンスを復元するには、Runtime Fabric アクティベーションデータを​**指定せずに**​ Runtime Fabric インストールスクリプトを実行します。インストールスクリプトを実行したら、復元プロセスを完了します。 自己管理型 Kubernetes 上の Runtime Fabric でクラスターを復元する場合は、​`rtfctl`​ インストールコマンドを実行​**せずに**​クラスターを作成してください。クラスターを作成したら、復元プロセスを完了します。 1. クラスターを復元するための対象オプションを選択します。 2. クラスターに ​`rftctl`​ がインストールされていることを確認します。 3. 作成してあるバックアップファイルをコピーして、​`rtfctl`​ で使用できるようにします。 - VM/ベアメタルの Runtime Fabric の場合、圧縮されたバックアップファイルを、復元する環境のコントローラーノードのディレクトリにコピーします。たとえば、このファイルは次のコマンドを使用して安全に転送できます。 scp /backup-path/to-restore.tar.gz your\_username@remotehost:/opt/anypoint/runtimefabric/ 4. Kubernetes (kubectl) コンテキストがバックアップしたクラスターに設定されていることを確認し、元のバックアップしたクラスターですべての Runtime Fabric コンポーネントをスケールダウンします。 kubectl scale --replicas=0 -n rtf deployment.apps/agent 5. バックアップからクラスターを復元します。 ./rtfctl restore \+ このプロセスは、完了するまで数分かかる場合があります。 自己管理型 Kubernetes の Runtime Fabric の場合、​`rtfctl`​ バイナリが現在のディレクトリに存在し、Kubernetes (kubectl) コンテキストが復元先のクラスターに設定されていることを確認します。 ## [](#関連情報)関連情報 - [Runtime Fabric からのノードの追加または削除](https://docs.mulesoft.com/jp/runtime-fabric/1.13/manage-nodes) - [Anypoint Runtime Fabric インストールの前提条件](https://docs.mulesoft.com/jp/runtime-fabric/1.13/install-prereqs)