VM のバックアップと復元

テスト用 VM を、別のストレージへ完全バックアップして保護します。次にコピーを復元し、データが使えることを確認します。バックアップジョブの成功はテストの半分にすぎません。復元までが 1 つのテストです。

セクション 1〜5 はチュートリアルです。NFS への完全バックアップを 1 回行い、安全に復元します。その後のセクションは、これを前提とした任意のテストです。スケジュールと保持数、増分バックアップ、ファイル単位の復元、別プールへの DR レプリカ、SMB の保存先を扱います。

始める前に

• テスト用 VM を作成してインストールします。XOA-HL の管理者アカウントを使います。このバージョンのバックアップ画面には管理者権限が必要です。
• VM やアプライアンスがあるストレージとは別のバックアップシステムに、NFS エクスポートを用意します。アプライアンスから接続でき、ファイルの作成、読み取り、削除ができる必要があります。サーバー、エクスポートのパス、必要なマウントオプションをストレージ管理者に確認します。
• 空き容量を 3 か所で確認します。バックアップの保存先、VM の SR（一時スナップショット用）、復元したディスクを置く書き込み可能な SR です。設定する保持数に加えて、もう 1 回分の余裕を確保します。圧縮後のサイズは保証されません。
• ゲスト内に無害な小さいファイルを作り、内容またはチェックサムを控えます。次にゲストを通常の方法でシャットダウンし、VM が停止したことを確認します。稼働中の VM のバックアップは、アプリケーションの整合性が保証されません。
• 2 台目の VM のリソースを確保します。復元したコピーは、仮想ネットワークインターフェース（NIC）をすべて削除するまで 停止したままにします。このテストではコンソールだけを使うので、コピーにネットワークは不要です。

バックアップの管理は ブラウザー で行います。サンプルファイルの作成と確認は ゲスト内 で行います。ホストやアプライアンスのシェルは不要です。

1. バックアップの保存先を追加する

1. 設定 → リモート（/#/settings/remotes）を開きます。確認済みの適切な保存先があれば使い、なければ lab-backup-nfs という名前で作成します。
2. NFS を選び、ストレージ管理者から受け取ったサーバー、エクスポートのパス、必要なマウントオプションを入力します。ストレージ側で必要な場合を除き、詳細項目は既定値のままにします。アプライアンス内のローカルフォルダーは使わないでください。
3. 保存先を保存し、必要なら有効にして、リモートのテストをすると良いでしょう を実行します。接続エラーやテストのエラーがあれば、先に進む前に内容を確認します。

確認: 保存先が有効になり、テストが成功し、接続エラーが表示されません。これで確認できるのはアクセスだけで、VM のバックアップが復元できることまでは分かりません。

2. 完全バックアップのジョブを作成する

1. バックアップ → バックアップの作成 → VMs（/#/backup/new/vms）を開き、ジョブ名を lab-first-vm-full にします。
2. テスト用 VM だけを選びます。他の VM が含まれないよう、スマート選択はオフのままにします。
3. バックアップモードで バックアップ を選びます。これが完全エクスポートのモードです。Rolling snapshot、Delta backup、Disaster recovery、Continuous replication はオフのままにします。
4. Target remotes (for export) で lab-backup-nfs を選びます。古いバックアップを最初に削除する はオフのままにします。オンにすると、新しいエクスポートが成功する前に古いコピーが削除されることがあります。
5. スケジュールを追加します。Backup retention を 2 にし、Asia/Tokyo などのタイムゾーンを明示して、次回以降の実行のプレビューを確認します。保持数はこのスケジュールで残すバックアップの個数で、日数ではありません。
6. ジョブを保存する前に、スケジュール一覧でこのスケジュールを無効にします。最初のバックアップは手動で実行します。バックアップのスケジュールと保持数を試すまでは、スケジュールを無効のままにします。
7. 保存し、概要を確認します。VM が 1 台、保存先が正しく、スケジュールが無効になっていることを確かめます。最初のテストでは、詳細設定は変更しません。

3. バックアップを実行して確認する

1. バックアップ → オーバービュー（/#/backup/overview）で、無効にしたスケジュールの実行操作を使います。確認画面にこのジョブと VM 1 台だけが表示されていることを確かめてから、実行します。
2. 完了まで待ちます。ログを開き、ジョブが開始したことだけでなく、VM のエクスポート結果を確認します。警告、失敗、スキップされたデータがあれば調べます。
3. バックアップ → 復元（/#/backup/restore）を開きます。テスト用 VM を探し、新しい完全バックアップが想定どおりの時刻と保存先で表示されることを確認します。必要に応じて一覧を更新します。

