オフサイトと復旧¶

ローカルバックアップは、コンテナの喪失や不良な更新からあなたを守ります。オフサイト複製とテスト済みのリカバリーキットは、マシン全体、ランサムウェア、または火災からあなたを守ります。このページでは、オフサイトへの複製、そのコピーを改ざん不能にすること、復元できることの証明、そして BombVault 自身が失われたときの復旧を扱います。

オフサイト複製¶

高速なローカルバックアップを保ちつつ、ひとつ以上のオフサイトレプリカを追加します。設定、オフサイト ページでドメインごとにリポジトリを設定します。BombVault はベストエフォート方式で restic copy により新しいスナップショットをそこへ複製するため、オフサイトの不調でローカルバックアップが失敗することはありません。この形ではローカルリポジトリが主でオフサイトリポジトリはレプリカですが、ドメインの主リポジトリはローカルである必要はまったくありません。オフサイトへ複製する代わりに S3/rest-server などへ直接バックアップする方法は、下のリモートのプライマリリポジトリを参照してください。

ドメインごとに複数のオフサイトターゲット。 各ドメイン（コンテナ、VM、フラッシュ、config、ファイルセット、ZFS データセット）は、ひとつだけでなく複数のオフサイトデスティネーションへ同時に複製できます。そのため、たとえば友人のマシン上の rest-server と S3 バケットを並行して保てます。設定、オフサイトで追加のターゲットを加え、それぞれに独自のリポジトリ、S3 ストレージクラス、追記専用フラグ、保持、成長予算を設定します。既存の単一オフサイトセットアップは最初のターゲットとしてそのまま引き継がれ、ドメインのすべてのターゲットは、そのドメインのオフサイトスケジュールで複製されます。
ドメインごとのオフサイトスケジュール（他のすべてのスケジュールと並んで設定、スケジュールで編集）: 空欄のままにすると各ローカルバックアップの後に複製し、頻度（たとえば weekly Sun 03:00）を設定すると、ローカルでバックアップするより少ない頻度でオフサイトへ送れます。今すぐ複製ボタンがオンデマンドの実行をカバーします。
オフサイトの保持は設定、保持にあり、オフサイトのコピーをアーカイブとして長く保てます。ポリシーをすべてゼロのままにすると、オフサイトのスナップショットを自動整理しません。
帯域幅制限（設定、オフサイト）は、restic のアップロード/ダウンロードレートに上限を設け、複製が WAN を飽和させないようにします。
複製インジケーターは、実行中にどのドメインが複製しているかを示します（そのページとダッシュボードで）。これはアクティブなインジケーターであり、パーセンテージバーではありません。restic copy が機械可読な進捗を公開しないためです。

どこからでも復元

すべてのコンテナ、VM、ファイルセット、フラッシュ、アプリ構成は、バックアップが存在するすべての場所を横断する一つのタイムラインとしてバックアップを一覧表示します。B2 にコピーされたバックアップは一度だけ表示され、それを保持する各場所が付記されます。復元は、その項目が書き込まれるリポジトリを起点に、到達できる最初の場所を使い、行ごとに別の場所を選ぶこともできます。オフサイトの場所は、開いたときにだけ読み取られます。ある場所での削除は、まず他の場所を確認し、それが最後のコピーだったかどうかを示します。

保存先¶

設定、オフサイトは 保存先 から始まります。オフサイトのコピーを置く場所で、すべてのドメインに対して一度だけ設定します。保存先は、各ドメインと各項目の配置行にボタンとして表示されます。あるドメインで初めてオンにすると、BombVault はその保存先の下のフォルダーにそのドメインのリポジトリを作成します（例: rclone:onedrive:BombVault/containers）。フラッシュ、セルフバックアップ、ZFS データセットには配置行がないため、オフサイトのセクションには代わりに、保存先の名前に続けて から追加 と表示されます。

保存先を追加 は五つの手順のウィザードを開きます。

