復元

復元はすべて復元ページから始まります。セクションを選び、戻したいものを検索し、バックアップを選びます。1 つのウィンドウで、あらゆる種類の項目を復元でき、手順に沿って質問されます。標準では元のものには何も起きません。バックアップはその隣に戻ってくるからです。

復元ページ

• セクションは、セクションをタイルで並べ、スナップショットのある項目がいくつあるかを表示します。
• 何を戻しますか？は、選んだセクションの項目を検索します。各行には最新のスナップショットが表示され、項目を開くでその項目のページに移動します。
• スタックは、バックアップ済みのコンテナが 2 つ以上ある Compose プロジェクトを一覧にします。たとえば、データベースと Redis を持つ immich です。検索では、スタックの名前、またはそのコンテナのどれかの名前で見つかります。
• 実行中は、実行中の復元を表示します。ウィンドウを閉じたあとも表示されます。
• 緊急は、失われた、またはセットアップし直したサーバー向けに緊急ウィザードを開始します。緊急ウィザードを参照してください。
• ほかの取得元には、別の BombVault のバックアップ用の古いバックアップフォルダーからと、Appdata.Backup プラグインから取り込むがあります。

復元ウィンドウ

項目をクリックすると、その名前で復元が開きます。手順に沿って質問され、開始する前にどの手順もやり直せます。

1. バックアップ：おすすめのスナップショットが最初から選ばれています。それは最新のもの、または未処理の異常がある場合はその直前のものです。以前の復元の前に取ったバックアップには、その復元が置き換えた状態が入っているので、ほかにない場合を除いて選ばれません。古いものは一覧にあり、比較で 2 つのあいだの違いが分かります。
2. ソース：スナップショットが複数の場所にあるとき、ファイルの取得元です。ローカルが最速です。
3. 対象：すべて、または個別ファイルで、戻したいファイルやフォルダーにチェックを入れます。

4. 復元先：行き先です。選択肢は項目の種類によって変わります。

   復元先	動作
   元の隣に	標準です。コンテナは、独自のポートを持つ <name>-restored という名前の 2 つ目のコンテナとして戻り、VM のディスクと NVRAM は <folder>-restored というフォルダーに置かれ、フォルダーセットは <path>-restored として戻ります。元のものには何も起きません。
   元を置き換える	現在あるものを上書きします。標準でオンの先に現在の状態をバックアップを使うと、BombVault はまず今の状態をバックアップするので、元に戻せます。そのバックアップが失敗した場合、復元は始まりません。これは、サーバーからなくなったコンテナや VM でも使えます。復元が上書きするフォルダーが、それだけでバックアップされます。
   フォルダーに	ファイルだけを、中身を見るために戻します。
   ZIP でダウンロード	フラッシュドライブ用で、新しいスティックに使います。BombVault が動作中のフラッシュドライブに書き込むことはありません。
   新しいデータセットへとデータセットの中へ復元	ZFS データセット用です。ZFS データセットを参照してください。

5. 実行される内容は、復元で何が起きるかを言葉で示し、選んだ復元先を場面として表示します。

復元が押せるようになる前に、ウィンドウは、リポジトリが応答すること、鍵で開けること、スナップショットがあること、復元先に空きがあることを確認します。確認が失敗している間はボタンは押せないままで、その中の (i) がどれなのかを教えます。

ウィンドウには、復元が現在あるものと比べて何を変えるかも表示されます。新規、置き換え、変更なしのファイルがあり、一覧は要求すると表示されます。また、復元先にあってバックアップにはないため、そのまま残るファイルも分かります。restic が、ファイルを読まずにサイズと更新時刻から、ドライランとして算出します。非常に大きなツリーでは、30 秒で打ち切られ、その旨が表示されます。コンテナと VM については、復元が再作成する設定と、実行中の設定を比較します。イメージとタグ、ポート、変数名、ボリューム、またはメモリ、vCPU、ディスク、ネットワークです。

何も変更する前に、復元を止めるものがいくつかあります。コンテナの固定 IP と公開ポートが空いていて、そのネットワークが存在している必要があります。Unraid では、その場での復元はすべて、マウントされたプールや共有上にないフォルダーを拒否します。ファイルがメモリ上に置かれ、再起動で消えてしまうからです。その場での復元では、書き込み先のフォルダーにバインドマウントが届いているほかのすべてのコンテナを、たとえば「このパスは nextcloud-db でも使われています」のように示しますが、これは警告だけです。

いくつかのオプションは、該当する場合に表示されます。終了後は停止したままにするは、コンテナや VM をもう一度動かす前に確認するためのものです。GPU とランタイムなしで復元は、バックアップ時に使っていた GPU やランタイムがないホストで使います。