確認: 実行が成功し、その復元ポイントが一覧に表示されます。ジョブ、スケジュール、保存先、バックアップ時刻、インストール済みのバージョンを控えます。元のゲストは再び起動して構いません。復元テストの間、スケジュールは無効のままにします。

4. 停止したコピーを復元する

1. バックアップ → 復元 で、テスト用 VM の復元操作を選び、先ほど作成した完全バックアップを選びます。
2. 空き容量が十分にある、書き込み可能な SR を選びます。これは VM ディスク用のストレージで、NFS の保存先や ISO SR ではありません。
3. Start VM after restore は オフ のままにします。Generate new MAC addresses をオンにし、コピーに別のネットワークカードのアドレスを割り当てます。MAC アドレスを変えても、ゲストの固定 IP アドレス、ホスト名、アプリケーションの識別情報は変わりません。
4. 復元を実行し、完了まで待ちます。復元ログにエラーがないか確認します。新しい VM は、名前ではなく UUID と復元されたディスクで特定します。
5. 復元した VM が停止していることを確認します。名前を lab-first-vm-restore-test に変更し、元の VM の UUID と並べて控えます。

確認: 想定したディスクを持つ、停止した別の VM があります。まだ起動しないでください。起動していた場合は停止し、どのネットワークにつながり得たかを確認してから先に進みます。

5. コピーを隔離して起動し、確認する

1. 復元したコピーのネットワーク タブ（/#/vms/<restored-uuid>/network）を開きます。停止中に NIC を すべて 削除し、一覧が空であることを確認します。「未接続」の状態では不十分です。次の起動で NIC が再接続される可能性があります。
2. UUID と空の NIC 一覧をもう一度確認します。次にコピーを起動し、コンソール を開きます。元の VM のネットワークには触れません。
3. ゲストが起動すること、コンソールからログインできること、サンプルファイルの内容またはチェックサムが一致することを確認します。復旧に必要な他のデータも確認します。ゲストが起動しただけでは、アプリケーションの復旧まで確認したことにはなりません。
4. 復元したゲストを通常の方法でシャットダウンします。結果、バックアップ時刻、復元にかかった時間、バージョンを控えます。終わったら UUID を確認し、テスト用のコピーと復元したディスクだけを削除します。元の VM とバックアップは残します。

確認: 復元したデータがサンプルと一致し、コピーは NIC がない状態で起動しました。失敗した場合はバックアップを残し、コピーを停止して、ログを読んでから再試行します。

バックアップのスケジュールと保持数を試す

このテストでは、テスト用ジョブのスケジュールを有効にし、自動実行を 3 回観察してから、再び無効にします。上記の手動バックアップと復元が成功してから行ってください。

始める前に

• テスト用ジョブ lab-first-vm-full、その無効なスケジュール 1 件、テスト用 VM 1 台だけを使います。
• すべての実行で、テスト用 VM を停止したままにします。稼働中のゲストの整合性は、別のテストが必要です。
• 空き容量と保存先へのアクセスをもう一度確認します。
• 必要な復旧用のコピーは このジョブの外 に保管します。保持数の設定により古いバックアップが削除されることがあるためです。