バックアップの保存先を選びます 対応するすべてのサービスがロゴ付きで、四つのグループに分けて並びます。S3 バケットを持つストレージサービス（Backblaze B2、Wasabi、Cloudflare R2、Hetzner Object Storage、Amazon S3 など）、自前の S3 サーバー（Garage、SeaweedFS、RustFS、Silo、Ceph、JuiceFS、Versity S3 Gateway）、自前のサーバーと共有（rest-server、Hetzner Storage Box、SFTP、SMB、WebDAV、マウント済みパス）、そしてクラウドストレージ（OneDrive、Google Drive、Dropbox、pCloud、Nextcloud など、rclone が対応するすべて）です。それぞれ、バックアップにどの程度向いているかが示されます。クラウドドライブは大量のリクエストで遅くなるため、最初のバックアップと prune に時間がかかります。
サインイン 入力欄はサービスによって異なります。S3 ならアクセスキー、WebDAV と SMB ならユーザーとパスワード、二要素認証が通常のパスワードを拒む場合はアプリパスワード、SFTP と Storage Box なら BombVault の公開 SSH 鍵、ブラウザー経由でサインインするサービスならトークンです。そのようなサービスでは、ウィザードがブラウザーのあるコンピューターで実行する rclone authorize コマンドを表示し、出力されたトークンを入力欄に貼り付けます。接続をテスト は、何かを保存する前にサインインを確認します。
フォルダーを選択 ウィザードは保存先のフォルダーを一覧表示します。新しいフォルダー で作成でき、サービスが報告する場合は空き容量も表示されます。空のフォルダーが最も安全です。
削除に対する保護 ウィザードは、そのサービスに何ができるかをはっきり示します。append-only モードの rest-server は削除を拒み、改ざんテストがそれを確認します。S3 バケットはバージョニングとオブジェクトロックで古いバージョンを保持できますが、BombVault はまだそれを確認できません。クラウドドライブは削除を拒むことがまったくできません。サーバーに侵入した者は、そのコピーにも侵入できます。イミュータブル（append-only） は、相手側が本当に削除を拒む場合にだけオンにしてください。オンにすると、BombVault はそこでは prune を行いません。
緊急時のために リカバリーキットには、すべての保存先と、その下にある各ドメインのリポジトリが一覧されます。サインイン情報は BombVault の設定バックアップとともに戻ります。それがない新規インストールでは、同じ場所に保存先をもう一度設定してください。

S3 サービスは restic 自身の S3 バックエンドを通るため、ストレージクラスとオブジェクトロックが適用できます。それ以外のサービスはすべて BombVault に同梱の rclone を通り、そのリモートは設定、クラウドアクセスの rclone 設定に表示されます。設定のエクスポートには保存先が含まれ、認証情報を含めるとそのサインイン情報も含まれます。

グループの別のインスタンスが動かしている受信サーバーは、ウィザードの グループから に表示されます。受信サーバーを参照してください。

保存先から作られたドメインのターゲットは、保存先の名前、場所、認証情報、ストレージクラス、イミュータブルの設定を引き継ぎます。保持、圧縮、成長予算はドメインごとのままで、リポジトリがそこにあるため、場所は移動できません。各ドメインの このドメイン専用のターゲットを追加 では、これまでどおり手入力のリポジトリ URL を指定します。

手入力したターゲットのリポジトリが保存先のフォルダー内にある場合、そのターゲットはその保存先に加わることができます。保存先はそのようなターゲットを すでにこの保存先の下にあります の下に一覧表示し、引き継ぐ でその 1 つを保存先にぶら下げます。ターゲットはリポジトリ、スナップショット、保持、配置をそのまま保ち、保存先の名前、認証情報、ストレージクラス、イミュータブルの設定を引き継ぎます。BombVault は最初に、保存先のサインインでリポジトリを開けるかを確認し、追記専用でない保存先の下に追記専用のターゲットを置くことは拒否します。ドメインのプライマリを引き継ぐと、そのドメインのオフサイト欄は空になります。

項目ごとの配置¶

各コンテナ、VM、ファイルセットのカードには、ボタンが並ぶ配置行があります。ローカル と、ドメインのオフサイトターゲットごとに一つのボタン、さらにそのドメインにまだターゲットのない保存先が続きます。点灯したボタンが、その項目のバックアップを受け取ります。

ローカル が点灯していると、項目は 保存先 に示されたリポジトリへ書き込まれ、点灯している他のすべてのターゲットへコピーされます。ターゲットを消灯すると、そのターゲットはこの項目から何も新しく受け取らなくなります。ローカルだけならどこにもコピーしません。NAS 上で暮らす共有のように、すでに二つ目のコピーがあるデータに向いています。
ローカル が消灯していると、項目は点灯している最初のターゲットのダイレクトリポジトリへ直接書き込まれ、そこから点灯している他のターゲットへコピーされます。最初のときは、ダイアログがそのダイレクトリポジトリを作成します。
保存先のボタンは、その保存先の下にドメインのターゲットを作成し、この項目にだけ点灯させます。他のすべての項目は、そこにコピーのない状態で始まります。
一つのボタンは常に点灯したままです。バックアップには行き先が必要だからです。何かをバックアップから外したい場合は、除外してください。

位置は項目の最初のバックアップから固定されます。BombVault はバックアップをリポジトリ間で決して移動させないためです。コピー先はいつでも変更できます。項目を受け取らなくなったターゲットは、持っているコピーをそのまま保持し、ドメインの次回オフサイト実行時に自身の保持ポリシーに合わせて整理します。カード上の B2 で削除 はそれらを即座に削除します。それらのコピーの一部がほかのどこにも存在しない場合、確認ダイアログは日付ごとに一覧を示し、項目名の入力を求めます。追記専用のターゲットからは削除できません。

行の下でカードは、項目がどこへ向かい、実際に何があるかを示します。何か所のサイトが保持しているか、各ターゲットが最後に確認された時刻、そして 3-2-1 が満たされているかどうかです。サイトとは、元データのあるサーバー、各オフサイトターゲット、そして 敷地外 と印されたリポジトリのことです。BombVault はコピーとサイトを確認しますが、3-2-1 の「二つの媒体」の部分は確認しません。

配置の既定値¶

