ホームサーバーでデータを失わずにHermesエージェントを実行する方法

簡単な答え

Hermes Agentをホームサーバーでデータを失わずに実行するには、設定、スキル、ログ、生成ファイル、ゲートウェイ設定がコンテナの内部ファイルシステムだけに存在することに頼らないでください。永続的なホストフォルダやDockerボリュームを最初に計画し、アプリが実際に使用するコンテナパスにマウントし、ファイルの所有権を確認し、再起動や再設定後にデータが存在することを検証してください。この記事は、ボリュームマウント、権限、パスマッピングの問題でコンテナがフォルダを見つけられない一般的な失敗パターンに焦点を当てています。

初心者に最も安全なワークフローは以下の通りです：

1. どのHermes Agentデータを保持すべきか特定してください。
2. 専用のホストフォルダかDocker管理のボリュームを選択してください。
3. そのストレージを正しいコンテナパスにマッピングしてください。
4. アプリユーザーが書き込み可能か確認してください。
5. アップデートや再構築の前に重要な設定をバックアップしてください。
6. 設定、ログ、生成ファイル、ゲートウェイ設定がまだ存在するか再起動後に確認してください。

稼働中のコンテナがあるからといってデータが安全とは限りません。データは永続的な場所に保存され、正しいユーザーが書き込み可能で、必要に応じてバックアップされ、再起動後に検証されて初めて安全です。

なぜHermes Agentのデータがコンテナ環境で消えるのか

コンテナ化されたアプリは起動や置き換えが簡単です。これはアップデート、テスト、復旧に便利ですが、使い捨てのコンテナレイヤー内にのみ保存されたものは、コンテナの削除、再作成、再構築時に失われる可能性があります。

セルフホストのAIエージェントの場合、基本設定以上の影響があります。エージェントの使い方によっては、モデル設定、スキル、生成ファイル、ログ、メッセージングゲートウェイ設定、その他のアプリ状態が重要になることがあります。

コンテナの再起動と永続的なアプリデータの違い

通常のコンテナ再起動は必ずしもデータを削除しません。データが永続的なボリュームや正しくマッピングされたホストフォルダに保存されていれば、再起動後も利用可能なままです。

重要なファイルがコンテナの書き込み可能なレイヤー内にのみ存在する場合にリスクが生じます。そのレイヤーは計画された永続的なデータ保存場所とは異なります。適切なパスを保持または再マウントせずにコンテナを再作成すると、アプリは初期状態で起動するか、以前のファイルを見つけられなくなる可能性があります。

なぜコンテナの削除や再作成で未保存の状態が失われるのか

コンテナの削除や再作成は再起動とは異なります。再作成されたコンテナは新しい内部ファイルシステム、新しい環境変数、または異なるマウントマッピングを使用することがあります。

Hermes Agentの設定、スキル、ログ、生成された出力が永続的なホストフォルダやボリュームに書き込まれていなければ、新しいコンテナに引き継がれない可能性があります。これが「昨日はアプリが動いていたのに」「アップデート後にアプリがリセットされた」という両方が起こりうる理由です。

安全な習慣として、アプリのデータ保存場所を確認するまでは、コンテナの置き換えをデータリスクのあるイベントとして扱うべきです。

なぜホストパスとコンテナパスを最初に計画する必要があるのか

ホストパスはホームサーバー上のデータの場所です。コンテナパスはコンテナ内からアプリがそのデータを見る場所です。ボリュームマウントまたはバインドマウントはこれら二つの世界をつなぎます。

ホストパスが正しくても誤ったコンテナパスにマウントされている場合、アプリはフォルダが存在しないかのように動作することがあります。コンテナパスが正しくてもホストパスが使い捨ての場合、アプリは意図しない場所にデータを書き込む可能性があります。

アプリを実行する前にマッピングを計画し、データを失ってからではありません。

Hermesエージェントを実行する前に保護すべきデータは何ですか？

