XO 設定のエクスポートと復旧の準備

アプライアンスの保守の前に、XO の設定をファイルに保存し、VM のバックアップとは別に保管します。次に、そのファイルを使い捨てのアプライアンスでテストします。プールのメタデータには専用のバックアップジョブが必要です（後述）。作業はブラウザーで、XOA-HL に XO 管理者としてログインして行います。

エクスポートに含まれるもの

エクスポートには XO の設定が保存されます。ユーザーとグループ、アクセス規則、サーバー接続、リモート、ジョブ、スケジュール、認証トークン、プラグイン設定です。サーバーのパスワード、リモートの認証情報、トークンが含まれることがあるため、ファイルは機密情報として扱ってください。

エクスポートが完了しても、そのファイルでインストール環境を復元できるとは限りません。イメージとアプリケーションのバージョンを一緒に記録しておきます。

1. エクスポートをダウンロードして保存する

1. ブラウザーで XO 管理者としてログインします。インストール済みのバージョンを記録します。
2. 設定 → Config（/#/settings/config）を開きます。Export の下で Download current config を選びます。
3. 一意のパスフレーズを入力して確定します。空欄のままにすると、エクスポートは暗号化されません。
4. アプライアンスを失っても使えるように、パスフレーズは別に保管します。
5. ブラウザーが新しいウィンドウをブロックした場合は、ダウンロードを許可します。空でないファイルが保存されたことを確認します。ファイル名は config.json.gz で、暗号化した場合は .enc が付きます。VM のバックアップに見える名前に変えないでください。
6. ファイルを、アプライアンスの外にある保護されたストレージに移します。日付、ファイルサイズ、バージョン、暗号化の有無を記録します。
7. 新しいエクスポートが、隔離したアプライアンスでのインポートテストに合格するまで、以前のエクスポートも残します。

確認: 元のアプライアンスがなくても、ファイルとパスフレーズを取り出せます。ファイルを公開 Issue に添付したり、復号した内容を報告に貼り付けたりしないでください。

2. 隔離したアプライアンスでインポートをテストする

始める前に

• 記録したものと同じイメージとパッケージのバージョンの、使い捨てのアプライアンスを使います。
• インポートの前にネットワークを制限します。テスト用のブラウザーからは接続でき、アプライアンスからは本番のホスト、バックアップのリモート、外部サービスに接続できない状態にします。
• この制限は XO の外で行います。インポートの前に接続やスケジュールを無効にしても、インポートで元に戻る可能性があるため不十分です。
• 新しいアプライアンスの状態を記録します。インポートでアカウントが変わることがあるため、エクスポートした設定の認証情報を用意しておきます。

1. 設定 → Config を開きます。エクスポートしたファイルを選択またはドロップし、Import を選び、エクスポートのパスフレーズを入力します。成功またはエラーのメッセージを待ちます。
2. インポートが成功したら、ログアウトし、エクスポートに含まれる管理者アカウントでログインします。
3. ユーザー、権限、リモート、サーバー、ジョブ、スケジュールを、元の環境の記録と比べます。ネットワークを遮断している間は、サーバーへの接続エラーが出るのが想定どおりです。
4. 使い捨てのテスト用リソースへのアクセスを許可する前に、インポートしたスケジュールを無効にし、本番の保存先を削除するか置き換えます。テストのたびに、これらの設定を再確認します。
5. インポートが失敗したら、エラーと、機密情報を除いた xo-server のログを記録します。次の試行では、そのアプライアンスを破棄し、新しいアプライアンスから始めます。失敗したインポートが何も変更していないとは考えないでください。

確認: エクスポートした管理者でログインでき、ユーザー、権限、リモート、ジョブ、スケジュールが記録と一致します。成功のメッセージだけでは、復旧できることの証明にはなりません。誤ったパスフレーズ、ユーザーの競合、中断したインポートはここでは扱いません。

プールメタデータを保存する

独立した Pool metadata ジョブで、プールのメタデータをバックアップします。XO は選んだプールから XAPI の /pool/xmldbdump ストリームを読み取ります。そして、リモートの xo-pool-metadata-backups/<schedule>/<pool>/<timestamp>/ に data と metadata.json を書き込みます。これは 設定 → Config のエクスポートでも、VM ディスクのバックアップでも、アプライアンスのイメージでもなく、テスト済みのホスト復旧手段でもありません。メタデータからインフラの詳細が分かることがあります。リモートへのアクセスを制限し、これらのファイルを公開 Issue に添付しないでください。

始める前に