1. バックアップ → オーバービュー でジョブ ID を控え、クリップボードのボタンで正確なスケジュール ID をコピーします。
2. ジョブを編集します。Schedules で、既存の無効な行を編集します。削除して作り直さないでください。分かりやすいテスト用の名前を付け、Backup retention は 2 のままにします。古いバックアップを最初に削除する、長期保持、自動の復元ヘルスチェックはオフにします。バックアップ モード、テスト用 VM、lab-backup-nfs だけが選ばれていることを確認します。
3. 時刻の選択画面でテスト用のルールを作り、Timezone に Asia/Tokyo などを明示します。実行の間隔は、手動バックアップ 1 回にかかる時間に、失敗を調べる時間を加えたよりも長くします。今後の実行を少なくとも 3 回分確認し、Cron pattern を控えます。
4. ブラウザーのタイムゾーンも控えます。ルールは選んだタイムゾーンで実行されますが、プレビューはブラウザーのタイムゾーンで時刻を表示します。そのため、同じ時点でも表示される時刻が違うことがあります。プレビューは予定日時の予測であり、バックアップが実行されることを保証するものではありません。
5. 行は Disabled のまま、バックアップジョブの保存 を選びます。ジョブを開き直し、スケジュール ID、ルール、タイムゾーン、保持数、VM、保存先を確認します。ジョブとスケジュールは別々に保存されるため、エラーで一部だけが変わることがあります。すべてが一致するまで先に進まないでください。
6. オーバービュー に戻り、状態ボタンでこのスケジュールだけを有効にします。このボタンはすぐに反映され、別の保存操作はありません。更新して、行に Enabled と表示されることを確認します。
7. 手動実行ボタンは押さずに、次の実行を待ちます。実行の詳細を開き、ジョブとスケジュールの ID、開始と終了の時刻、VM、エクスポート結果を確認します。復元 で、正しい保存先に新しいポイントが表示されることを確認します。
8. このスケジュールの実行が少なくとも 3 回成功するまで待ち、毎回、復元ポイントの時刻を比べます。保持数が 2 なら、このスケジュールによるこの VM の最新の完全バックアップ 2 個が残るはずです。実際の一覧で確認してください。ファイル数を決めつけず、スキップや失敗した実行は数えません。
9. 次の予定時刻より前に、オーバービュー でスケジュールを無効にし、更新して Disabled を確認します。これで今後の実行は止まりますが、実行中のバックアップは取り消されません（このバージョンではキャンセルボタンが無効です）。実行中のバックアップは完了を待ち、次の予定時刻に何も始まらないことを確認します。
10. 定期実行で作られたポイントを 1 つ選び、セクション 4 と 5 の手順で復元します。停止したコピー、初回起動前にすべての NIC を削除、チェックサムの比較、コピーのシャットダウンの順です。コピーは VM の削除手順で削除します。最後のスケジュールの状態、残ったポイント、復元の結果を控えます。

知っておくこと

• 古いバックアップを最初に削除する がオフの場合、新しいバックアップを書いてから古いものを削除します。削除に失敗すると、新しいバックアップがあっても実行は失敗と表示されることがあります。再試行の前に実際の復元ポイントを確認し、ポイントを使う前に復元を試してください。
• 保持数は、VM、モード、保存先ごとのスケジュール ID の単位で数えます。日数、名前、ファイル数ではありません。別のスケジュールは、それぞれのポイントを残します。スケジュールを削除して作り直すと新しい ID になるため、古いバックアップは新しいポリシーの対象になりません。
• 同じジョブの実行中に始まった実行は、拒否されることがあります。アプライアンスが停止していた間の実行は、後から補われません。
• ジョブを無効化、編集、削除しても、実行中のバックアップは取り消されません。

実行がない、または失敗した場合 は、ジョブ、スケジュール、保存先の ID、予定と実際の時刻、エラー、復元ポイントの一覧を保存します。状況が分かるまでは、自動実行が始まる可能性があるものとして扱います。サーバーが稼働して時計が正しいかを確認し、次に有効状態、VM の選択、保存先へのアクセス、空き容量を確認します。解決したら、他に実行中のものがない状態でジョブを 1 回手動で実行し、新しいポイントを確認し、復元を試してから、スケジュールを再び有効にします。

ここで扱わないもの：メール通知、夏時間の切り替え、停止後の回復、長期保持、本番の保持ポリシー。

増分バックアップを使う

増分（delta）バックアップは、前回のバックアップから変わった部分だけをコピーします。このテストでは、別の delta ジョブを作って復元ポイントを 3 つ作り、保持数による整理の後でも古いポイントを復元できることを確認します。上記の完全バックアップと復元が成功してから行い、その完全バックアップは残しておきます。

始める前に

• 通常の仮想ディスクを持つテスト用 VM を使います。共有ディスクやパススルーディスク、メモリのバックアップは使いません。VM とディスク（VDI）の UUID、サイズ、サンプルファイルのパスとチェックサムを控えます。テスト中はディスクを変更しないでください。
• ストレージの担当者に新しい空の NFS エクスポートを用意してもらい、別の保存先（例：lab-delta-nfs）として追加します。
• 元の SR のスナップショット、保存先の完全バックアップ 1 回分とその後の変更、書き込み可能な SR に置く復元コピーのための容量を確保します。
• 管理者アカウントを使います。インストール環境に Delta Backup やその設定がない場合は中止し、表示されているバージョンを報告します。ライセンスを変更したり、別の画面である XO 6 向けの手順に従ったりしないでください。