コンテナを変更したり、イメージを更新したり、ゲートウェイを再設定する前に、再作成が困難なデータをリストアップしてください。すべてのファイルが同じ保護を必要とするわけではありませんが、どのファイルが重要かを把握しておくべきです。

役立つルールは、ID、アクセス、設定、学習したワークフロー、または簡単に再生成できない出力を保存するものはすべて保護することです。

エージェント設定およびモデルプロバイダー設定

モデル設定には通常、プロバイダーの選択、エンドポイントの値、モデル名、コンテキスト関連のオプション、およびAPIアクセスが含まれます。これらの設定が失われると、エージェントは起動しても正しく応答できない可能性があります。

モデル設定は使い捨てのシェルセッションではなく、永続的なアプリデータパスに保存してください。設定が環境変数で提供される場合は、composeファイル、envファイル、またはデプロイメントノートの安全なコピーを保持してください。

エージェントがターミナルツールやメッセージングゲートウェイをどのように使用するかを決定するセットアップの選択も保護してください。

アプリのメモリ、セッション、スキル、およびランタイム状態

Hermesエージェントのデータには複数の設定ファイルが含まれることがあります。Hermesスキルのデータ構造では、スキルは~/.hermes/skills/に存在し、これはバンドル、ハブインストール、エージェント作成のスキルの主要な真実の情報源であると説明しています。また、バンドルマニフェスト、スキルバンドル、ハブタップ設定、保留中のスキル書き込み、設定などの関連状態についても説明しています。

これは重要です。なぜなら、エージェントが作成したスキルは再利用可能な手続き記憶になる可能性があるからです。誤ったパスがマウントされると、設定だけでなく、エージェントが学習したワークフローやインストールしたスキルも失う可能性があります。

スキル、バンドル、保留中の書き込み、およびプロファイル関連の状態は永続的なエージェントデータとして扱ってください。

ダウンロード、生成ファイル、ログ、およびツール出力

生成されたファイルは見落としやすいです。エージェントは通常の使用中に計画、スクリプト、レポート、スクリーンショット、ログ、またはダウンロードファイルを作成することがあります。

これらのファイルは、アクティブなワークスペース、バックエンドの作業ディレクトリ、アプリのホームディレクトリ、またはマウントされた出力パスに保存される場合があります。その場所がコンテナ内のみの場合、コンテナが削除されるとファイルも消える可能性があります。

実用的に使用するには、生成されたファイルがホストサーバーのどこに表示されるべきかを決定し、コンテナがそこに書き込むことを確認してください。

APIキー、ボットトークン、環境変数

秘密情報は通常のアプリデータではありません。APIキー、ボットトークン、ダッシュボードパスワード、環境変数は永続性と保護の両方が必要です。

秘密情報をランダム生成された出力フォルダや広く共有されたディレクトリに保存しないでください。アクセス制限された管理された設定パスに保管しましょう。

良い秘密管理のセットアップは以下に答えるべきです：

• 秘密情報がどこに保存されているか
• どのユーザーが読み取れるか
• バックアップに含まれているかどうか
• バックアップが暗号化されているかアクセス制御されているか
• 秘密情報が漏洩した場合のローテーション方法

ホストパス vs コンテナパス vs ボリュームマウント

これはほとんどの「コンテナがフォルダを見つけられない」や「再起動後にデータが消えた」問題の鍵となる概念です。コンテナは自身のファイルシステム内かマウントされたものしか見られません。

トラブルシューティング前にセットアップを整理するためにエージェントデータ生存マップを使いましょう。

