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

Proxmox config backupを月次点検に組み込む実践手順

安全な確認コマンド、前月差分、異常判断、最終報告を一つの運用へつなぐ

Proxmox config backupの月次点検を表すサーバー、バックアップケース、チェックリストの実写ミニチュア — サーバー、保護されたバックアップ、チェックリストを月次で照合する運用イメージです。

前回の第三十二話では、Proxmox config backupで何を残すか、どこまで復旧確認を行うかという考え方を整理しました。今回は、その考え方を月次点検へ落とし込みます。

結論は単純です。毎月同じ項目を、同じ順番で、同じ形式へ保存し、前月との差分を「意図した変更」「要確認」「即時停止」に分けます。バックアップが存在するだけではなく、判断に使える証跡になっていることが完了条件です。

安全上の前提

以下は読み取り中心の確認例です。実IP、実ホスト名、API token、パスワード、証明書秘密鍵、/etc/pve/priv/ 配下の内容は、記事・チャット・月次報告へ出しません。復元、再起動、設定変更のコマンドは含めず、必要な場合は別の承認済み手順書で扱います。

Proxmox config backupの現況確認、証跡保存、前月差分、異常判断、最終報告の5段階 — 月次点検を、現況確認・証跡保存・前月差分・異常判断・最終報告の5段階に固定します。

1. 最初は読み取りだけで現況をそろえる

Proxmox VEでは、クラスタ構成の中心がpmxcfsにあり、/etc/pve にクラスタ、ストレージ、VM/LXC、権限、バックアップジョブなどの設定がまとまります。公式のProxmox Cluster File System文書でも、秘密情報を含む領域が明示されています。月次点検では、まず秘密値を表示しない一覧とAPI出力をそろえます。

# 1. バージョンとクラスタ状態
pveversion -v
pvesh get /cluster/status --output-format json-pretty
pvesh get /cluster/resources --type vm --output-format json-pretty

# 2. ストレージとクラスタ全体のゲスト一覧
pvesm status

# 3. 定期バックアップジョブと権限の一覧
pvesh get /cluster/backup --output-format json-pretty
pveum acl list

# 4. ノード単位の補助確認（各ノードで個別に実行）
qm list
pct list

# 5. pmxcfsの構成ファイル一覧（秘密領域は除外）
find /etc/pve -maxdepth 2 -type f ! -path '/etc/pve/priv/*' -printf '%P
' | sort

コマンドの役割は、pvesh, pvesm, qm, pct, pveum の公式リファレンスで確認できます。環境やPVE版によって出力列が変わることがあるため、月次比較ではバージョンも必ず残します。

公開用に匿名化した出力例

検査日時: 2026-07-17 09:50 JST
対象: node-a / node-b（公開用サンプル名）
PVE package: 9.x 系
Cluster nodes: 2 / online: 2
Storage: 4 / active: 4 / inactive: 0
Cluster guests: 11 / QEMU: 8 / LXC: 3
Backup jobs: 2
Existing config backup: 1 file / non-empty / SHA-256取得済み
Inspection evidence: 8 files / non-empty / JSON確認済み / SHA-256検証済み
秘密領域: 出力・記事・報告書へ未記載

ここで見るのは、単なる件数ではありません。クラスタ全体のゲスト数は /cluster/resources --type vm から数え、qm list と pct list は各ノードで個別に照合します。ノードが全台onlineか、保存先がactiveか、保護対象が前月より減っていないか、バックアップジョブの数が変わっていないかを一組として見ます。

2. 同じ名前・同じ順番で証跡を保存する

月ごとに保存先を分け、ファイル名を固定すると差分が機械的に取れます。次の例は証跡ファイルを新規作成するだけで、Proxmox設定自体は変更しません。ただし保存先の権限と容量は事前に決め、実行者を管理者に限定します。

# この例は途中失敗を成功扱いにしない
set -eu
for cmd in pveversion pvesh pvesm pveum find sort xargs diff stat sha256sum perl install; do
  command -v "$cmd" >/dev/null 2>&1 || { echo "missing command: $cmd" >&2; exit 127; }
done

# 検査証跡の保存先を作る（例）
CHECK_MONTH='2026-07'
CHECK_DIR="/root/pve-monthly-check/${CHECK_MONTH}"
install -d -m 0700 "$CHECK_DIR"