delta の復元ポイントには、そのメタデータと、親となるディスクファイル（VHD）のチェーンが必要です。VHD ファイル 1 つだけでは VM のバックアップになりません。チュートリアルの完全バックアップは、この新しいチェーンの親にはなれません。

delta ジョブを作成する

1. セクション 1 と同じように保存先を追加してテストします。バックアップ → バックアップの作成 → VMs（/#/backup/new/vms）を開き、ジョブ名を lab-delta-chain にして、テスト用 VM だけを選びます。スマート選択はオフのままにします。
2. Delta Backup だけを選びます。バックアップ、Rolling Snapshot、Disaster Recovery、Continuous Replication はオフのままにします。保存先は lab-delta-nfs だけを選び、古いバックアップを最初に削除する はオフのままにします。先に作った完全バックアップのジョブは編集しません。
3. 詳細設定 で Full backup interval を 2 にします。Use NBD to transfer disk if available と Purge snapshot data when using CBT. はオフのままにします。Merge backups synchronously はオンにします。他の詳細設定は使わず、このジョブが残すスナップショットは削除しないでください。
4. Backup retention を 2 にしたスケジュールを 1 つ追加し、タイムゾーンを明示してプレビューを確認します。Force full backup はオフのままにします。オンにすると毎回が完全バックアップになります。長期保持もオフにします。スケジュールを無効にしてから保存します。ジョブを開き直してすべての設定を確認し、ジョブ、スケジュール、保存先の ID を控えます。テストの間、スケジュールは無効のままにします。

Full backup interval はチェーンの長さを決めます。2 の場合、新しいジョブは完全バックアップ、増分バックアップ、再び完全バックアップの順に作ります。日数や残すポイントの数ではありません。親の欠落、ディスクの変更、エラーによって順序が変わることがあるため、ログで確認してください。

復元ポイントを 3 つ作る

毎回の実行前に、ゲストにサンプルを書き込み、ゲストを通常の方法でシャットダウンします。実行は手動で、他のバックアップやマージが動いていないときだけ開始します。実行ごとに、実行 ID、時刻、エクスポートの Type、警告、新しい復元ポイントを控えます。タスクのすべての状態とページを確認し、必要なら生の JSON を保存します。

delta ジョブのポイントは、エクスポートが完全でも、復元の一覧で incremental と表示されることがあります。この表示やファイルサイズではなく、ログのエクスポートの Type で確認します。実行 2 が完全エクスポートだった場合は記録を残し、親のスナップショット、ディスク、間隔と Force の設定を確認します。その実行は増分転送として数えません。テストのために親を削除しないでください。

整理の前後で増分ポイントを復元する

1. バックアップ → 復元（/#/backup/restore）で、lab-delta-nfs のポイント B と、十分な空きのある書き込み可能な SR を選びます。すべてのディスク を含めます。この画面ではディスクを除外できるため、1 つずつ確認してください。
2. Start VM after restore と Use differential restore はオフのままにします。Generate new MAC addresses をオンにします。差分復元は元のスナップショットを再利用するもので、別のテストです。
3. セクション 4 と 5 のとおりにコピーを隔離して確認します。新しい UUID を控え、停止したまま NIC を すべて 削除し、起動してコンソールでファイルをチェックサム B と比べます。通常の方法でシャットダウンします。コピーは VM の削除手順で削除します。
4. 実行 3 とその整理が終わったら、ポイント B を新しい隔離コピーにもう一度復元し、チェックサム B を確認します。ポイント C も別に復元し、チェックサム C を確認します。これにより、保持数による整理の後も古い増分ポイントが使えることを確認できます。残ったポイントを控え、スケジュールは無効のままにします。

知っておくこと

• 保持数は、この保存先にあるこの VM とスケジュールのポイントを対象にします。マージの上限や整理の失敗で、余分なポイントが残ることがあります。
• 古いバックアップを最初に削除する がオフの場合、古いポイントは転送の後で削除されます。それでも、実行前の整理でデータのマージや削除が起こることがあります。
• 同期マージを使っても、実行が「すべて成功か、何も変わらないか」になるわけではなく、復旧できることの保証にもなりません。
• バックアップの JSON や VHD ファイルを手作業で削除、名前変更、移動、編集しないでください。チェーンを整理するためにスナップショットを削除しないでください。

