第8章　バックアップ・リストアとレプリケーション

章のゴール

本章では、Proxmox VE のバックアップ機能とレプリケーション機能の基本的な考え方を理解し、 ラボ環境でバックアップジョブの作成・実行・リストアを試せるようになることを目標とします。 本章の画面・操作例は Proxmox VE 9.1（9.x 系）を前提とします。

この章で分かること / 分からないこと

• 分かること:
  • バックアップとリストアの基本（何を、どこに、どの頻度で）
  • 「復元できること」を確認するための、最小限のテストの考え方
  • クラスタ環境でのレプリケーションの位置づけ（概念）
• 分からないこと（後続章または別パスで扱います）:
  • UI を 1 クリックずつ追う詳細手順（本章では入口の例と考え方を優先）
  • Proxmox Backup Server（PBS）を含む本番向けの詳細設計（環境依存が大きい）

事前準備（チェックリスト）

バックアップは「保管場所」が無いと始まりません。ラボでも最初に次を確認しておくと手戻りが減ります。

• バックアップの保存先を決めている（ローカル以外を推奨: 外付け/NAS/別ホスト など）
• バックアップ対象の VM（テスト用）が 1 台ある（壊してもよい VM）
• 復元テストのやり方を決めている（同じノードか、別ノードか、VMID を変えるか）

用語メモ（最小）

• バックアップ: VM/コンテナを「あとで戻せる形」で保存すること
• リストア: バックアップから VM/コンテナを復元すること
• レプリケーション: ある VM の状態を別ノードへ定期的に複製し、障害時の起動を早くするための仕組み（クラスタ向け）

バックアップの基本概念

Proxmox VE では、仮想マシンやコンテナの状態をバックアップとして取得し、 別のストレージに保存することで、障害や誤操作からの復旧に備えます。

バックアップ時に意識すべきポイント:

• どのストレージにバックアップを保存するか（ローカルディスク、外部ストレージなど）
• どのくらいの頻度でバックアップを取得するか
• どの単位（VM 単位、サービス単位）でバックアップを考えるか

重要: 「バックアップを取る」だけでは不十分です。実際に復元できること を定期的に確認してください。 本章では、ラボでできる最小限の復元テストを紹介します。

バックアップジョブの作成イメージ

Web UI からバックアップジョブを作成し、対象となる VM / コンテナ、保存先ストレージ、スケジュールなどを指定します。 ラボ環境では、まずは手動実行や低頻度のスケジュールで動作を確認するところから始めるとよいでしょう。

Web UI の入口（例）

• バックアップジョブの作成: Datacenter → Backup
• リストアの入口（例）: バックアップが保存されているストレージの Backups タブから、対象バックアップを選んで Restore

最小手順（Web UI: ジョブ作成 → 手動実行 → Restore）

1. Datacenter → Backup で Add からバックアップジョブを作成する（まずは対象 VM を 1 台に絞る）
2. 作成したジョブを選び、Run now（または同等のボタン）で手動実行する
3. 画面下部の Tasks でバックアップ実行タスク（vzdump）が OK で完了していることを確認する
4. バックアップ保存先ストレージ（例: local）を開き、Backups 一覧で対象バックアップを選んで Restore を開く

注意:

• ラボでも「復元できること」の確認が重要ですが、復元先 VMID を変える/別ノードへ復元するなど、既存 VM と衝突しない手順を優先してください。
• バックアップの保存先は “local ディスク” だけだと同一障害ドメインになりやすいため、本番では外部ストレージや PBS の利用を検討してください。

スクリーンショット（例）:

• Datacenter → Backup（ジョブ一覧）:
  • 
• バックアップジョブ作成ダイアログ（入口）:
  • 
• Tasks（手動バックアップ実行のタスクログ）:
  • 
• ストレージの Backups 一覧 → Restore（復元ダイアログ）:
  • 

補足:

• UI の配置や文言はバージョン差で変わることがあります。見つからない場合は「Datacenter（全体設定）」「ストレージ（バックアップの置き場）」を起点に探してください。
• 復元テストでは、既存の VM と競合しないように別 VMID（または別ノード）としてリストアするのが安全です。

流れの全体像は diagrams/part3/ch8/backup-restore-flow.svg にまとめます。

図で見るポイント（例）:

• バックアップ（取得）とリストア（復元）の入口がどこか
• 「復元できること」を確認するために、どこまでを成功とみなすか

スクショ無しでの最小確認（CLI）

スクリーンショットが無い段階でも、次の CLI を使うと「ジョブが動いているか」「バックアップが残っているか」を最低限確認できます。

pvesm status
pvesm list local --content backup
pvesh get /cluster/backup --output-format json
pvesh get /cluster/tasks --limit 20 --output-format json

出力例（抜粋）:

$ pvesm list local --content backup
Volid                                              Format   Type    Size
local:backup/vzdump-qemu-100-<YYYY_MM_DD-HH_MM_SS>.vma.zst vma.zst  backup  <SIZE>
...

$ pvesh get /cluster/tasks --limit 1 --output-format json
[
  {
    "type": "vzdump",
    "status": "OK",
    "node": "pve1",
    "starttime": 1700000000
  }
]

見るポイント（最低限）:

• pvesm status: バックアップ先ストレージが見えており（active）、空き容量がある
• pvesm list ... --content backup: バックアップファイルが作成されている
• pvesh get /cluster/tasks ...: 直近のタスクに status: OK がある（失敗時は Tasks とログへ）

バックアップ実行ログ（入口）:

ls -1t /var/log/vzdump/*.log | head -n 1
tail -n 50 /var/log/vzdump/<直近のログファイル>

出力例（抜粋）:

$ ls -1t /var/log/vzdump/*.log | head -n 1
/var/log/vzdump/vzdump-qemu-100-<YYYY_MM_DD-HH_MM_SS>.log

例: ラボ用バックアップ方針（最小）

迷う場合は、まず次のような「学習用の最小方針」から始めるとよいでしょう。

• 対象: テスト用 VM 1 台（例: vm-ubuntu01）
• 保存先: 別ストレージ（例: 外付け/NAS/別ホスト。可能なら “別障害ドメイン”）
• 取得頻度: まずは手動実行で 1 回、次に 1 日 1 回など
• 世代管理（保持数）: 少数（例: 3 世代）から始める

目安: RPO/RTO から頻度と確認範囲を決める

バックアップ方針を決めるときは、先に「許容できる損失（RPO）」と「許容できる復旧時間（RTO）」を言語化すると、頻度や復元テストの範囲が決めやすくなります。

注意: バックアップ頻度を上げるほど、ストレージ容量・ネットワーク帯域・ジョブ時間の要件も上がります。保持世代、実行時間帯、対象範囲（全台/重要台のみ）とセットで検討してください。

リストアの考え方

取得したバックアップから VM をリストアする際には、次の点を意識します。

• 同じホストに戻すか、別ノードに復元するか
• 既存の VM と競合しないように ID やストレージを調整する

ラボ環境では、意図的にテスト用の VM をバックアップ・削除・リストアする一連の流れを試し、 どの程度の時間と手順が必要かを体感しておくことが重要です。

復元テスト（ラボでの最小チェック）

本書では次のような「壊してよい VM」で練習することを推奨します。

1. テスト用 VM を 1 台決める（例: 第4章で作った vm-ubuntu01）
2. バックアップジョブを作成し、まずは手動で 1 回実行する（Datacenter → Backup）
3. Tasks とバックアップログ（/var/log/vzdump/）で、エラーなく完了したことを確認する
4. 保存先ストレージの Backups（またはバックアップ一覧）に、バックアップファイルが作成されていることを確認する
5. そのバックアップを、別 VMID（または別ノード）として Restore する
6. リストアした VM を起動し、ゲスト OS にログインできることを確認する

成功判定（最低限）:

• リストア処理がエラーなく完了する
• リストアした VM が起動できる
• ゲスト OS にログインでき、最低限の疎通（ping 等）が取れる

補足:

• ラボでは「元の VM を残したまま別 VMID で復元する」方法が安全です（比較できる・誤消去しない）。
• どうしても同一 VMID に戻したい場合は、まず手順に慣れてからにしてください（上書きの判断が必要になります）。

よくあるつまずきポイント

• バックアップジョブが失敗する:
  • まずは Web UI の Tasks と、/var/log/vzdump/ の直近ログを確認します。
  • 保存先ストレージの空き容量や到達性（NFS など）を疑います。
• バックアップが保存されているはずのストレージが見えない/選べない:
  • Datacenter → Storage の定義と、ストレージの Content 種別（backup を許可しているか）を確認します。
• リストア時に既存 VM と衝突する:
  • ラボでは別 VMID（または別ノード）として復元するのが安全です。
  • 既存 VM の削除や上書きは、復元手順に慣れてからにします（誤操作のリスクが高い）。

レプリケーションの概要

クラスタ環境では、特定の VM を定期的に別ノードへレプリケーション（複製）することで、 障害時に素早く起動できる “待機系” を用意することができます。

レプリケーションのパターンの一例:

• ノード A 上の重要な VM を、ノード B に定期レプリケーションする
• HA 設定と組み合わせて、フェイルオーバ先での起動を想定する

注意:

• Proxmox VE のレプリケーションは、主に ZFS のスナップショット を使って VM ディスクを別ノードへ送る仕組みです。 そのため、利用できるのは ZFS ローカルストレージ（zfspool）が前提になります。
• レプリケーションはバックアップの代替ではありません（誤操作の取り消し・長期保管・別障害ドメインへの退避には不向きです）。
• ラボでは「バックアップ/リストア」と混同しないよう、目的（RPO/RTO の違い）を意識してください。

ラボでの実践パターン

• 単一ノードラボでは、まずは（別ディスクや外部ストレージなどの）バックアップ先へのバックアップとリストアを通じて基本の流れを確認する
• 3 ノードクラスタラボでは、共有ストレージやレプリケーションを利用した復旧シナリオを検証する

これらの練習を通じて、「バックアップを取っているつもり」ではなく、 実際に復元できるかどうかを確認する習慣を身につけることが、本章の狙いです。

ミニ演習（手を動かす）

• バックアップ対象の VM を 1 台決め、手動バックアップを 1 回実行する（Datacenter → Backup / VM → Backup など、環境に合わせて）
• Tasks と /var/log/vzdump/ を確認し、「成功/失敗」の入口がどこかをメモする
• ラボで安全にできる範囲で、別 VMID として 1 回リストアし、起動とログインまで確認する

まとめ

• バックアップは「何を・どこに・どの頻度で残すか」を運用として決め、ジョブとして継続的に実行できる形にします。
• 重要なのは「取れていること」ではなく「復元できること」です。ラボでも最小の復元テストを行い、成功判定を確認します。
• レプリケーションは ZFS ローカルストレージ前提の仕組みで、バックアップとは目的が異なります（RPO/RTO を意識して使い分けます）。
• 次に読む章: 第9章「運用・監視・トラブルシュート」で、日常運用と障害時の入口を整理します。