フレームワークモジュール	重要な質問	何を決めるのに役立つか	セットアップ／トラブルシューティングの焦点
データの棚卸し	コンテナの再起動や再作成後も残すべきデータは何か？	保護が必要な設定、スキル、ログ、ダウンロード、トークン、生成ファイルはどれか	重要なエージェントデータを使い捨て状態として扱うのを防ぐ
永続パス	永続データはホストのどこに置くべきか？	専用ホストフォルダ、Dockerボリューム、またはバインドマウントのどれを使うか	コンテナ再作成後のデータリセットを防ぐ
マウントマッピング	ホストパスが正しくコンテナパスにマッピングされているか？	アプリが意図したフォルダを実際に見られるかどうか	フォルダが見つからない、誤った宛先パスのエラーを診断するのに役立つ
権限の境界	どのユーザーがマウントされたデータを所有し、どのユーザーが書き込むか？	ホストユーザー、コンテナユーザー、アプリユーザー、またはrootのどれがファイルを所有しているか	すべてをroot所有にせずに権限拒否を解決するのに役立つ
バックアップの境界	アップデートや再設定前に何をバックアップすべきか？	どのデータが重要でどのデータが一時的か	設定、スキル、セッション、トークン、ゲートウェイ設定の喪失を防ぐ
再起動検証	再起動やアップデート後もデータは存在するか？	セットアップが本当に耐久性があるかどうか	「動いている」を繰り返し可能な安全チェックに変える

ホストサーバーが保存するもの

ホストサーバーは実際のフォルダ、ディスク、Docker管理のストレージ場所を保存します。バインドマウントを使う場合は特定のホストフォルダを選びます。名前付きDockerボリュームを使う場合はDockerがストレージ場所を選び管理します。

この区別は、ホストの可視性がバックアップや移行に影響するため重要です。バインドマウントされたフォルダは初心者が見つけてコピーしやすいかもしれません。名前付きボリュームはDocker管理のアプリデータにとってはよりクリーンですが、検査やバックアップ方法を知っておく必要があります。

人間が読めるホストフォルダ、Docker管理のアプリ永続化、または制御されたバックアップパスのいずれが必要かに基づいてストレージスタイルを選択してください。

コンテナが見られるもの

コンテナは自身の内部ファイルシステムとマウントされたパスのみを認識します。ホームサーバー上のすべてのフォルダを自動的に見るわけではありません。

Dockerのバインドマウント解説では、ホストのディレクトリがコンテナ内のターゲットパスにどのように表示されるか、マウントが正しい場合にホストとコンテナ間でファイルの変更がどのように反映されるかを示しています。

これが核心です：アプリはファイルがホストのどこにあるか気にしません。ファイルがアプリが使うパスにマウントされていなければ意味がありません。

ボリュームマウントがアプリデータを永続化する仕組み

永続的なマウントは、単一のコンテナの寿命を超えてデータを書き込む安定した場所をアプリに提供します。アプリデータにとって、これは「再起動に安全」と「コンテナの寿命のみ」の違いになることが多いです。

マウントはアプリが期待するデータパスと一致しなければなりません。アプリが内部のあるフォルダに書き込むのに、別のフォルダをマウントすると、データは使い捨てストレージに入る可能性があります。

良い永続的セットアップは次を定義すべきです：

• ホストフォルダか名前付きボリュームか；
• コンテナのターゲットパス。
• マウントが読み書き可能か読み取り専用か；
• どのアプリデータがそこに属するか；
• どのようにパスがバックアップされるか。

誤ったパスマッピングがフォルダが見つからないエラーを引き起こす理由

誤ったマッピングは、フォルダが見つからない問題のように見えます。フォルダはホストに存在しても、コンテナから見えない場合があります。または、コンテナに期待されるパスにフォルダがあっても、意図したホストフォルダと接続されていないことがあります。

よくある症状は次の通りです：

• アプリがフォルダが存在しないと言う；
• 生成されたファイルがコンテナ内にはあるがホストにはない；
• コンテナ再構築後にログが消える；
• 更新後に設定がリセットされる；
• ホストフォルダを編集してもアプリは古い設定を使い続ける；
• バックアップスクリプトは実行されるが、実際のアプリデータが含まれていない。

問題が起きたら、ホストパスとコンテナパスの両方を確認してください。一方だけを調べてはいけません。

データを失わずにHermes Agentを実行する方法

目的は単にHermes Agentを起動することではありません。重要なのは、再起動、更新、再構築、再設定後も大切なデータが残ることです。

ステップ1：専用のホストデータフォルダを選ぶ

