J.A.R.V.I.S.計画第三十二話

Proxmox config backupの考え方 – アップグレード前に残す設定・復旧確認・月次レポート

Proxmox VEの更新前に必要なのは、バックアップを取ったという安心感だけではありません。どの設定を残し、どこまで戻せることを確認し、社長や担当者が月次で判断できる形に整えることが大切です。

Proxmox VEを運用していると、「VMのバックアップは取っています」という答えはよく出てきます。しかし、アップグレードやノード入れ替えで困るのは、VMそのものよりも、ネットワーク、ストレージ、クラスタ、バックアップジョブ、権限設定のような周辺設定です。

今回のジャービス計画では、config backupを「設定ファイルのコピー」ではなく、「復旧判断の材料」として扱います。Proxmoxのアップグレード前に残すべきファイル、実行しておく確認コマンド、復旧確認の見方、月次レポートへ落とし込む粒度を整理します。

この記事で整理すること

Proxmox config backupで残すべき設定の範囲
アップグレード前に実行する確認コマンドと保存先ディレクトリ
snapshot、vzdump、config backupを混同しない考え方
アップグレード前後の復旧確認を月次レポートにする方法
AI特命室で点検・報告へつなげる時の確認ポイント

1. config backupは「VMバックアップ」と別に考える

Proxmoxのバックアップを考える時、まず分けたいのは「仮想マシンの中身」と「Proxmox基盤の設定」です。vzdumpやProxmox Backup ServerでVMを守っていても、bridgeの設定、storage.cfg、クラスタ設定、バックアップジョブの条件が失われると、復旧時に手が止まります。

config backupは、サーバーが壊れた時だけの保険ではありません。アップグレード前に現状を固定し、更新後に差分を確認し、万一の切り戻しで何を見ればよいかを残すためのものです。

Proxmox config backupで残すネットワーク、ストレージ、VM、権限設定の図 — Proxmox config backupでは、VM定義だけでなくネットワーク、ストレージ、バックアップジョブ、権限運用を分けて控えます。

2. アップグレード前に残すファイルと取得コマンド

アップグレード前の控えは、「あとで読み返せる単位」に分けて残すのが実務的です。特に、ネットワークとストレージは小さな差分が大きな停止につながります。スクリーンショットだけでは検索や比較がしづらいため、設定ファイル、コマンド出力、画面確認の3つを組み合わせます。

対象	保存するファイル・コマンド	復旧時に見ること
Proxmox基盤	`/etc/pve/`、`pveversion -v`	クラスタ構成、ノード名、Proxmox VEの版数を戻せるか
ネットワーク	`/etc/network/interfaces`、`/etc/hosts`、`/etc/resolv.conf`	管理画面に入れるか、VMの疎通が戻るか
ストレージ	`/etc/pve/storage.cfg`、`pvesm status`、ZFS/NFS/PBSの接続メモ	VMディスクとバックアップ保存先が見えるか
VM/LXC	`/etc/pve/qemu-server/.conf`、`/etc/pve/lxc/.conf`、`qm list`、`pct list`	優先順位どおりに起動し、業務サービスが戻るか
バックアップジョブ	`/etc/pve/jobs.cfg`、PBSのdatastore名、保持世代、通知先	次回の自動バックアップが正常に動くか
権限と運用	`/etc/pve/user.cfg`、作業者、承認者、復旧判断者のメモ	誰が作業でき、誰が復旧判断するか

実際の取得は、作業前に日時入りディレクトリを作って、設定コピーとコマンド出力を一緒に保存しておくと後で追いやすくなります。外部保管する場合は、/etc/pve/priv 配下やAPI tokenなどの秘密情報を含む可能性があるため、rootのみ閲覧できる場所、または暗号化した保管先に限定します。

BACKUP_ROOT="/root/proxmox-config-backup"
STAMP="$(hostname)-$(date +%F-%H%M)"
BACKUP_DIR="${BACKUP_ROOT}/${STAMP}"

install -d -m 700 "$BACKUP_DIR/etc-pve" "$BACKUP_DIR/node" "$BACKUP_DIR/inventory"
rsync -a --numeric-ids /etc/pve/ "$BACKUP_DIR/etc-pve/"
cp -a /etc/network/interfaces /etc/hosts /etc/hostname /etc/resolv.conf "$BACKUP_DIR/node/"

pveversion -v > "$BACKUP_DIR/inventory/pveversion.txt"
qm list > "$BACKUP_DIR/inventory/qm-list.txt"
pct list > "$BACKUP_DIR/inventory/pct-list.txt"
pvesm status > "$BACKUP_DIR/inventory/pvesm-status.txt"

tar -C "$BACKUP_ROOT" -czf "${BACKUP_DIR}.tar.gz" "$STAMP"
sha256sum "${BACKUP_DIR}.tar.gz" > "${BACKUP_DIR}.tar.gz.sha256"

注意：上のコマンドは「更新前の現状控え」です。VMの実データ保護は別途 vzdump や Proxmox Backup Server で取得し、config backupだけでVMバックアップを代替しないようにします。

3. snapshot、vzdump、config backupを混同しない

snapshotは、短時間で戻るための一時的な保険です。vzdumpやProxmox Backup Serverは、VMを別世代として戻すためのバックアップです。config backupは、Proxmox基盤の設定と運用判断を戻すための控えです。目的が違うため、どれか一つで全部を代替しようとすると危険です。

第二十八話のProxmox VEアップグレード前の確認でも触れたとおり、更新前は「戻す手段」と「戻す判断」をセットで残す必要があります。今回のconfig backupは、その判断材料を補強する位置づけです。

4. 復旧確認は「戻せるか」を短く記録する

バックアップがあることと、復旧できることは別です。毎回すべてのVMを戻す必要はありませんが、代表VMを1台だけでも復元し、起動、ログイン、主要サービス、ネットワーク疎通を確認しておくと、月次報告の信頼度が上がります。

第三十話のバックアップ確認を月次レポートにする考え方と合わせると、技術ログをそのまま並べるのではなく、「現在戻せる状態か」「戻す時に誰が何を判断するか」を短く書くことが重要です。

復旧確認では、アーカイブが壊れていないか、必要ファイルが入っているか、更新前後でネットワークやVM定義に意図しない差分が出ていないかを見ます。最低限、次のような確認ログを月次レポートの根拠として残しておくと、あとから判断しやすくなります。

sha256sum -c /root/proxmox-config-backup/*.tar.gz.sha256
tar -tzf /root/proxmox-config-backup/対象アーカイブ.tar.gz | sed -n '1,80p'
diff -u /root/proxmox-config-backup/更新前/node/interfaces /etc/network/interfaces
diff -u /root/proxmox-config-backup/更新前/etc-pve/storage.cfg /etc/pve/storage.cfg
qm list
pct list
pvesm status