失敗した場合（親の欠落、転送やマージのエラー、復元の失敗）は、実行の JSON、復元ポイントの ID、途中まで作られた VM とディスクの一覧を保存します。実行のたびにチェーンが変わる可能性があるため、ジョブの実行を止めます。アクセス、容量、所有者の問題をバックアップの担当者と解決してから、テストをやり直します。一般的な対処としてサービスを再起動したり、強制や修復の操作を使ったりしないでください。復旧できない場合は、独立した完全バックアップを残し、インシデントを継続します。

ここで扱わないもの：稼働中のゲスト、NBD と CBT、暗号化された保存先や他の保存先、差分復元、実際の障害からの復旧。

ファイル単位の復元（差分バックアップから 1 ファイル）

delta の復元ポイントから、ファイルを 1 つ手元のコンピューターにダウンロードします。このテストでは、上記の増分テストのポイント B を、その VM の復元が成功した後に使います。ファイルを VM に戻す操作ではありません。チュートリアルの完全バックアップは、この画面には表示されません。

始める前に

• ディスクが 1 つで、通常の読み取り可能なパーティションを持つ Linux のテスト用 VM を使います。
• バックアップ B の前に、小さなサンプルファイルのパス、内容、SHA-256 を控えます（例：/home/lab/recovery-b.txt）。
• ポイント B とそのチェーンを保存先に残します。コンピューターにアーカイブ用の空きがあることを確認します。
• 管理者アカウントを使い、インストール環境に ファイル単位の復元 があることを確認します。
• 最初のテストでは、本番の VM、個人情報、暗号化や RAID のボリューム、シンボリックリンク、フォルダーは避けます。このテストで、すべてのファイルシステム、LVM 構成、保存先に対応していることが分かるわけではありません。

1. バックアップ → ファイル単位の復元（/#/backup/file-restore）を開きます。テスト用 VM を探し、ファイルの復元操作を開きます。隣にある削除ボタンは押さないでください。VM やポイントが見つからない場合は、一覧を更新し、lab-delta-nfs が有効か確認します。先に作った完全バックアップには切り替えません。
2. 時刻とジョブで ポイント B を選び、次にディスクを選びます。パーティションの検出を待ち、サンプルがあるパーティションを選びます。パーティションテーブルのないディスクでは、ファイルシステムが直接表示されることがあります。検出に失敗したら中止します。バックアップファイルを手作業でマウントしたり編集したりしないでください。
3. / からたどってサンプルファイルまで進み、そのファイルだけ を選びます。フォルダーの選択やすべて選択は使いません。パスを確認し、形式は tgz（既定値）のままにします。zip も使えますが、遅くなることがあります。ダウンロードを開始し、ブラウザーで完了するまで待ちます。ポップアップのブロックや途中で止まったダウンロードは、成功ではありません。
4. コンピューターで、アーカイブの名前、サイズ、SHA-256 を控えます。中身を一覧し、サンプルだけを新しい空のフォルダーに取り出して、内容と SHA-256 をバージョン B と比べます。アーカイブ内のパスは信頼せず、稼働中のデータの上に展開しないでください。元の VM、ポイント B、スケジュールは変更しません。

確認: アーカイブが開け、中身がサンプルファイルだけで、そのファイルがチェックサム B と一致します。ファイル名だけの一致や、バージョン C の内容は一致とは見なしません。

いずれかの手順が失敗した場合は、記録を保存し、バックアップの担当者が確認するまで追加のバックアップを止めます。ポイントを表示させるために、チェーンのファイル、元のスナップショット、途中のファイルを削除しないでください。取り出したファイルをゲストに戻すのは、担当者の承認が必要な別の作業です。

別のプールへの DR レプリカ

Disaster Recovery（DR）は、VM 全体を別のプールの SR にコピーします。NFS バックアップとも、変更分だけを送る Continuous Replication（CR）とも異なります。コピーはレプリカと呼ばれ、停止したまま起動がブロックされています。レプリカのブロックを解除したり、起動したりしないでください。 使うときはクローンを作ります。このテストでは、隔離した場所でそのクローンを確認します。自動フェイルオーバー、元のプールの喪失、元に戻す操作（フェイルバック）はテストしません。

始める前に

