コンテンツにスキップ

設定

このページでは、コンテナの環境変数、テンプレートが提供するマウント、SSH 経由の VM バックアップ、そしてオフサイトのセットアップを扱います。バックアップのリポジトリパスは、環境変数ではなくアプリ内（設定、ストレージ、バックアップパス）で設定します。

環境変数

変数 必須 説明
APP_KEY はい restic リポジトリのパスワードを導出するために使う 32 バイトの 16 進シークレット（16 進数 64 文字）。openssl rand -hex 32 で生成します。これを安全に保管してください: 失うと暗号化されたバックアップは復元不能になります。
LIBVIRT_HOST VM と ZFS データセットに必要 VM バックアップのために SSH で到達する Unraid ホスト（デフォルト host.docker.internal。テンプレートは LAN-IP のプレースホルダーをあらかじめ入力します）。Unraid の LAN IP を使ってください。カスタムの br0.x ネットワークでは必須です。 ZFS データセットのバックアップでも使われます（テンプレート項目 Host SSH: Address）。プレースホルダー 192.168.x.x は未設定として扱われます。
LIBVIRT_SSH_PORT いいえ VM バックアップのためのホスト SSH ポート（デフォルト 22）。 テンプレート項目 Host SSH: Port。ZFS データセットでも使われます。
LIBVIRT_SSH_USER いいえ VM バックアップのためのホスト上の SSH ユーザー（デフォルト root）。 テンプレート項目 Host SSH: User。ZFS データセットでも使われます。
LIBVIRT_URI いいえ 完全な libvirt 接続 URI。上記 3 つの LIBVIRT_* 変数から組み立てる代わりに、これをそのまま使用します（設定するとそれらは接続文字列には使われなくなります）。デフォルトは未設定です。TrueNAS Scale では必須です。TrueNAS の libvirtd は非標準のソケットで待ち受けており、組み立て式の URI ではそれを表現できません: qemu+ssh://<user>@<truenas-host>/system?socket=/run/truenas_libvirt/libvirt-sock。詳細は docs/vm-backup-ssh-setup.md の TrueNAS Scale の節を参照してください。 qemu+ssh:// の URI なら、LIBVIRT_HOST・LIBVIRT_SSH_USER・LIBVIRT_SSH_PORT のうち未設定のものはそれぞれこの URI から取られ、BombVault 自身の SSH コマンド（NVRAM の転送、ZFS データセット）にも使われます。
PORT いいえ HTTP ポート（デフォルト 3000。HTTP_ONLY=true の場合にのみ使用）。
HTTPS_PORT いいえ HTTPS ポート（デフォルト 3443。テンプレートは 1:1 で公開するため、WebUI は https://<ip>:3443 で応答します）。
HTTP_ONLY いいえ true に設定すると、自己署名 HTTPS リスナーを無効にし、プレーン HTTP のみを提供します（TLS を終端するリバースプロキシの背後での使用向け）。
BIND_HOST いいえ WebUI が待ち受けるアドレス（デフォルト 0.0.0.0、すべてのインターフェース）。コンテナでは設定しないでください。公開ポートにはすべてのインターフェースが必要です。127.0.0.1 は Docker の外で動かす場合向けです。ヘルスチェックも同じアドレスに問い合わせます。
TRUSTED_PROXY いいえ BombVault の前段にあるリバースプロキシのアドレスまたは CIDR 範囲をカンマ区切りで指定します（例: 192.168.20.11、10.0.0.0/8）。それらのホップからのみ X-Forwarded-For を信頼し、ログイン制限は失敗を実際のクライアントごとに数えるようになります。指定しない場合（既定）は誰も信頼しません。無条件に信頼するヘッダーは、呼び出し側が自分でカウンターを選べてしまうためです。
HOST_SOURCE_ROOT いいえ Host Data としてマウントされるホストパス（デフォルト /mnt）。BombVault は Docker が報告するバインドマウントのソースを、このマウント配下のパスに変換します。別のホストルートをマウントした場合のみ変更してください。
DATA_ROOT_SEGMENTS いいえ バインドマウントのソースをバックアップ対象データとして扱うためのパスセグメント名のカンマ区切りリスト（デフォルト appdata。Unraid の /mnt/user/appdata/<container> という慣習に一致します）。列挙したセグメントのいずれかが、コンテナのバインドマウントのホストソースの完全なパスセグメントとして現れる場合、そのバインドマウントは自動的にバックアップ対象として選択されます。たとえば DATA_ROOT_SEGMENTS=appdata,config と設定すると、.../config のバインドも対象になります。コンテナのデータフォルダーを見つけるための、その他の常時有効な方法についてはバックアップソースの検出を参照してください。
PLATFORM いいえ BombVault が自動検出する代わりに、自身がどのプラットフォームで動作しているとみなすかを強制します: unraid、generic、truenas のいずれか（デフォルトは未設定。フラッシュマウント配下の dockerMan マーカーを探して Unraid を自動検出し、見つからなければ generic になります。認識できない値を指定した場合も generic にフォールバックし、ログに記録されます）。汎用の Docker ホストや TrueNAS Scale では、Unraid 専用の自動検出に頼らず明示的に設定してください（汎用の compose ファイルはこれを行っています）。appdata フォールバックの慣習、インスタンス間の復元先のデフォルト、そして Unraid 専用の通知・コンパニオンプラグイン処理を試みるかどうかが変わります（internal/platform を参照）。
BOMBVAULT_SELF_CONTAINER いいえ BombVault コンテナ自身の名前。これにより自分自身をバックアップ（したがって停止）しません。
BACKUP_MAX_HOURS いいえ 単一のバックアップ実行が強制キャンセルされる前に、そのドメインロックを保持できる最大の実時間（実行が動かなくなってもドメインを永遠にブロックできないようにするガード）。空（デフォルト）は 48 を使います。非常に大きい、または遅いクラウドバックアップでは引き上げてください（上限でキャンセルされた実行は context deadline exceeded で失敗します）。0 に設定すると上限を完全に無効にします。
BACKUP_STALL_HOURS いいえ バックアップがまったく進まない状態が続いた場合に、キャンセルされるまでの時間数。空（デフォルト）は 2 を使います。0 に設定すると停滞ではキャンセルしなくなります。2 つのガードのうち細かいほうで、通常先に働くのはこちらです。実行にかかった時間ではなく、まだ何かが起きているかどうかを見るため、遅くても健全な数テラバイトのバックアップはそのまま続き、応答しない共有で止まったものは数日ではなく数時間で停止されます。何かをキャンセルする前に、30 分間動きがなければ警告がログに記録されます。スキャンも進捗として数えます。restic は大きなツリーをたどっている間はバイトを書き込まないため、その段階は書き込んだバイト数ではなく、ファイルとバイトの合計で見守ります。2 つの変数は互いに独立しており、BACKUP_MAX_HOURS は引き続きバックアップ本体の後の段階（保持、統計、オフサイトコピー）の上限になります。そこには見守るカウンターがないからです。
DB_DUMP_MAX_HOURS いいえ 自動データベースダンプ 1 回が停止されるまでに実行できる時間数。空（既定）は 6 を使います。指定できるのは 1 から 48 で、上限は BACKUP_MAX_HOURS より 1 時間低く保たれます（それが 2 時間未満のときはその半分）。長いダンプがバックアップ全体を巻き込まず、自分の制限で打ち切られてそう報告されるためです。進まなくなったダンプは BACKUP_STALL_HOURS でそれより早く停止されます。停止されたダンプはそれ自体が失敗となり、コンテナのバックアップは続きます。Unraid では Add another Path, Port, Variable で BombVault コンテナに追加します。
TZ いいえ スケジューラーのタイムゾーン（たとえば Europe/Berlin）。 設定しない場合、すべてのスケジュールは UTC で実行されます。02:30 に設定したスケジュールは現地時間ではなく 02:30 UTC に開始します。 Unraid では自分で設定する必要はありません。システムが自身のタイムゾーンをすべてのコンテナーに渡します。起動ログには、どのタイムゾーンに決まったかが表示されます。夏時間のあるタイムゾーンでは、春に 1 回の実行が飛ばされ、秋に 1 回の実行が 2 度行われます。UTC ではどちらも起きない代わりに、年に 2 回、手元の時計と 1 時間ずれます。