• 自分が所有し、作り直せる使い捨てのプールを 1 つ使い、XOA-HL に接続しておきます。このテストのために本番のプールを変更したり復元したりしないでください。
• 書き込み可能な専用の NFS バックアップ用リモートを使います。1 つの障害で両方が影響を受けないよう、そのプールのストレージに依存しない場所にします。
• ゲストのデータには、別に VM のバックアップと復元の計画を用意します。
• インストール済みのイメージとパッケージを確認します。管理者がメタデータのバックアップ画面を使えることも確認します。このバージョンでは、プランの確認によって画面が表示されないことがあります。表示されなければ中止します。
• プールの UUID、マスターとホストの識別情報、リモートの ID と空き容量を控えます。

無効のジョブを作成する

1. バックアップ → バックアップの作成 を開き、XO config & Pool metadata Backup（/#/backup/new/metadata）を選びます。ジョブ名を lab-pool-metadata にします。
2. Pool metadata だけを有効にし、XO config はオフのままにします。
3. 使い捨てのプールを明示的に選びます。専用のリモートだけを選びます。他のプールやリモートは追加しません。
4. タイムゾーンを明示したスケジュールを 1 つ追加します。Pool retention を 2 にし、スケジュールは無効のままにします。
5. 保存します。ジョブとスケジュールの ID、プール、リモート、モード、保持数、無効の状態を読み直します。エディターがこれらを保持していなければ中止します。

ジョブを 3 回実行する

1. 保存したスケジュールから、ジョブを手動で実行します。時刻を控えます。これを実行 A とします。
2. 実行が終わるまで待ちます。ジョブのログで、子タスクも含めてプールとリモートごとに確認します。全体の成功表示だけでは、リモートのコピーが完全であることの証明にはなりません。
3. 実行の ID、状態、元のプールの UUID を控えます。
4. 時刻を変えて、実行 B と C を繰り返します。前の実行が終わってから次を開始します。

残ったポイントを確認する

1. バックアップ → 復元 → メタデータ（/#/backup/restore/metadata）を開きます。有効なリモートの pool の行、時刻、利用できるポイントを確認します。復元や削除は選ばないでください。
2. 保持数が 2 なので、残るのは実行 B と C のポイントだけです。実行 A、B、C の記録と比べます。
3. ストレージ管理者がリモートを直接開ける場合は、残った各ポイントを確認してもらいます。data と metadata.json が空でなく、ジョブ、スケジュール、プールの識別情報が一致することを確認します。ファイルサイズとハッシュは保護された場所に記録します。内容は公開しません。
4. 不完全なポイントや、想定外の整理結果は、調査のために残します。

このジョブはチェックサムなしでファイルを書き込みます。一覧に表示されたポイントや成功したタスクは、XAPI でインポートできることの証明にはなりません。

確認: スケジュールは無効のままで、3 回の実行が意図したプールとリモートを示し、残った B と C のポイントとそのファイルが記録と一致します。エクスポート、リモートへの書き込み、整理、一覧表示のどれかが失敗したら、ジョブの実行を止め、ログとインベントリを保存します。名前だけを根拠にバックアップのフォルダーを削除しないでください。

プールを復元する前に

プールの復元は、選んだポイントの data を対象プールの /pool/xmldbdump に送ります。プールが変更され、元に戻す方法は確認されていません。復元の前に、プールの所有者が次のものを用意する必要があります。

• 隔離された使い捨ての対象プール
• バージョンと識別情報が一致する復旧計画
• イメージまたはメタデータの別の予備コピー
• 本番のネットワークとストレージへのアクセスの遮断
• 復元後にホストとプールの接続とインベントリを確認する方法

これらを確認した後でのみ、正確なポイントを 1 つと対象プールを 1 つ選びます。利用できるポイントやエクスポートの成功は、復旧できることの証明にはなりません。XO 設定のエクスポートとゲストのバックアップは別に保管します。復元そのもの、一括復元、別のプールへの復元はここでは扱いません。

復旧とロールバックの制約

実際に障害が起きた場合は、故障したアプライアンスと証拠を残します。正確なバージョンを特定し、そのバージョンで隔離テストに合格した復旧計画を使います。有効なスケジュールを持つ 2 つのコピーを、同じ本番の保存先に接続しないでください。

古い RPM パッケージがあっても、完全なロールバックにはなりません。ダウングレードしても OS の更新は元に戻らず、XO のデータや上記の別管理のファイルも復元されません。このリリースでは、異なるバージョン間のインポートと、ダウングレードによる復旧はテストされていません。更新に失敗した場合は、保守とトラブルシューティングを参照してください。