• プール A のテスト用 VM と、同じ XOA-HL アプライアンスが管理する 2 つ目のテスト用プール B を使います。
• プール B の担当者に、書き込み可能な専用 SR lab-dr-sr を用意してもらいます。完全コピー 2 つとクローン 1 つ分の容量が必要です。プール A とは別のストレージにあり、ISO ライブラリではないものにします。両方のプールと SR の UUID、空き容量、SR に接続できるホストを控えます。
• チュートリアルで作った独立した NFS バックアップは残しておきます。
• 共有ディスクやパススルーディスクのない、ディスク 1 つの VM を使います。実行の前に毎回サンプル（A、B、C の順）を書き、SHA-256 を控えて、ゲストを通常の方法でシャットダウンします。
• コンソールで操作でき、本番ネットワークのない 場所をプール B に用意します。起動前に、クローンから NIC をすべて削除します。
• インストール環境で DR やターゲット SR が使えない場合は中止します。

1. バックアップ → バックアップの作成 → VMs（/#/backup/new/vms）を開き、ジョブ lab-dr-full を作成します。テスト用 VM だけを選び、スマート選択はオフのままにします。Disaster Recovery だけを選び、バックアップ、Delta Backup、Continuous Replication、Rolling Snapshot はオフのままにします。Target SRs (for replication) では lab-dr-sr だけを選びます。転送前に古いレプリカが削除されないよう、古いバックアップを最初に削除する はオフのままにします。他のジョブは編集しません。
2. Replication retention を 2 にしたスケジュールを 1 つ追加し、タイムゾーンを明示してプレビューを確認します。スナップショットの保持とヘルスチェックは使いません。スケジュールを無効にして保存します。ジョブを開き直し、VM、ターゲット SR、モード、保持数、無効状態、ID を確認します。
3. サンプル A を書いてゲストを停止した状態で、バックアップ → オーバービュー からジョブを 1 回実行します。すべてのタスクと警告を確認します。プール B で、UUID、名前に含まれるジョブ名と時刻、Disaster Recovery タグ、ディスクから、新しい 停止中 のレプリカを特定します。起動しないでください。
4. サンプル B、続いて C で、1 回ずつ実行の完了を待ってから繰り返します。実行とレプリカの ID、時刻、ディスク、エラーを控えます。3 回目の後、どのレプリカが残っているか確認します。通常は B と C です。ジョブが成功と表示されても、データが正しいとは限りません。削除に失敗しても元には戻りません。
5. 元の VM、C のレプリカ、NFS のポイントではなく、B のレプリカ を選びます。レプリカは停止したまま、プール B で一意の名前を付けて Fast clone を作ります。クローンの新しい VM とディスクの ID を控え、停止していること、起動がブロックされていないことを確認します。クローンの作成に失敗した場合や、クローンがブロックされている場合は中止します。ブロックを回避しないでください。
6. 停止したクローンから NIC を すべて 削除し、ネットワーク一覧が空であることを確認します。クローンだけを起動してコンソールを開き、サンプルをチェックサム B と比べます。通常の方法でシャットダウンします。C のクローンも同じ方法でテストできます。
7. B と C のレプリカ、NFS バックアップは残します。テスト用のクローンだけを VM の削除手順で削除します。

確認: 3 回の完全実行が正しいプールと SR に届いています。B と C が残っているか、残っていない理由を説明できます。B の隔離したクローンは独自の ID を持ち、起動時に NIC がなく、サンプル B と完全に一致します。

転送、容量の確認、削除、クローン、データの確認のどれかが失敗したら、以降の実行を止め、一覧をバックアップとストレージの担当者に渡します。レプリカの起動ブロックを外したり、名前だけでポイントを削除したり、バックアップジョブが管理するスナップショットを削除したりしないでください。

ここで扱わないもの：CR のチェーン、スケジュール実行、ネットワークの切り替え、同じ VM の二重起動の防止、フェイルバック、実際の障害。

Windows Server の SMB バックアップを試す

SMB の保存先 1 つで、完全バックアップと隔離した復元を試します。XO の画面には、SMB の保存先は Windows Server 向けであり、Linux の Samba やほとんどの NAS には NFS を勧めるという警告があります。このテストは、他の SMB サーバー、ISO や VM ディスク用の SMB ストレージ、クラウドの保存先、本番利用を対象にしません。XO は共有を CIFS でマウントし、XOA-HL のパッケージには cifs-utils が含まれますが、実際のアプライアンスでのマウントはまだ確認していません。

始める前に