マウント

CA テンプレートに示されているとおり、Docker ソケット、フラッシュ（/boot）、そして Host Data ルート（/mnt）をマウントします。バックアップのソースとデスティネーションはどちらも Host Data の配下に存在し、それは slave でマウントされます。そのため、コンテナ起動後にマウントされるリモート共有（たとえば /mnt/remotes の配下）が、再起動なしで見えるようになります。

ZFS データセットのバックアップにもこのモードが必要です。ホストはコンテナの起動後にデータセットのスナップショットをマウントするためです。ZFS データセットを参照してください。

バックアップのリポジトリパスはデフォルトで /mnt/user/bombvault/{container,vms,flash,config,files,zfs} になり、初回バックアップ時に作成されます。場所はいつでも 設定、ストレージ、バックアップパス で変更できます。各パス欄にはインラインの ローカル / リモート スイッチもあります。パスはローカルフォルダーの代わりに restic のリモート（s3:...、rest:...、sftp:...、rclone:...）にでき、別のローカルコピーなしでそこへ直接バックアップします。リモートのプライマリリポジトリを参照してください。

ホスト統合チェック

コンテナが起動したあと、Web UI で /spike を開いてください。これはすべてのマウントと CLI（Docker ソケット、libvirt、restic、qemu-img、rclone）をプローブし、欠けている部分を報告します。