# 読み取り結果を同じ順番で保存する
pveversion -v > "$CHECK_DIR/pveversion.txt"
pvesh get /cluster/status --output-format json-pretty > "$CHECK_DIR/cluster-status.json"
pvesh get /cluster/resources --type vm --output-format json-pretty > "$CHECK_DIR/cluster-resources-vm.json"
pvesm status > "$CHECK_DIR/storage-status.txt"
pvesh get /cluster/backup --output-format json-pretty > "$CHECK_DIR/backup-jobs.json"
pveum acl list > "$CHECK_DIR/acl-list.txt"

# 空ファイルとJSON構文・最低限の型を検証する
for file in   pveversion.txt cluster-status.json cluster-resources-vm.json   storage-status.txt backup-jobs.json acl-list.txt; do
  test -s "$CHECK_DIR/$file" || { echo "empty evidence: $file" >&2; exit 65; }
done
perl -MJSON::PP -0777 -e '$d=decode_json(<>); ref($d) eq "ARRAY" or die "cluster-status: top level must be array\n"; for (@$d) { ref($_) eq "HASH" && exists $_->{type} && exists $_->{name} or die "cluster-status: invalid item\n" }' "$CHECK_DIR/cluster-status.json"
perl -MJSON::PP -0777 -e '$d=decode_json(<>); ref($d) eq "ARRAY" or die "cluster-resources: top level must be array\n"; for (@$d) { ref($_) eq "HASH" && exists $_->{type} && exists $_->{id} or die "cluster-resources: invalid item\n" }' "$CHECK_DIR/cluster-resources-vm.json"
perl -MJSON::PP -0777 -e '$d=decode_json(<>); ref($d) eq "ARRAY" or die "backup-jobs: top level must be array\n"; for (@$d) { ref($_) eq "HASH" && (exists $_->{id} || exists $_->{schedule}) or die "backup-jobs: invalid item\n" }' "$CHECK_DIR/backup-jobs.json"

# 既存の保護済みconfig backup本体を読み取り検証する
# 実行前に、承認済み手順書に記載された実在パスへ置き換える
BACKUP_ARTIFACT='<APPROVED_CONFIG_BACKUP_FILE>'
test "$BACKUP_ARTIFACT" != '<APPROVED_CONFIG_BACKUP_FILE>' || { echo 'set approved backup path' >&2; exit 64; }
test -r "$BACKUP_ARTIFACT" && test -s "$BACKUP_ARTIFACT"
stat -c '%n|%s|%y' "$BACKUP_ARTIFACT" > "$CHECK_DIR/config-backup-stat.txt"
sha256sum "$BACKUP_ARTIFACT" > "$CHECK_DIR/config-backup-sha256.txt"

# 証跡の時刻・サイズ・ハッシュを残す
find "$CHECK_DIR" -maxdepth 1 -type f -print0 | sort -z | xargs -0 stat -c '%n|%s|%y'
find "$CHECK_DIR" -maxdepth 1 -type f ! -name 'SHA256SUMS' -print0 | sort -z | xargs -0 sha256sum > "$CHECK_DIR/SHA256SUMS"
sha256sum -c "$CHECK_DIR/SHA256SUMS"

config backup本体と月次証跡は分ける

上のJSONや一覧は「点検証跡」です。実際のconfig backup本体、config.db、VM/LXCバックアップ、PBSの保持世代は、既存のバックアップ手順と暗号化・アクセス制御に従って別管理します。証跡だけで復旧できるとは判断しません。

3. 前月との差分を、理由と影響まで読む

差分は「変わったから異常」ではありません。承認済みの変更と一致するか、保護対象や復旧可能性を弱めていないかを読みます。まず同名ファイルを比較します。

PREV='/root/pve-monthly-check/2026-06'
CURR='/root/pve-monthly-check/2026-07'
set -eu

# 差分1は「差分あり」として受け入れ、2以上の読取エラーは失敗にする。
compare_files() {
  if diff -u "$1" "$2"; then
    return 0
  else
    rc=$?
    if test "$rc" -eq 1; then
      return 0
    fi
    return "$rc"
  fi
}