• Windows Server の管理者に、テスト専用の共有 を用意してもらいます。元の VM やアプライアンスとは別のストレージにあり、バックアップと復元テストに十分な空きがあるものにします。
• その共有でファイルの作成、読み取り、削除ができる専用アカウントを用意してもらい、ネットワークのアクセスはアプライアンスからだけに限定してもらいます。サーバー名、共有名、任意のサブフォルダー、ドメイン、認証情報は安全な方法で受け取ります。
• パスワードは専用の欄にだけ入力します。XO は認証情報を含む内部の URL を作るため、XO の設定エクスポートは機密情報として扱います。その URL を共有せず、スクリーンショット、Issue、ログの抜粋、カスタムマウントオプションに認証情報を書かないでください。
• チュートリアルで作った独立した NFS バックアップは残します。同じ小さな停止中のディスク 1 つのテスト用 VM に、新しいサンプルファイルを作ってチェックサムを控えます。復元したコピー用に、書き込み可能な SR と、コンソールだけで使える場所を用意します。

1. 設定 → リモート（/#/settings/remotes）で、種類 SMB の lab-backup-smb を作成します。Address\Share には、サーバーと共有をバックスラッシュで区切って入力します。Subfolder は共有内の任意のパスで、別の共有のパスではありません。専用のユーザー名、パスワード、ドメインを入力します（初期値は WORKGROUP です。管理者から受け取った値を使います）。Custom mount options、プロキシ、暗号化は既定値のままにします。保存したら、保存先の ID、有効状態、種類、サーバー、共有、サブフォルダー、エラー表示を確認します。パスワードは表示されません。表示される URL から読み取ろうとしないでください。
2. この保存先で リモートのテストをすると良いでしょう を実行します。10 MiB のランダムなファイルを書き込み、読み戻して比べ、削除を試みます。成功アイコン、結果、失敗した段階を確認します。失敗した場合は、残った .test ファイルがないか、正確な名前で管理者に確認してもらいます。テストの成功で分かるのはこの読み書きだけで、VM の復元や継続的な転送速度は分かりません。
3. バックアップ → バックアップの作成 → VMs（/#/backup/new/vms）で、別のジョブ lab-smb-full を作成します。停止したテスト用 VM だけを選び、モードは バックアップ（完全）だけ、保存先は lab-backup-smb だけにし、古いバックアップを最初に削除する はオフにします。タイムゾーンを明示し、Backup retention を 2 にしたスケジュールを 1 つ追加します。無効のまま保存し、ID を確認します。NFS のジョブは変更しません。
4. バックアップ → オーバービュー から、無効なスケジュールを手動で 1 回実行します。ログで VM のエクスポートと保存先の結果を確認し、バックアップ → 復元 で lab-backup-smb の完全ポイントを探します。時刻、ID、サイズと、SMB のマウント、ログイン、容量のエラーを控えます。元の SR に残ったスナップショットや、保存先のテストの成功は、VM のバックアップではありません。
5. Start VM after restore をオフにして、そのポイントを用意した SR に復元します。新しい VM とディスクの UUID を控えます。コピーが停止している間に NIC をすべて 削除し、ネットワーク一覧が空であることを確認します。このコピーだけを コンソール から起動し、サンプルのチェックサムを比べてから、シャットダウンします。結果を控えるまで、元の VM、NFS バックアップ、SMB のポイントは残します。その後、テスト用のコピーだけを VM の削除手順で削除します。

確認: 保存先のテストが成功し、完全バックアップが共有に届き、隔離したコピーが NIC なしで起動して正しいデータを持っています。

アクセス、書き込み、読み取り、削除、エクスポート、復元のどれかが失敗したら中止します。認証情報を除いたエラー、正確な ID、共有の内容、途中まで作られた VM を、バックアップとサーバーの担当者に渡します。本番の共有で再試行したり、名前だけでバックアップのパスを削除したりしないでください。

ここで扱わないもの：パスワードの変更、共有の障害、複数回の実行での保持、ドメインの信頼関係、SMB のバージョンとセキュリティ設定、転送速度、他の SMB サーバー。

うまくいかない場合

実行の状態、途中までのエクスポート、安全な再試行については、失敗したバックアップを診断するを参照してください。

次の手順

復元テストに成功したら、実際のバックアップ頻度、保持数、容量の監視、アプリケーションの整合性を保つ方法を決めます。スケジュールは、タイムゾーンと次回以降の実行を確認してから有効にします。アップデートガイドと用語集も参照してください。設定の復旧と Continuous Replication には、それぞれ別の手順が必要です。