設定、ストレージ、配置の既定値 には、同じボタンを持つドメインごとの行があります。コピー先は、独自の選択を持たないすべての項目に即座に適用され、Compose スタックのプロジェクトフォルダーにも適用されます。位置は新しい項目の最初のバックアップに適用されます。変更してもバックアップは移動しません。保存前に、この行は項目を得るまたは失うすべてのターゲットと、それが何個のスナップショットを意味するかを示します。バックアップのない項目に適用 は、まだバックアップのないすべての項目を既定値に戻します。

新しいオフサイトターゲットは、ローカルに設定されていないすべての項目を受け取ります。追加時に開くダイアログは、何個の項目か、そしてわかる範囲でそれがどれだけの履歴量かを示し、他のターゲットですでに除外されている項目を除外する選択肢を提供します。

ダイレクトリポジトリ¶

項目のローカルをオフにして、ダイレクトリポジトリのないターゲットをその置き場所にすると、ターゲットの隣に提案された場所（例えば s3:https://s3.eu-central-003.backblazeb2.com/bucket/containers-direct）を示すダイアログと、何も作成しない接続テストが開きます。作成して使う はリポジトリを作成し、項目をそこへ向けます。ダイレクトリポジトリはターゲットのキー、ストレージクラス、制限、append-only 設定、保持を引き継ぎ、それらと一緒に変化します。リポジトリ カードはそれを読み取り専用で表示します。ターゲットの新しいキーでそれを開けない場合、ダイレクトリポジトリは手持ちのキーを保持し、保存時にその旨を示します。ダイレクトリポジトリにある項目は、そこから点灯している他のターゲットへコピーされ、そのリポジトリが属するターゲットへはコピーされません。そのスナップショットにはタグ bv:direct が付き、ほかのすべての保持処理はそれらを残すため、ターゲットへのリンクを失ったダイレクトリポジトリは、ローカルのルールでは決して古びません。B2 にはその S3 エンドポイント経由でアクセスし、キー ID とアプリケーションキーを S3 の認証情報として入力します。ターゲット自身のフォルダーに限定したキーは隣のフォルダーには届かないため、代わりにキーをターゲットの一つ上のフォルダーに限定してください。

敷地外¶

名前付きのリポジトリは、リポジトリ カード上で 敷地外 と印を付けられます。リモートリポジトリは最初から印が付いた状態で始まります。同じ建物内の rest-server ではオフにしてください。この印はカード上のサイト数と 3-2-1 にのみ影響します。コピーは何も変わりません。

再構築の後¶

コピーの選択は BombVault 自身の設定の中で生きています。復元された /config を伴わずに「バックアップを検出」経由で再構築すると、それらは失われ、すべてをコピーすると、除外していた項目を再び B2 へ送ってしまいます。そのため、再構築されたすべてのドメインのオフサイト複製は一時停止します。ダッシュボードはそれを琥珀色で示し、配置の既定値は、次回の実行が何をコピーするかのプレビューと、エントリのないバックアップ内の名前を示す 既定を確認 を提供します。それらはそこで除外できます。この一時停止を終わらせるのは確認だけです。設定ファイルのインポートはルールと既定値を取り戻しますが、一時停止は終わらせません。

リモートのプライマリリポジトリ¶

ドメインのバックアップパス（設定、ストレージ）はローカルフォルダーに限りません。restic のリモート（s3:...、rest:http://host:8000/repo、sftp:user@host:/repo、rclone:remote:bucket/path）を直接指定すれば、BombVault は別のローカルコピーもレプリケーション手順も挟まずに、そこへ直接バックアップします。これは上のオフサイトレプリケーションとは本質的に別の形です。あちらではローカルリポジトリが主で、オフサイトはその最善努力の控えです。ここではリモートリポジトリ そのものが 主であり、そのドメインにオフサイトレプリケーション（または二つ目のリモート）を併せて設定しないかぎり、唯一のコピーになります。

六つのパス欄（コンテナ、VM、フラッシュ、セルフバックアップ、フォルダー、ZFS データセット）にはそれぞれすぐ隣に ローカル / リモート の切り替えがあります。

ローカル はいつものフォルダーブラウザーを表示します。
リモート はそれを素朴な URL 欄に置き換え、オフサイト先が使うのと同じ接続テストと資格情報のダイアログを、このプライマリ向けに構成した状態で開くボタンを添えます。そこから次が得られます。
- 接続テスト。実際のパスに対して、頼りにする前に確かめられます。
- 帯域制限（送信・受信）。リモートのプライマリへの定期バックアップが WAN 回線を埋め尽くさないように、オフサイトレプリケーションが使うのと同じ restic の --limit-upload と --limit-download を、バックアップ自体に適用します。
- 追記専用（不変）保護。オフサイト先と同じ能動的な改ざんテスト（相手側への実際の DELETE 試行）で検証されます。有効にすると BombVault はそのリポジトリの prune を拒みます。背後に別のローカルコピーがない以上、この機体の資格情報がバックアップの唯一のコピーを消せてはならないからです。
- 増加量の予算警告。ストレージカードがすでに追っているのと同じリポジトリ容量の推移から求めます。