復元はバックグラウンドで実行されます。ウィンドウを閉じても構わず、進捗は実行中にも表示されます。長い復元ではパーセントが表示され、中止もできます。中止した復元は、失敗ではなく中止として記録されます。コンテナの停止中に中止した復元や、コンテナを削除できなかった復元は、まだ何も復元していないので、コンテナはもう一度起動します。--volumes-from で別のコンテナからボリュームを受け取るコンテナはそのボリュームを保ち、その別のコンテナが存在しないあいだは、復元は始まりません。

フォルダーへの復元先

設定、復元の復元用フォルダーで、既定の復元フォルダーを設定します。セクションごとのサブフォルダーも選べ、1 つのセクションだけ例外にもできます。選んだファイルは、復元先のフォルダーの直下に置かれます。1 つのファイルならそのファイルだけ、フォルダーならその中身ごと戻り、別々のフォルダーから選んだ場合は、共通のフォルダーより下のパスだけが残ります。BombVault は、マウントされたストレージ上にない復元先を拒否します。Unraid ではそのようなフォルダーがメモリ上にあり、再起動で消えてしまうからです。また、自分自身のデータフォルダーには復元しません。

例：ファイルを 1 つ取り戻す

昨夜、誰かが Nextcloud の config.php を編集し、Nextcloud が起動しなくなりました。03:00 の夜間バックアップには、正常なファイルが残っています。戻したいのはコンテナ全体ではなく、そのファイル 1 つです。

1. 復元を開き、コンテナのタイルを選んで、何を戻しますか？に nextcloud と入力します。
2. nextcloud をクリックします。ウィンドウが開き、おすすめとして 03:00 のバックアップが最初から選ばれています。
3. ソースはローカルのままにします。
4. 対象で個別ファイルを選びます。フォルダーを config まで開き、config.php にチェックを入れます。
5. 復元先でフォルダーにを選び、フォルダーを選びます。たとえば user/restore で、ホスト上では /mnt/user/restore です。
6. 実行される内容を読みます。ファイルは復元先のフォルダーに置かれ、コンテナには何も起きません。復元を押します。

ウィンドウの最後に 完了: ファイルは /mnt/user/restore にあります と表示されます。ファイルは、上位のフォルダーなしで /mnt/user/restore/config.php にあります。壊れたファイルと見比べて、appdata フォルダーにコピーし、Nextcloud を再起動してください。

ファイルをそのまま元に戻したい場合は、手順 5 で元を置き換えるを選びます。先に現在の状態をバックアップはオンのままにして、BombVault が書き込む前に壊れた状態をバックアップするようにします。確認のため nextcloud と入力して、復元を押します。Nextcloud は、選んだファイルが元の場所に書き戻されるあいだ停止し、そのあと再び起動します。チェックを入れたファイルだけが書き込まれます。途中で失敗した復元では、Nextcloud は停止したままになります。読み込むファイルが書きかけかもしれないからで、実行にそう書かれます。

種類ごとに戻るもの

コンテナは、保存された定義から Docker API を通じて再作成されます。エントリーポイント、ホスト名、停止の設定、ボリュームとマウント、リソース制限、ログドライバー、DNS 設定、レガシーリンクも含まれます。コンテナは、バックアップ時に動いていたイメージで戻り、あとで取得された新しいイメージにはなりません。ないイメージは先に取得され、そのときは 設定、復元 のコンテナレジストリにある認証情報が使われます。GPU やランタイム（--gpus、--runtime=nvidia）も戻ります。そのドライバーやランタイムがないホストでは、復元がその旨を伝え、GPU とランタイムなしで復元を提案します。存在しないコンテナへのリンクや、復元したコンテナが起動するときに停止しているコンテナへのリンクは除外され、実行履歴にその旨が書かれます。コンテナを削除したあとで失敗した復元は、停止した状態で元に戻します。

バックアップには、コンテナでもう選ばれていないフォルダーが含まれていることがあります。たとえば、あるフォルダーがなくなる前に取った古いバックアップです。なくなったフォルダーや空のフォルダーは戻ります。いまファイルが入っているフォルダーは、意図してチェックを外したのかもしれないのでそのままにし、復元前のチェックと実行履歴にその名前が示されます。戻したいときは、個別ファイルかフォルダーにを使ってください。

VM は、XML が SSH 経由で再定義され、ディスクと UEFI NVRAM が再アタッチされます。VM を削除したあとでも同じです。Unraid スナップショットのある VM や、zvol 上にディスクがある VM については、VM のバックアップを参照してください。

フォルダーセットは、restic が保存したとおりの所有者、モード、タイムスタンプとともに戻ります。復元先が所有者の設定だけを拒否する場合（/mnt/user がそうです）、実行はそう伝える注記付きで終わります。そのあと BombVault はファイルをバックアップと照合し、届かなかったファイルがあれば復元は失敗になります。