compare_files "$PREV/storage-status.txt" "$CURR/storage-status.txt"
compare_files "$PREV/cluster-resources-vm.json" "$CURR/cluster-resources-vm.json"
compare_files "$PREV/backup-jobs.json" "$CURR/backup-jobs.json"
compare_files "$PREV/acl-list.txt" "$CURR/acl-list.txt"
compare_files "$PREV/config-backup-stat.txt" "$CURR/config-backup-stat.txt"

差分の読み方サンプル

--- 2026-06/storage-status.txt
+++ 2026-07/storage-status.txt
@@
-backup-store  pbs  active  62%  38%
+backup-store  pbs  active  68%  32%

判定: 容量使用率が6ポイント増加。保存先はactiveのため即停止ではない。
対応: 増加理由と保持世代を確認し、次月予測が80%を超える場合は要対策。

--- 2026-06/backup-jobs.json
+++ 2026-07/backup-jobs.json
@@
-"schedule": "sat 02:00"
+"schedule": "mon..fri 02:00"

判定: バックアップ頻度の変更。変更記録と承認が一致するまで「要確認」。

差分	判断	次の安全な一手
バージョン更新、容量増加	変更記録と閾値に一致すれば正常	根拠を月次報告へ添付
ジョブ頻度、保持世代、権限の変化	要確認	変更せず承認記録と照合
保存先inactive、保護対象減少、ハッシュ不一致	停止	影響範囲を固定し、責任者へ即時報告

Proxmox config backupの前月証跡、当月証跡、差分判断、最終報告の流れ — 前月と当月を比較し、差分の理由と影響を判断したうえで最終報告へつなぎます。

4. 異常判定は3段階に固定する

正常

差分なし、または承認済み変更と一致。ストレージ、保護対象、証跡検証が合格。

要確認

差分の理由や承認記録が未照合。設定変更は行わず、担当者確認を待つ。

停止

保存先inactive、保護対象減少、証跡破損、権限の重大差分など。作業を止め、影響と根拠を即時報告。

自動化する場合も、この判定をAIだけで確定しないのが安全です。AIは差分抽出、候補分類、報告文の下書きを担当し、変更理由・業務影響・復旧判断は人間が承認します。これはProxmox VE運用自動化, バックアップ復旧確認, アップグレード前後の確認, RTO/RPO月次レポートにも共通する考え方です。

5. 最終報告テンプレート

最終報告は、ログの羅列ではなく、判断に必要な数字・差分・影響・次の一手を一枚へまとめます。

【Proxmox config backup 月次点検】
検査日:
対象ノード:
担当者:

1. 現況
- PVEバージョン:
- ノード数 / online数:
- ストレージ数 / inactive数:
- QEMU数 / LXC数:
- バックアップジョブ数:

2. 証跡
- 保存先:
- SHA-256検証:
- 秘密情報の除外:

3. 前月差分
- 差分:
- 変更記録との一致:
- 影響:

4. 判断
- 正常 / 要確認 / 停止:
- 根拠:
- 次の安全な一手:

5. 次回
- 次回確認日:
- 保留事項:

記入済みサンプル

【Proxmox config backup 月次点検】
検査日: 2026-07-17
対象ノード: node-a / node-b（公開用サンプル名）
担当者: インフラ担当

1. 現況
- PVEバージョン: 9.x系 / 2台一致
- ノード数 / online数: 2 / 2
- ストレージ数 / inactive数: 4 / 0
- QEMU数 / LXC数: 8 / 3
- バックアップジョブ数: 2

2. 証跡
- 保存先: 管理者限定の月次証跡領域
- SHA-256検証: 合格
- 秘密情報の除外: 合格

3. 前月差分
- 差分: PBS使用率62%→68%、ジョブ頻度変更1件
- 変更記録との一致: PBS増加は運用内、ジョブ頻度は確認待ち
- 影響: 容量は継続監視、ジョブ頻度は承認一致まで要確認

4. 判断
- 要確認
- 根拠: バックアップ頻度の差分に承認記録を未照合
- 次の安全な一手: 設定変更を行わず、担当者と承認記録を照合

5. 次回
- 次回確認日: 2026-08-17
- 保留事項: ジョブ頻度変更の承認確認