どれも必須ではありません。手で入力しただけの、安全設定を保存していないリモートパスは、これまでどおりにバックアップします（帯域無制限、prune 可能、予算警告なし）。安全設定のダイアログは、オフサイトコピーと同じ保護を、そのためだけにオフサイト先を用意することなく得たいときのためにあります。

クラウドと REST の資格情報は共通です

リモートのプライマリは、設定、クラウドアクセス、共有クラウド認証情報に登録した S3/REST の資格情報でそのまま認証します。プライマリリポジトリ専用の資格情報の保管場所はありません。

ホストマウントなしの SMB と WebDAV¶

設定、クラウドアクセス、rclone には、Windows または Samba の共有と、WebDAV サーバー（Nextcloud、ownCloud、SharePoint、その他）のためのフォームがあります。短い名前、ホストと共有（SMB）または URL とサーバーの種類（WebDAV）、ユーザー、パスワードを入力すると、BombVault が rclone のセクションを書いてくれます。パスワードは保存される前に rclone 自身が難読化します。すでにある名前で宛先を追加すると、2 つ目を追加するのではなく、そのセクションを置き換えます。

フォームは完成した場所を返します。たとえば rclone:nas:backups です。それをバックアップパスかオフサイトの宛先に入れ、必要ならサブフォルダーを付け加えます（rclone:nas:backups/bombvault）。共有はパスの最初の区切りで、名前の一部ではありません。

これは Unraid に共有をマウントするより良い方法です。restic はマウントした CIFS 共有にリポジトリを置くことを勧めておらず、ここでは何もマウントされません。NFS がフォームにないのは、restic にも rclone にも NFS バックエンドがないからです。NFS の場合は、ホストでエクスポートをマウントし、バックアップパスをそこに向けてください。

イミュータブル（追記専用）オフサイト¶

オフサイトリポジトリを追記専用としてフラグ付けすると、ランサムウェアや侵害されたホストがバックアップを削除したり書き換えたりできなくなります。相手側（--append-only モードで実行される restic/rest-server）がそれを強制します。BombVault はそれを常に検証するだけで、設定上の主張だけで緑を表示することは決してありません。

ガイド付きオフサイトセットアップウィザードは、バックエンドの選択（rest-server / rclone / S3）から、すぐ貼り付けられる rest-server のデプロイスニペット、接続テスト、イミュータブルの切り替え（これはすぐに改ざんテストを実行します）、保持戦略までを案内します。そのため、追記専用のオフサイトに、設定を手で編集することなく到達できます。

/locks/ 配下での削除成功は想定どおりです

追記専用は、もう何も削除できないという意味ではありません。restic は自身のロックを取得して解放する必要があるため、/locks/ は意図的に書き込み可能かつ削除可能なままです。スナップショットとその背後にあるデータ、つまりランサムウェアが狙うものそのものは削除できません。遠隔側をご自分で試した場合、/locks/ 配下で削除が成功するのは正しい動作であり、保護の穴ではありません。

イミュータブルなリポジトリはこのマシンからは整理されません

イミュータブルなオフサイトは、意図的に古いスナップショットを決して整理しません。リポジトリサイズが暴走する前に警告を受け取れるよう、それに成長予算アラームを設定してください。

改ざんテスト¶

BombVault は定期的に、オフサイトリポジトリに対して実際に削除を試みる（存在しないオブジェクトを狙う）ことで、追記専用の保証を証明します:

拒否は保護されていることを意味します。
受理は保護されていないことを意味します。
判定不能の結果（サーバー到達不能、認証エラー）が、保存された判定を覆すことは決してありません。

保護状態から非保護状態への実際の反転は、単一のアラートを発火させます。

DR ドリル¶

BombVault は、バックアップが単に存在するだけでなく、実際に復元可能であることについて、2 段階の証明を提供します。

復元検証ドリル（ローカル）。 BombVault は定期的に restic check --read-data-subset を実行し（範囲を限定し、ディスクを埋め尽くす完全復元は決して行いません）、ドメインごとに復元可能と検証済みバッジを表示します。頻度は設定、スケジュールに、バッジは設定、整合性にあります。
DR ドリル（オフサイト）。 BombVault はオフサイトリポジトリから実際のターゲットを使い捨てのサンドボックスへ復元し、ファイル単位・バイト単位で検証してからクリーンアップします。これは、リポジトリが応答するだけでなく、オフサイトから実際に復旧できることを証明します。

ダッシュボードのランサムウェア対策スコアカードは、これをドメインごとに緑 / 黄 / 赤の姿勢へとまとめ、経過日数を刻んだチェックリスト（オフサイト設定済み、追記専用検証済み、複製が最新、復元ドリル合格、暗号化オン、整理戦略設定済み）を示します。すべての赤い行は修正箇所へディープリンクし、カードは検証済みの事実に基づいてのみ緑になります。

インスタンスのペアリング¶

レシーバー、取得元、インスタンスページ、そして Mesh オフサイトは、いずれも別の BombVault と通信します。これらは 1 つのペアリンググループのメンバーとして行われ、インスタンスは 12 個の単語でグループに参加します。