フラッシュドライブは、動作中の /boot には一切触れません。復元は flash-<id>.zip という名前のダウンロードで、Unraid USB Creator にそのまま使えます。ZIP には APP_KEY が含まれるため、ダウンロードにはログインパスワードと、インスタンスでのサインインが必要です。ウィンドウには、各フラッシュバックアップに含まれるプラグインがバージョンとサイズ付きで一覧され、1 つだけを動作中のフラッシュに戻すこともできます。戻されるのは、その .plg ファイル、config/plugins の下のフォルダー、バックアップにあるパッケージファイルです。Unraid は次回の起動時に、または Plugins、Install Plugin からすぐにそれをインストールします。

ZFS データセットには専用の復元先があり、ZFS のプロパティが保たれます。復元を参照してください。

セルフバックアップは、緊急ウィザードからしか戻せません。ウィザードが BombVault を再起動するので、稼働中のデータベースが開いたハンドルのまま上書きされることはありません。

データベースダンプが自動で読み戻されることはありません。データベースダンプの下の行は、ダウンロード、フォルダーへの保存、新しく起動したデータベースへのインポートができます。データベースダンプを参照してください。

複数の項目をまとめて復元する

復元ページで、バックアップ一覧で行を選ぶのと同じ方法で項目を選びます。Ctrl+クリック、Shift+クリック、Ctrl+A、長押し、または選択です。復元を押すと、すべてをまとめた 1 つのウィンドウが開きます。

• どのバックアップか：おすすめは、各項目について、その項目自身のウィンドウがおすすめするバックアップを使います。全項目で同じ時点は、各項目について、選んだ時点かそれ以前の最新のバックアップを使います。たとえば、問題が起きる前の晩です。
• 復元先：元の隣にまたは元を置き換えるで、先に現在の状態をバックアップも選べます。

各項目は、単独の復元と同じように確認され、そのあと 1 つずつ順に実行されます。各行に、それぞれの結果が 待機中、実行中、復元しました、失敗、対象外 として表示されます。この項目の後で停止は、実行中の復元を終わらせ、それ以上は開始しません。フラッシュドライブは ZIP のダウンロードとして届き、ZFS データセットとセルフバックアップは 1 つずつ復元されます。

スタックを復元する

スタックカードでスタックをクリックすると、スタックを復元が開きます。すべてのメンバーを最新のバックアップから同時に復元し、復元後に依存関係順で起動を使うと、depends_on の順に起動します。データベースとキャッシュが先で、そのあとアプリです。メンバーのプロジェクトフォルダーが、選んだ場所にない場合は、ウィンドウがローカルの状態を代わりに提案します。

BombVault はまずメンバーとプロジェクトフォルダーを確認し、うまくいかない復元は何も変更しません。問題がなければ、動いているメンバーを、アプリをデータベースより先にして停止し、プロジェクトフォルダーを書き込み、それからメンバーを復元します。プロジェクトフォルダーが戻らなかった場合も、メンバーは復元されますが停止したままです。フォルダーが書きかけかもしれず、メンバーのバインドマウントはたいていそこにあるからです。各メンバーの実行にそう書かれます。

データベースダンプだけがあってファイルのバックアップがなく、コンテナと名前付きボリュームもなくなっているデータベースは、データなしで戻ります。復元の前にチェックがそう伝えます。そのデータベースは停止したままで、それに依存するコンテナも停止したままなので、空のデータベースでアプリがセットアップを始めることはありません。データベースを起動し、ダンプをインポートしてから、ほかのコンテナを起動してください。データベースダンプを参照してください。

ほかの取得元

• 古いバックアップフォルダーからは、もう動いていない別の BombVault のリポジトリを、ディスク上またはオフサイトの保存先から、そのリカバリーキットか入力した APP_KEY で開きます。セッションは読み取り専用で、メモリ上にだけ存在します。古いバックアップフォルダーからを参照してください。
• Appdata.Backup プラグインから取り込むは、プラグインのバックアップフォルダーを読み取ります。各コンテナのアーカイブは、プラグインが作成した日付で、そのコンテナのリストアポイントになります。以前に取り込んだアーカイブはスキップされ、アーカイブ自体は読み取られるだけです。復元に定義が必要なため、コンテナはまず BombVault で 1 回バックアップしておく必要があります。保持ルールは取り込んだリストアポイントに手を付けないので、不要になったら自分で削除してください。

復元のあと

元の隣に復元したコピーは、バックアップに除外された項目として一覧されるので、未対応のタスクとしては数えられません。残したいときは、スケジュールに追加してください。バックアップ時に動いていたコンテナや VM は動いた状態で戻り、停止していたものは停止したままです。Unraid では、復元したコンテナは Docker タブに通常の編集可能なアプリとして再び現れ、VM は VM Manager にディスクと NVRAM を再アタッチした状態で現れます。