バックアップ元の自動判定

コンテナごとに、どのバインドマウントと名前付きボリュームをバックアップするかは BombVault が自動で選びます。次のいずれかに当てはまるとパスが採用されます（結果はコンテナごとに バックアップ対象フォルダ でいつでも上書きできます）。

  • データルート区切りの一致: バインドのホスト側ソースが DATA_ROOT_SEGMENTS の区切りのいずれかをパス要素まるごととして含む場合（既定は appdata のみ）。
  • Docker の名前付きボリューム は常に対象になります。使い捨ての相当物が存在せず、除外すべきものがないからです。ただし、そのボリュームの実際のホスト保存パス自体が Host Data マウント経由で到達できる場合に限ります。BombVault がバックアップする他のホストパスとまったく同じ条件です。既定のローカルボリュームドライバはボリュームをデーモン自身のデータルート配下、つまり変更していなければ /var/lib/docker/volumes/<name>/_data に置きます（docker info -f '{{.DockerRootDir}}' で確認できます）。その場所は、汎用の docker-compose.yml が既定で使う単一ディレクトリの狭い Host Data マウントには含まれません。到達できないボリュームは黙って飛ばされ、エラーにはなりません。汎用ホストで名前付きボリュームを実際にバックアップするには、Host Data（および HOST_SOURCE_ROOT）を Docker のデータルートも含む共通の上位ディレクトリに向けてください。その代償については compose ファイルの Host Data コメントを参照してください（Unraid は同じ理由から、独自の全体規約である /mnt をまるごとマウントすることでこれを回避しています）。
  • Docker Compose のプロジェクトディレクトリ: コンテナが標準のラベル com.docker.compose.project.working_dir（docker compose up が自動で付けます）を持つ場合、いずれかのバインドがデータルート区切りに一致したかどうかに関係なく、そのディレクトリも追加されます。
  • ラベル bombvault.data による上書き: コンテナにラベル bombvault.data=true を付けると、そのバインドマウントを全部含めます。上の二つの規約のどちらにも当てはまらない構成（たとえば Compose プロジェクトのない /srv/plex/config 単独のバインド）向けです。false 以外の空でない値はすべて真とみなされ、ラベルがない場合や bombvault.data=false では何も変わりません。
  • ラベル bombvault.dbdump: コンテナに bombvault.dbdump=false を付けると、そのコンテナの自動データベースダンプが止まります（0、no、off も同じ働きです）。エンジン名（postgres、mysql、mariadb）を書けば、BombVault が自力で認識しないコンテナもダンプできます。ラベルはコンテナのカード上のスイッチより優先されます。Unraid ではそのスイッチが通常の方法です。

セキュリティモデル

ホストに対する root 相当の制御