最初のインスタンスで 設定 → ペアリング を開き、ペアリングカードで フレーズを作成 を押します。12 個の単語が、コピー ボタンのあるウィンドウに表示されます。他のすべてのインスタンスで同じ場所を開き、フレーズを入力 を押して、それらを貼り付けるか入力するか、そのウィンドウの 貼り付け を押します。リストにない単語は入力中にその位置とともに示され、最後の単語はチェックサムを兼ねているため、入力ミスや単語の入れ替わりはペアリングが成立する前に検出されます。フレーズを作成するのは 1 つのインスタンスだけにしてください。2 つのインスタンスが両方でフレーズを作成すると、2 つの別々のグループができてしまいます。1 分たっても誰も現れない場合、タブには 2 つの抜け方が示されます。単語を再表示して相手側で入力するか、相手のインスタンスの単語を入力してそのグループに一度で参加するかです。ペアリングはログインパスワードなしでも機能しますが、設定しておいてください。設定していないと、このウェブ画面を開ける人なら誰でも単語を読み取り、グループを通じてそこに含まれる各インスタンスのresticパスワードを取得できてしまいます。パスワードが設定されるまで、ペアリングカードはその旨を表示します。パスワードを設定すると、フレーズの再表示時にそのパスワードを求められます。グループを抜ける で、インスタンスを再びグループから外せます。

単語を知っている人は誰でもグループに参加できるため、パスワードと同じように扱ってください。

メンバー同士がどう到達し合うか。 各インスタンスは、サインインした瞬間にブラウザからネットワーク上の自分のアドレスを学習し、リレーカードに ネットワーク上のこのインスタンス として表示されます。手前にリバースプロキシや特殊なポートがある場合は、そこで修正してください。同じネットワーク上ではメンバーがそのアドレスをマルチキャストで告知し、直接通信します。マルチキャストが Docker のデフォルトの bridge ネットワークのようなコンテナネットワークを越えられない場合、インスタンスは代わりに自分のサブネットを検索し、グループのメンバーしか応答できない署名付きの呼び出しでほかのメンバーを見つけるため、リレーなしでもペアリングは数秒で終わります。何も見つからない場合は、ペアリングカードの下にある 見つかりませんか? から、別のサブネットや非標準ポート用にアドレスを 1 つ手入力できます。異なるネットワーク上のインスタンスはリレーを経由します。リレーは同じタブで選びます。

プロジェクトのリレー（デフォルト）: parleyport.halleluja.design。KnightLoader も使っているリレーです。設定は不要です。
自分のリレー: Unraid Community Apps の ParleyPort コンテナ、または外部からすでに到達可能で リレーとして機能させる がオンになっている自分のインスタンスのいずれかです。そのインスタンスは、すでに持っているリバースプロキシと証明書の背後で、自身のアドレスの /relay/connect で応答し、自分のグループだけを通します。使うべきすべてのインスタンスにリレーのアドレスを入力してください。
リレーなし: メンバーは同じネットワーク上でのみ自動的に互いを見つけ、それ以外の場所では見つかりません。

リレーが見えるもの。 メンバー間のすべての通信は、12 個の単語から導かれた鍵のもとで AES-256-GCM により封印され、その鍵はインスタンスの外に出ることは決してありません。リレーが知るのは、接続をまとめるハッシュ、メッセージがどのインスタンス宛てか、そのサイズ、通過した時刻だけです。ローカルネットワーク上の直接通信も同じように封印され、さらに署名もされるため、インスタンスが提供する自己署名証明書には何も依存しません。

グループ上を行き交うもの。 インスタンスページのスコアカード、ドメインを今すぐ確認する要求、Mesh のオフサイト提案、そしてレシーバーや取得元が必要とするもの、つまり相手のインスタンスのリポジトリの場所とその restic パスワードです。バックアップデータは決して行き交わず、常に restic のバックエンドへ直接向かいます。APP_KEY も同様です。restic パスワードはそのインスタンスのリポジトリだけを開き、それ以外は、保存されたシークレットもセッションも復旧コードも開きません。

ペアリング以前のエントリ。 フリートトークンで追加されたインスタンス、そして相手のインスタンスの APP_KEY で設定されたレシーバーと取得元は、更新後も残り、再度ペアリング と表示されます。レシーバーと取得元は動作し続けます。初回起動時に BombVault が、保存されている各 APP_KEY を、そこから導かれた restic パスワードに置き換えるためです。両方のインスタンスをペアリングしてから、エントリを編集してそのインスタンスを選んでください。そのようなインスタンスは、同じ名前のインスタンスがグループに現れ次第、古いカードを引き継ぎます。

それでも手動で APP_KEY を必要とする唯一の場所が別の BombVault リポジトリから復元です。相手のインスタンスがなくなっていて、グループの中で応答できない場合のためのものです。

受信側ダッシュボード（受信する側）¶

受信側を読み取り専用で監視し、整合性チェックはこのハードウェアで実行します。

受信側を読み取り専用で監視し、整合性チェックはこのハードウェアで実行します。