コンテナを実行または再構築する前にホストデータフォルダを選択してください。識別しやすく、バックアップしやすく、無関係な個人ファイルと混ざらないものが望ましいです。

専用フォルダは、アプリに属するものが見えるためリスクを減らします。また、ホームディレクトリ全体や他の機密フォルダをコンテナにマウントするのを避けられます。

実用的なホストデータフォルダは次の条件を満たすべきです：

• アプリ固有のもの；
• 使い捨てのダウンロードパスの外に置く；
• バックアップ計画に含める；
• 無関係なサービスと広く共有しない；
• アクセスが必要なユーザーやサービスだけが書き込み可能。

ステップ2：データフォルダをコンテナにマウントする

ホストのデータフォルダをアプリが期待するコンテナのパスにマウントします。ここで多くのデータ損失問題が発生したり防止されたりします。

バインドマウントの場合、ホストのパスはあなたが選択し、ターゲットパスはコンテナ内で表示される場所です。名前付きボリュームの場合、Dockerがホスト側の場所を管理します。

アプリが自動的にマウントされたフォルダーを使用するとは限りません。マウントされたターゲットが実際のアプリデータパスと一致していることを確認してください。

ステップ3：コンテナが期待されるアプリデータパスを使用していることを確認する

マウント後、コンテナ内からパスを確認してください。ホスト上にフォルダーが存在しても、正しくマウントされていなければアプリからは見えません。

最も簡単な検証は、一方から無害なテストファイルを作成または特定し、それがもう一方に表示されることを確認することです。その後、アプリが実際の設定、ログ、生成ファイルを同じ永続パスに書き込むことを確認します。

このステップは、アップデートや移行の前に特に重要です。

ステップ4：ファイルの所有権と書き込み権限を確認する

正しいマウントでも、アプリが書き込みできなければ失敗します。権限エラーは、ファイルがrootによって作成され、その後アプリが別のユーザーとして実行される場合によく発生します。

権限を広範囲に変更する前に所有権を確認してください。正しい対処は、通常、対象のアプリユーザーが特定のアプリデータフォルダーを読み書きできるようにすることであり、すべてのプロセスにホストの広範なディレクトリの完全な制御を与えることではありません。

「Permission denied（許可拒否）」が表示された場合は、以下を特定してください：

1. マウントされたホストのパス。
2. コンテナのターゲットパス。
3. アプリを実行しているユーザー。
4. ファイルの所有者。
5. マウントが読み取り専用かどうか。
6. バックアップやエクスポートパスが書き込み可能かどうか。

ステップ5：シークレットと設定ファイルを使い捨てパスの外に保管する

シークレットや設定ファイルは、一時フォルダー、生成された出力ディレクトリ、または臨時のシェル履歴だけに置かないでください。環境変数を使う場合は、デプロイメントファイルやenvファイルを管理された永続的な場所に保管してください。

シークレットをログや生成された成果物と混ぜないでください。ログはトラブルシューティングのために共有されることがありますが、シークレットは軽率に共有すべきではありません。

シークレットをバックアップする場合は、バックアップを保護してください。APIキーやボットトークンを露出させるバックアップは別のリスクを生みます。

ステップ6：コンテナを再起動してデータがまだ存在するか確認する

セットアップ後、コンテナを再起動して重要なデータが残っているか確認します。これが永続性の最も実用的なテストです。

「コンテナが起動する」だけで止まらず、以下を確認してください：

• モデル設定がまだ存在します；
• スキルやアプリの状態が引き続き表示されます；
• ログが期待される場所で継続されます；
• 生成されたファイルがホスト上に表示されます；
• ゲートウェイやボットの設定が引き続き機能します；
• バックアップファイルの場所を特定できます。

再起動検証に合格した設定は、初回インストールに合格しただけの設定よりもはるかに安全です。

権限、バックアップ、安全性の境界

データの安全性は、誰が書き込みできるか、何がバックアップされるか、エージェントが何にアクセスできるかの3つの境界に依存します。これらの境界は、ファイルの作成、ワークフローの変更、ツールとの連携を行う可能性があるセルフホスト型エージェントにとって特に重要です。