Docker ソケットを通じて、BombVault はコンテナの停止、削除、再作成を行い、appdata の読み書きができます。また VM バックアップのためにホストに SSH（qemu+ssh://、デフォルトは root）でログインして virsh を実行します。その Web UI に到達できる者は、実質的にホストの root 権限を持つことになります。

  • 任意のパスワード保護（設定、セキュリティ）: パスワードを設定するとログインが必要になり、消すと無効になります。信頼できる LAN での利用を想定し、既定では無効です。パスワードは APP_KEY で味付けした値に対する Argon2id で保存されるため、コピーされた /config は鍵がなければ無価値で、鍵があっても攻撃には時間がかかります。新しいパスワードは 12 文字以上が必要です。既存のより短いパスワードは変更するまで使えます。セッションは署名され（APP_KEY から導出した HMAC）、パスワードを変えると無効になります。ログインはクライアントごとに 1 分あたり 5 回の失敗までに制限されます。
  • 二要素認証（設定）: パスワードに加えて認証アプリの時刻ベースのコードを使い、有効にしたときに一度だけ 8 個の使い捨てリカバリーコードが渡されます。共有鍵は APP_KEY で暗号化して保存され、無効化には現在のコードが必要です。
  • パスキー（WebAuthn）は、パスワードを設定すると専用のカードに表示されます。パスワードと併用するもので、パスワードの代わりにはならないため、パスキーをすべて削除しても誰も締め出されません。実際のドメイン名と、ブラウザが信頼する証明書が必要です。既定の https://<ip>:3443 はまさに WebAuthn が拒否する形なので、カードは失敗するボタンを出す代わりにその旨を表示します。
  • 変更には JSON が必要です。 何かを変更するリクエストは Content-Type: application/json を送る必要があり、ブラウザからクロスサイトと判定されてはいけません。これにより、別のサイトのページがあなたのブラウザを使って LAN アドレス上の設定を変更することはできません。API を操作するスクリプトはこのヘッダーを送ります。それ以外は 415 で拒否されます。
  • ゲートはオプトインのため、未設定のときは UI と API 全体（オフサイトのセットアップ、改ざんテストのルート、リカバリーキットを含む）が、ポートに到達できる誰からでもアクセス可能になります。オフサイト、イミュータブルなバックアップ、または暗号化を使い始めたら、ゲートを有効にしてください。
  • BombVault は信頼できる、外部に公開されていないネットワークでのみ実行してください。リモートアクセスには、認証と TLS を追加するリバースプロキシの背後に置いてください。レスポンスにはベースラインのセキュリティヘッダー（CSP、nosniff、X-Frame-Options、Referrer-Policy）が付きます。
  • リバースプロキシの背後ではすべてのリクエストがプロキシのアドレスを持つため、TRUSTED_PROXY を指定しないとログイン制限は全クライアントをまとめて数え、攻撃者の失敗であなたも締め出されます。TRUSTED_PROXY にプロキシを指定すると、クライアントごとの計数に戻ります。
  • BombVault の前に置くリバースプロキシは、Authorization または X-API-Key ヘッダーを /mcp へそのまま渡し、応答をバッファリングしてはいけません。そうでないとアシスタントは接続できません。MCP サーバー を参照してください。
  • MCP エンドポイント /mcp は、キーが存在するか OAuth によるサインインがオンになるまで 404 を返します。ログインパスワードがオフでも、すべてのクライアントにキーまたはトークンを求めます。例外となるアドレスはなく、localhost も例外ではありません。復元や削除のツールはなく、設定バックアップを復元するとすべてのキーが失効します。MCP サーバー を参照してください。
  • HTTP_ONLY=true では、セッション Cookie は Secure フラグを失います（プレーン HTTP で機能させるためにそうせざるを得ません）。そのため、機密性が重要な場合は、TLS を終端するプロキシの背後でのみパスワードを有効にしてください。
  • VM バックアップの SSH 接続は、初回接続時にホスト鍵を信頼し（TOFU）、それ以降ピン留めします。コンテナからホストへの経路が信頼できない場合は、ホストの鍵を帯域外で検証してください。
  • 暗号化が有効な場合（設定。デフォルトはオン）、バックアップは restic によって暗号化され、鍵は APP_KEY から導出されます。

MCP サーバー