これまでのすべては送信側のことです。別の BombVault からイミュータブルなオフサイトコピーを受信するマシンでは、受信側ダッシュボードが、受信側のハードウェアでそれらのリポジトリを独立して読み取り専用で監視できるようにします。そのため、相手側での静かな失敗が見過ごされることがありません。

設定で レシーバー トグルをオンにすると レシーバー タブが現れます。デフォルトはオフです。実際にイミュータブルなオフサイトバックアップを受信するマシンでのみ有効にしてください。次に、受信したリポジトリを登録すると（読み取り専用、送信元インスタンスの restic パスワードで開き、それはペアリンググループ経由で届きます）、以下が得られます:

ソースごとにグループ化されたスナップショットのインベントリ。どのコンテナ、VM、ファイルセットが着信したかを正確に確認できます。
ソースごとの最終受信。それぞれがどれだけ新しいかがわかります。
受信側のハードウェアで実行される独立した restic check。整合性が、送信側だけでなく、データが実際に存在する場所で検証されます。
デッドマンズスイッチ: 設定した期間内にソースが送信を止めたときのアラート。
整合性アラート: 受信側でのチェックが失敗したときのアラート。

レシーバーは厳密に読み取り専用です。受信したリポジトリに書き込むことは決してないため、送信側が頼りにする追記専用の保証を壊すことは決してありません。

受信サーバー¶

受信側のマシンは、ほかのインスタンスがコピーを書き込む rest-server も動かせます。レシーバー タブの先頭にある 受信サーバーを設定 では、共有上のフォルダー（新しいフォルダー で作成できます）とポート番号（ほかのコンテナが使っていなければ 8000）を指定します。BombVault はこのあと次の処理を行います。

rest-server という名前のコンテナがすでにある場合や、ほかのコンテナがそのポートを使っている場合は、設定を拒否します。
restic/rest-server を取得し、Docker ソケット経由で追記専用モードで起動します。リポジトリは非公開で、ログイン用ファイルはそのフォルダーに置かれます。
Unraid テンプレートをフラッシュに書き出すので、コンテナは Docker タブで引き続き編集できます。フラッシュに届かない場合は、テンプレートをダウンロードとして提示します。
改ざんテストを実行し、削除を拒否するかどうかを表示します。

グループ内のインスタンスは、保存先ウィザードの グループから にこのサーバーを、受信側マシンの名前で見つけます。各インスタンスは、サーバーを初めて選んだときに専用のログインを受け取り、そこでは自分のフォルダーにだけ書き込みます。カードにはこれらのログインが一覧表示され、ログインを取り消す で 1 つを無効にできます。そのインスタンスがすでにコピーした分はフォルダーに残ります。設定時にはグループ外の相手向けのログインも 1 つ作られ、そのパスワードはカードに 1 度だけ表示されます。

リレー経由でしか受信側マシンに届かないインスタンスは、このサーバーを使えません。リレーはバックアップを運ばないためです。先に、設定、ペアリングで受信側マシンのアドレスを追加してください。BombVault が独自の IP アドレス（たとえば br0 上）で動いている場合は、サーバーがホストのアドレスで待ち受けるため、パートナー向けのアドレス を入力します。

実践例: 2 台の Unraid マシンを端から端まで¶

ここまでは部品の説明です。ここでは実際の値を使った完全な構成をひとつ示します。部品は一度組み上がった姿を見ておくと、ずっと組みやすくなるからです。

2 台のマシン: TOWER がコンテナを動かしてバックアップを送り、VAULT がそれを受け取って不変性を強制します。名前・アドレス・共有パスはご自分のものに置き換えてください。

1. VAULT に追記専用サーバーを立てる。 TOWER の BombVault で 設定 → オフサイト → セットアップ を開き、rest-server を選んでレシピを生成します。Unraid テンプレート (XML) タブをコピーし、VAULT に /boot/config/plugins/dockerMan/templates-user/my-rest-server.xml として保存してから、Docker → Add Container でテンプレート一覧から rest-server を選びます。起動する前に、表示された htpasswd の行を VAULT の /mnt/user/appdata/rest-server/.htpasswd に書き込んでください。ワンタイムパスワードは一度しか表示されず保存もされないので、今のうちにコピーしてください。その行には同じパスワードが bcrypt でハッシュ化された形で入っています。平文は TOWER の REST 認証情報へ、ハッシュ化された行は VAULT の .htpasswd へ。自分でハッシュ化する必要はありません。

OPTIONS 欄の `--append-only` はそのままにしてください。これこそが要点で、外すと VAULT はただの共有に戻ります。

2. TOWER でオフサイトリポジトリをそこへ向ける。 リポジトリ URL はレシピが出力する形に従います:

rest:http://VAULT:8000/bombvault-containers/containers

パスの最初の区切りが htpasswd のユーザー、2 つ目がリポジトリです。生成されたユーザーとパスワードを宛先の REST 認証情報として入力し、接続テストを実行します。

3. TOWER で「イミュータブル」を有効にする。 改ざんテストがすぐ走り、保護されています と出る必要があります。各結果の意味:

結果	何が起きたか
保護されています	VAULT が削除を拒否しました。合格はこの状態だけです。
保護されていません	VAULT が削除を受け入れました。`--append-only` が無いか、外されています。
判定不能	どちらでもありません。多くは URL が restic 自身の使うものと違うか、認証情報が変わった場合です。記録も警告も行われません。

4. VAULT で届いたものを見る。 2 台をペアリングしてから（インスタンスのペアリング）、設定 → 一般 → レシーバー を有効にし、レシーバー タブを開いて、TOWER を送信元インスタンスとしてリポジトリを読み取り専用で登録します。

場所はコンテナの内側のパスで、ホストマウントからの相対で書きます

user/appdata/rest-server/bombvault-containers/containers と入力してください。/mnt/user/appdata/… ではありません。BombVault はコンテナ内で動いており、ホストの /mnt は別の場所にマウントされているため、ホストの絶対パスはそこに存在しません。貼り付けた場合、BombVault が使うべき相対パスを教えます。

保存すると、VAULT はグループ経由で TOWER の restic パスワードを受け取ります。鍵を入力する人はいません。

5. 必要なら相互にする。 同じ 5 手順を逆向きにも行います。TOWER 上の rest-server が VAULT のコピーを受け取る形です。こうすると各機が相手の不変性を強制し、どちらも相手のバックアップを消せません。

ガイド付き復旧¶

専用の リカバリー タブが、新規または再構築したインストールを、災害ケースへと一か所で案内します:

BombVault 自身の設定をまず復元します。そのため、以降のフローが必要とするバックアップパス、オフサイトターゲット、認証情報があらかじめ入力されます（Docker ソケット経由のセルフ再起動で適用されるため、稼働中の設定データベースがオープンなハンドルの下で上書きされることはありません）。
BombVault がバックアップを読み取れるか確認します（暗号化キーの落とし穴を最初に）。
既存のリポジトリを指定させます（ローカルまたはオフサイト）。
その中に保存されているコンテナ、VM、ファイルセット、ZFS データセットを検出します。
コンテナと VM を一度に復元します（停止状態のままにするため、意図的に起動します）。ファイルセットと ZFS アイテムは一覧に表示され、1 つずつ復元します。ZFS アイテムはオフの状態で戻ります。リカバリーキットはワンクリックで手が届きます。

再構築の後、オフサイトのコピーは待機します

手順 4 が古い設定なしでエントリを再構築すると、それらのドメインのオフサイト複製は配置の既定値が確認されるまで一時停止します。項目ごとの配置を参照してください。

計画的な移行と災害時の違い

ガイド付き復旧は、BombVault 自身の設定をバックアップから復元します。計画的な新しいマシンへの移動では、代わりに設定のエクスポート / インポートカード（持ち運び可能な JSON ファイル）で設定を直接持ち運べます。設定を参照してください。

別の BombVault リポジトリから復元¶

リカバリー タブの別のカードは、別の BombVault インスタンスのリポジトリ（/mnt 配下にマウントされた共有、またはリモート URL）を、そのインスタンスの APP_KEY を使って、一度限りの読み取り専用セッションで開きます。そこに保存されているコンテナ、VM、ファイルセットを閲覧し、スナップショットを選んで復元すると、復元されたオブジェクトは通常のローカルコンテナ、VM、またはファイルセットになります。相手のリポジトリに書き込まれることは決してなく、自分のバックアップ設定は手つかずのままです（セッションはメモリ内に存在し、ひとりでに期限切れになります）。サーバー A からサーバー B へコンテナを移動することは、もはやリポジトリ設定を指し直して後で元に戻すことを意味しません。このカードは一度限りのものです。セッションを開き、選んだものを復元し、相手のインスタンスのことは忘れます。そうではなく、このマシンが別のインスタンスのスナップショットを定期的に自分のリポジトリへ取り込む恒常的な仕組みが欲しい場合は、インスタンス ページの取得タブを使います。

このサーバーに存在しないネットワークを使うコンテナ (たとえば普通の Docker ホスト上の Unraid の br0 ネットワーク) には、行の下にネットワークの選択が表示されます。BombVault は選んだネットワーク上に、ほかのネットワークを保ったままコンテナを作成します。固定 IP アドレスと MAC アドレスは古いネットワークのものなので外れ、新しいネットワークが割り当てます。

暗号化キー・リカバリーキット¶

これは、稼働中の BombVault がないときでも災害復旧を可能にする要となる部分です。

ワンクリックで、マスターキー、導出された restic パスワード、そして正確なリポジトリの場所とコマンドをダウンロードできるため、任意のマシンで restic CLI を使って直接復元できます。ダッシュボードのリマインダーは、これを保管するまでせがみ続けます。

リカバリーキットはサーバーの外に保管してください

キットには、バックアップを復号するシークレットが含まれています。サーバーとは別の安全な場所（パスワードマネージャー、金庫内の印刷したコピー）に保管してください。BombVault と APP_KEY の両方を、リカバリーキットなしで失うと、暗号化されたバックアップは復元できません。

最新のスナップショットが復元すべきものとは限りません