コンテナのユーザー権限が重要な理由

コンテナのユーザー権限は、アプリがデータを読み書きできるかどうかを決定します。アプリがあるユーザーとして実行されていても、マウントされたフォルダーが別のユーザーの所有である場合、書き込み操作が失敗することがあります。

これが、rootでセットアップコマンドを実行すると後で問題が発生する理由です。rootはファイルを正常に作成できても、通常のアプリユーザーがそれらを変更できない場合があります。

アプリデータフォルダレベルで権限を修正してください。無関係なホストファイルを露出させる広範な権限変更は避けてください。

すべてをrootで実行するのを避けるべき理由

rootは多くの制限を回避できますが、それが安全なデフォルトであるわけではありません。すべてをrootで実行すると、root所有のファイルが作成され、権限の問題が隠れ、アプリに必要以上のアクセス権が与えられる可能性があります。

ほとんどのセルフホストアプリのワークフローでは、rootは特定の管理作業のみに使用すべきです。通常のアプリ設定は可能な限り意図されたアプリまたはコンテナユーザーとして実行してください。

より安全なパターンは最小権限です：アプリに必要なフォルダだけに書き込みアクセスを与えます。

読み取り専用マウントまたは限定フォルダを使用するタイミング

エージェントがファイルを検査する必要があるが変更すべきでない場合は読み取り専用マウントを使用してください。エージェントが出力を作成する必要があるが、広範な個人またはシステムディレクトリに触れてほしくない場合は限定的な書き込み可能フォルダを使用してください。

これは特に、エージェントにすべてのサーバーファイルへの書き込みアクセスを与えずに、レポート、計画、スクリプトを生成させたい場合に有用です。

限定フォルダ設計はミスの影響を減らします。また、どのフォルダにアプリの状態が含まれ、どのフォルダに生成された出力があるかが分かるため、バックアップが簡単になります。

更新や再設定の前にエージェントデータをバックアップする方法

コンテナイメージ、マウントパス、ゲートウェイ設定、またはプロファイルを変更する前に、重要なアプリデータをバックアップしてください。バックアップは、何が含まれているかと復元方法を知っている場合にのみ有用です。

Dockerコミュニティのボリュームバックアップの権限に関する議論では、一般的なユーザー向けの失敗パターンが示されています：パスは存在しても、権限、所有権、ラベリング、またはマウントに関連する制限により、バックアップや書き込み操作が失敗することがあります。

バックアップを作成するだけでなく、バックアップのテストも行うことを思い出してください。バックアップ計画には、バックアップの作成と復元の検証の両方が含まれるべきです。

よくある問題とその解決方法

Hermes Agentのデータが欠落している場合、すぐにアプリを再インストールしないでください。まず、どのレイヤーが失敗したのかを特定してください：データインベントリ、永続パス、マウントマッピング、権限境界、バックアップ境界、または再起動検証。

コンテナがマウントされたフォルダーを見つけられない場合

これは通常、パスが一方のレイヤーには存在するが、もう一方には存在しないことを意味します。ホストフォルダーがマウントされていない、コンテナのターゲットパスが間違っている、またはアプリが別の場所を参照している可能性があります。

次の順序で確認してください：

1. ホスト上にフォルダーが存在することを確認してください。
2. コンテナにマウントがあることを確認してください。
3. コンテナ内のターゲットパスを確認してください。
4. アプリがそのターゲットパスを使用するように設定されていることを確認してください。
5. アプリユーザーがフォルダを読み取れることを確認してください。
6. composeやrunの設定を変更した後、マウントが再作成されたことを確認してください。

コンテナ内にランダムなフォルダを作成してこれを修正しないでください。それは一時的にエラーを消すかもしれませんが、データを使い捨てストレージに残すことになります。

アプリのデータが再起動後にリセットされる

再起動後にデータがリセットされる場合、アプリが永続パスではなくコンテナの内部ファイルシステムに書き込んでいる可能性があります。また、予期しないプロファイル、環境変数、データディレクトリを使用している可能性もあります。