MCP サーバーに環境変数は必要ありません。設定、連携、MCP サーバー でキーを作成するとオンになり、Web インターフェースと同じポートの /mcp で応答します (例: https://192.168.1.10:3443/mcp)。有効なキーがなければ、このパスは 404 を返します。クライアント、証明書、制限については MCP サーバー を参照してください。

SSH 経由の VM バックアップ

BombVault は libvirt のパスを一切マウントすることなく KVM/libvirt VM をバックアップします。SSH（qemu+ssh://）経由でホスト上の virsh を実行するため、ホストの VM Manager に影響を与えることは決してありません。

Unraid では、ホストの libvirt ソケットをコンテナにマウントする方法は壊れやすいものです。これらのパスは VM Manager が管理しており、「Enable VMs」を切り替えると libvirt が起動できなくなることがあります。SSH 鍵はホストの root 権限を与えますが、これは BombVault がすでに使っている Docker ソケットと同じ信頼レベルです。

クイックセットアップ:

  1. 設定、連携、ホスト SSH: 表示された公開鍵をコピーします。
  2. それを Unraid の /root/.ssh/authorized_keys に追記します（再起動後も維持されるようフラッシュにも保存されます）。
  3. 接続をテスト をクリックします。

テンプレートは --add-host=host.docker.internal:host-gateway を追加するため、コンテナはホストに到達できます。その名前が解決されない場合（たとえばコンテナがカスタムの br0.x ネットワークで実行されている場合）は、LIBVIRT_HOST を Unraid の LAN IP に設定してください。Unraid の SSH ポートを変更した場合は、LIBVIRT_SSH_PORT を一致させてください。ライブスナップショットには、加えて VM 内の qemu ゲストエージェントと、ディスクが /mnt/cache（/mnt/user ではなく）にあることが必要です。

VM のセットアップとネットワークの完全ガイド

完全なステップバイステップガイド（SSH の有効化、永続的な鍵の承認、カスタムネットワークと VLAN のルーティング、VM ごとの方式、ホスト側のトラブルシューティング）は、GitHub の docs/vm-backup-ssh-setup.md にあります。

オフサイトのセットアップ

設定、オフサイト ページでオフサイトのレプリカをセットアップします。完全なワークフロー（イミュータブル/追記専用、改ざんテスト、DR ドリル）についてはオフサイトと復旧を参照してください。要点は以下のとおりです:

  • バックエンド: SMB/CIFS と NFS（共有をマウントしてバックアップパスをそこに向ける）、rclone なしのネイティブ restic バックエンド（s3:...、rest:http://host:8000/repo、sftp:user@host:/repo）、または任意の rclone リモート（rclone:<remote>:<bucket>/path）。Backblaze B2 にはここでネイティブのバックエンドがありません。S3 エンドポイント経由で接続し（s3:https://s3.<region>.backblazeb2.com/<bucket>/<path>）、キー ID とアプリケーションキーを S3 の認証情報として入力します。
  • 共有クラウド認証情報は、設定、クラウドアクセス、共有クラウド認証情報 で暗号化して保存されます。
  • SSH ターゲットは相手側に何もインストールする必要がありません。 sftp: は SSH サーバーだけを必要とします。設定、連携、ホスト SSH の公開鍵（/config/ssh/id_ed25519.pub にもあります）を、ターゲットユーザーの ~/.ssh/authorized_keys に追加します。
  • オフサイトコピー: BombVault は（通常はローカルの）主リポジトリに加えて、ベストエフォート方式で restic copy により新しいスナップショットを複製します。各ドメインには独自のオフサイトスケジュールがあり、今すぐ複製ボタンも備わっています。
  • ドメインごとに複数のオフサイトターゲット: 各ドメインは複数のオフサイトデスティネーションへ同時に複製できます。設定、オフサイト で追加のターゲットを加え、それぞれに独自のリポジトリ、S3 ストレージクラス、追記専用フラグ、保持、成長予算を設定します。それらはすべてそのドメインのオフサイトスケジュールで複製されます。既存の単一オフサイトセットアップは最初のターゲットとして引き継がれます。
  • 保存先: オフサイトの保存先は、対応するすべてのサービスを一覧するウィザードを通して、設定、オフサイト、保存先 で一度だけ設定します。保存先を参照してください。
  • 項目ごとの配置: 各コンテナ、VM、ファイルセットは、ローカルと、バックアップを受け取るターゲットを点灯させます。独自の選択を持たない項目には、設定、ストレージ、配置の既定値 がドメインごとにこれを決めます。項目ごとの配置を参照してください。
  • ソースごとの保持: ローカルとオフサイトのポリシーはどちらも 設定、保持 にあります（すべてをゼロのままにするとオフサイトのスナップショットを自動整理しません）。ローカルの保持 と オフサイトの保持 の各カードにある ソースごとの保持ルール で、コンテナー、VM、フラッシュ、フォルダー、ZFS、セルフバックアップに、ローカルのバックアップとオフサイトリポジトリそれぞれの独自の保持ルールを設定できます。独自ルールのないソースは共通ルールに従い、バックアップ後の保持、オフサイトへのコピー、手動の整理、保持のプレビューはいずれも対象ソースのルールを使います。追加のオフサイトターゲットは 設定、オフサイト で設定したルールに従います。
  • 帯域幅制限: 設定、オフサイト で restic のアップロード/ダウンロードレートに上限を設けます。
  • ストリーミング優先: 設定、オフサイト で、メディアサーバー（Plex、Jellyfin、Emby はイメージ名で事前に選択されます）、ストリーミングとみなす送信レート、ストリーミング中のアップロード制限、ストリーム後に通常の制限へ戻るまでの時間を選びます。
  • コールドおよびアーカイブのストレージクラス（S3）: ネイティブ S3 のオフサイトリポジトリでは、復元可能な階層（Standard、Standard-IA、One Zone-IA、Intelligent-Tiering、Glacier Instant Retrieval）を選びます。rclone リモートはそのクラスを rclone 設定で指定します。
  • ローカルではなくリモートを主に: ドメインのバックアップパス自体を上記のバックエンドのいずれかにでき、ローカルコピーも複製の手順もありません。インラインの ローカル/リモート スイッチと、その帯域幅、追記専用、成長予算の安全設定についてはリモートのプライマリリポジトリを参照してください。

異常

異常検出は 設定、整合性 の 異常 カードで設定します。各コントロールは変更した時点で保存され、検出がオフの間はスイッチの下の 3 つが隠れます。

設定 既定値 内容
異常を検出する オン 各バックアップを項目自身の履歴と比べます。オフにすると新しいチェックは行われず、サイドバーから 異常 が消えます。カードからは以前の検出結果に引き続き移動できます。
感度 標準 厳しめは小さな変化も知らせ、緩めは大きな変化だけを知らせます。
通知を送る対象 重大な検出結果のみ 通知 で設定したチャネルでメッセージを送る最低の重大度です。繰り返すバックアップやダンプの失敗と、失敗した定期リストアチェックはそれぞれ独自に通知するので、二重には送りません。
ソースが急に縮んだり書き換えられたりしたら古いバックアップを残す オン 項目に、ほぼ空のソース、大きな縮小、データの大部分の再保存についての未解決の検出結果がある間は、保持ポリシーと整理はその項目の古いバックアップに手を付けません。解放するには検出結果を確認済みにするか、想定どおりと印を付けてください。

項目ごとに独自の感度と通知の最低レベルを持てます。異常 ページで設定します。未解決の検出がある項目はそのカードの 監視 から、それ以外の項目は 未処理なし カードから開きます。項目自身のパネルでも設定できます: コンテナのフォルダー欄と VM の設定 (どちらも詳細モード)、フォルダーセットのフォルダーエディター、そして フラッシュ と セルフバックアップ のページです。ZFS 項目では、ZFS ページの項目のエディターにあり、ツリーのすべてのデータセットに適用されます。

持ち運び可能な設定（エクスポートとインポート）

設定、システム ページの設定のエクスポート / インポートカードは、BombVault の設定一式（ドメイン設定、オフサイトターゲット、スケジュール、保持、通知）を、別のインスタンスでインポートできる持ち運び可能な JSON ファイルに書き出します。これにより、新しいマシンへの移行やセットアップの複製で、すべてを手作業で入力し直す必要がなくなります。インポートはプレビューを表示して確認を求め、バックアップデータや履歴に触れることは決してありません。

エクスポートには認証情報が含まれることがあります

オフサイト、通知、MQTT ブローカーの認証情報をファイルに含めるかどうかは選べます。認証情報を含めた場合、エクスポートはリカバリーキットと同じくらい機密性が高くなるため、安全な場所に保管してください。含めない場合、ファイルには機密でない設定のみが含まれます。