restic 0.17 以降、restic snapshots は各スナップショットのサイズを表示します。データを失った後は、最新のスナップショットが空になったものである場合があるので、それ以前のものよりずっと小さいスナップショットは復元しないでください。ランサムウェアの後は、普段どおりのサイズの暗号化されたものである場合があります。BombVault がまだ動いているなら、まず異常ページを確認してください。最後の正常なバックアップが示されています。復元に BombVault の異常データは必要なく、保持の一時停止はスナップショットを多く残すだけです。

キットの封印¶

プレーンエクスポートの age 暗号化をオンにしている場合（設定）、キットもそれで封印され、bombvault-recovery-kit.md.age としてダウンロードされます。バイナリではなく ASCII アーマー形式なので、プレーンなテキストのままです。パスワードマネージャーへの貼り付けや印刷はこれまでとまったく同じように使え、中身が鍵なしでは読めなくなるだけです。

age の鍵をキットの中に保管しないでください

封印されたキットを開くには age の秘密鍵が必要です。キット自体に依存しない場所に保管してください。そうしないと、復旧すべきものが 1 つではなく 2 つになります。封印が役立つのは、キットを自分で完全には管理できない場所（共有のパスワードマネージャー、クラウドのメモ、オフィスに置いた印刷物）に保管する場合です。自分の金庫にあるキットは、すでに金庫が守っています。

暗号化がオンで使える受信者が設定されていない場合、ダウンロードはきっぱり拒否されます。BombVault がマスターキーを平文で渡すことに戻ることは決してありません。

手元にキットがないとき¶

パスワードはどこにも保存されておらず、APP_KEY から計算されます。鍵とシェルさえあれば、自分で同じ値を作れます。

printf 'bombvault:restic-repo' \
  | openssl dgst -sha256 -mac HMAC -macopt hexkey:$APP_KEY -r \
  | cut -d' ' -f1

これは固定文字列 bombvault:restic-repo に対する HMAC-SHA256 で、鍵は 16 進の APP_KEY の生バイト、出力は小文字 16 進 64 文字です。同じ値はキットにも「導出された restic パスワード」として載っています。これは、キットが手元にない日のためのものです。

受信したリポジトリでは「送信側」インスタンスの鍵を使う

オフサイト複製でここに届いたリポジトリは、送ってきたマシンが自分の APP_KEY で作ったものです。受信側の鍵から導出すると restic が拒否するパスワードになり、それは壊れたリポジトリとまったく同じように見えますが壊れてはいません。受信したリポジトリで restic check が何度もパスワードを聞いてくる、いつもの原因がこれです。

リカバリー定義は各リポジトリの内側に存在するため（<repo>/def、<repo>/vm-def）、コピーされたリポジトリフォルダーは完全に自己完結しています。つまり、キットとリポジトリがあれば、ベアメタル復元に必要なものはすべて揃います。

データベースダンプを取り戻す¶

データベースダンプはコンテナ用リポジトリの中の独立した復元ポイントで、タグ dbdump:<container> を持ち、/dbdump/<container>.sql というファイルを 1 つだけ含みます。BombVault は バックアップ で一覧、ダウンロード、取り込みができますが、以下は restic だけで同じことを行う手順です。BombVault が手元にない日のためのものです。

restic -r <repo> snapshots --tag dbdump:<container>
restic -r <repo> dump --tag dbdump:<container> latest /dbdump/<container>.sql > <container>.sql

各ダンプのタグ dbversion: と dbname: は、どのサーバーバージョンから取られたか、どのデータベースを含むかを示します。完全なファイルは -- PostgreSQL database cluster dump complete または -- Dump completed で終わります。

同じかそれより新しいバージョン（PostgreSQL）、あるいは同じメジャーバージョン（MySQL と MariaDB）のコンテナに取り込みます。コンテナは空のデータフォルダーで一度起動し、初期化を済ませておきます。ホストにデータベースクライアントは要りません。コンテナが持っています。

docker exec -i <container> sh -c 'exec psql -X -U "${POSTGRES_USER:-postgres}" -d postgres' < <container>.sql
docker exec -i <container> sh -c 'exec mariadb -uroot -p"$MARIADB_ROOT_PASSWORD"' < <container>.sql
docker exec -i <container> sh -c 'exec mysql -uroot -p"$MYSQL_ROOT_PASSWORD"' < <container>.sql

全体のダンプから 1 つのデータベースだけを入れる場合、MySQL と MariaDB はクライアントのコマンドに --one-database <name> を取ります。PostgreSQL のダンプはデータベースごとに区画があり、それぞれ \connect <name> の行で始まります。その区画を別ファイルにコピーし、データベースを作ってから -d <name> で取り込んでください。

root で取ったダンプはサーバーの利用者も連れてくる

root で取った MySQL や MariaDB の完全なダンプにはシステムデータベース mysql が入っているため、取り込むと新しいサーバーのアカウントが、root のパスワードも含めてダンプのものに置き換わります。PostgreSQL では、コンテナ自身が作った利用者に対する role ... already exists は想定どおりで害はありません。