再起動前後のデータパスが同じかどうかを確認します。その後、そのフォルダがマウントによって支えられているか、コンテナレイヤーのみかを確認します。

アプリが再作成された場合、新しいコンテナに同じボリュームまたはバインドマウントがアタッチされていることを確認してください。

データディレクトリでの権限拒否エラー

「Permission denied」はアプリがパスを認識しているが必要な操作を実行できないことを意味します。問題は所有権、読み取り専用マウント設定、ファイルシステムのラベル、またはホストユーザーとコンテナユーザーの不一致かもしれません。

最小限のチェックから始めます：アプリユーザーがデータディレクトリに無害なテストファイルを作成できるか？できない場合は、その特定のパスの所有者とモードを調査してください。

ホストのディレクトリ全体に広範な書き込み権限を与えて解決しようとしないでください。アプリのデータパスと対象のアプリユーザーを修正してください。

生成ファイルはコンテナ内にのみ保存される

再ビルド後に生成ファイルが消える場合、それらはおそらくコンテナ内に保存されており、マウントされたホストパスには保存されていません。これは、アプリの作業ディレクトリや出力ディレクトリがマッピングされていない場合によく起こります。

生成されたファイルの保存先を決定します。その後、その出力フォルダをマウントするか、アプリを既存の永続的な場所に書き込むように設定します。

パスを変更した後、無害なテストファイルを生成し、ホスト上に表示されることを確認します。

再設定後にボットまたはゲートウェイの設定が消える

設定が永続しないパスに保存されているか、再起動後にアプリが異なるプロファイルで実行されている場合、ゲートウェイの設定が消えることがあります。同様に、環境変数が一箇所で変更されても、実行中のコンテナが別の値を使用している場合も同様です。

ゲートウェイの設定、ボットトークンの参照、許可リスト、ダッシュボード設定が期待される永続的な場所に保存されているか確認します。その後、ゲートウェイを再起動して設定が有効なままであることを確認します。

ボットが再起動前は動作するが再起動後に動作しない場合は、トークンを変更する前に永続性と環境設定に注目してください。

Hermesエージェントのデータが安全かどうかを確認する方法

安全なセットアップは、再起動、書き込み、バックアップ、アクセスのチェックに合格する必要があります。これらのチェックは複雑である必要はありませんが、大きな変更後に繰り返し行うべきです。

再起動後も設定が保持される

無害な設定を変更し、コンテナを再起動して設定が保持されているか確認します。これにより、アプリが永続ストレージに書き込んでいることが確認できます。

設定が消える場合は、これ以上設定を追加しないでください。まずデータパスを修正してください。

ログと生成ファイルは期待されるホストフォルダに表示される

ログや生成ファイルはホストの期待する場所に表示されるべきです。コンテナ内にのみ存在する場合、再構築時に失われる可能性があります。

マウントの両側を確認してください。ホストとコンテナは重要なファイルについて一致している必要があります。

エージェントは権限エラーなしでアプリデータに書き込み可能

エージェントは意図したユーザーとしてアプリデータフォルダに書き込み可能であるべきです。フォルダの存在を確認するだけでなく、書き込みテストが成功することがより重要です。

再起動後のログで権限エラーに注意してください。エージェントが設定を更新したり、スキルを書き込んだり、生成ファイルを保存したり、ゲートウェイ状態を更新しようとしたときにのみ発生する権限問題もあります。

バックアップファイルは場所を特定して復元可能

バックアップは、場所を特定してテスト環境に復元できるまで不完全です。最低限、バックアップに保護したいデータが含まれていることを確認してください。

重要なセットアップの場合、バックアップを別のフォルダやテストインスタンスに復元してから使用してください。これにより、データ損失後に復元問題が発覚するのを防げます。

再起動後もダッシュボードやメッセージアクセスが機能している

再起動後にダッシュボードやメッセージアクセスがまだ機能しているか確認してください。これにより、永続データ、認証情報、ゲートウェイ設定、ネットワークアクセスが依然として整合していることが確認できます。

ダッシュボードは動作するがメッセージ送信が失敗する場合は、ゲートウェイ設定とトークンアクセスを確認してください。メッセージ送信は成功するが生成ファイルが消える場合は、出力パスとマウントを確認してください。

実際のホームサーバー環境での動作方法

実際のホームサーバー環境では、システムが使いやすいダッシュボードを提供していても、同じデータ安全性のロジックが適用されます。どのデータを保持すべきか、どこに保存されているか、コンテナがどのように認識しているか、どのユーザーが書き込み可能か、再起動後にどのように確認するかを理解する必要があります。

例えば、ZimaOS Hermesエージェントセットアップワークフローでは、モデルプロバイダーの設定、Telegramゲートウェイのセットアップ、Hermesコンテナへのアクセス、アプリ環境の起動、Webダッシュボードの確認、権限やボット応答の問題解決を含むデバイス固有のパスが示されています。

Dockerアプリ、エージェントワークフロー、ローカルサービスをコンパクトな常時稼働マシンで実行するユーザー向けに、ZimaBoard 2ホームサーバーは、永続フォルダ、コンテナパス、権限、ストレージ拡張を一緒に計画する必要がある軽量ホームサーバー環境の代表例です。これが唯一のセットアップではありませんが、本ガイドで説明するセルフホストアプリのワークフローに合致しています。

一般的な教訓として、コンテナ化されたエージェントに重要な作業を任せる前に、その重要なデータが今日動いているコンテナを超えて生き残ることを必ず確認してください。

よくある質問

コンテナを再起動したらHermes Agentのデータが消えたのはなぜですか？

単純な再起動で永続データが削除されることはありませんが、アプリが永続化されていないコンテナパスに書き込んでいた場合はリセットされたように見えることがあります。また、同じボリュームやバインドマウントなしでコンテナが再作成された場合もデータが消えることがあります。設定を変更する前にホストパス、コンテナパス、実際のアプリデータパスを確認してください。

Dockerボリュームとバインドマウントの違いは何ですか？

DockerボリュームはDockerが管理し、バインドマウントはホストの任意のフォルダをコンテナにマッピングします。ボリュームはアプリ管理データにクリーンであることが多く、バインドマウントはホスト上で直接場所を特定しやすいです。最適な選択は、Docker管理のストレージが欲しいか、バックアップや検査のためにホストのフォルダを見えるようにしたいかによります。

ホームサーバーでHermes Agentのアプリデータはどこに保存すべきですか？

一時的なコンテナパスではなく、専用の永続フォルダやDockerボリュームを使用してください。場所はバックアップしやすく、アプリの必要に限定され、関連のない機密ファイルと混ざらないようにします。最も重要なのは、アプリが期待するコンテナパスが実際にその永続ストレージにマッピングされていることです。

なぜコンテナはフォルダが存在しないと言うのですか？

フォルダはホスト上に存在してもコンテナ内にない場合があります。これは通常、マウントが作成されていない、ソースパスが間違っている、ターゲットパスが間違っている、またはアプリが異なるコンテナパスを参照していることを意味します。新しいフォルダを無闇に作成するのではなく、ホスト側とコンテナ側の両方を確認してください。

権限エラーを避けるためにHermes Agentをrootで実行すべきですか？

rootで実行すると即時のエラーは隠れるかもしれませんが、root所有のファイルが作成されリスクが増加します。より安全な方法は、対象のアプリユーザーに必要なアプリデータパスの読み書き権限だけを与えることです。rootは、変更内容を理解した上で特定の管理または修復作業にのみ使用してください。

Hermes Agentのデータはどのくらいの頻度でバックアップすべきですか？

更新、コンテナの再構築、パスの変更、ゲートウェイの再設定、または別のサーバーへの移行の前にバックアップを取ってください。アクティブに使用する場合は、スキル、設定、生成されたファイル、セッションの変更頻度に基づいて定期的なバックアップをスケジュールしてください。バックアップは、ファイルが見つかり復元できることを確認するまでは信頼できません。