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

Proxmox VEをアップグレードする時の注意点

バックアップ、RAM込みsnapshot、dry-run、停止判断、再起動後検品までを一つの運用にする

2026年6月17日に実施したProxmox VE 8.4から9.2への作業記録をもとに、アップグレード前後で何を確認し、どこで止め、どう報告するべきかを整理します。

Proxmox VEのアップグレードは、コマンドを順番に打つ作業ではありません。実際には、バックアップが戻せるか、稼働中VMをどう守るか、dry-runの差分を読めるか、失敗条件が出た時に止められるか、再起動後に全体を検品できるか、という判断作業です。

今回の記事では、YouTubeチャンネル「ニリアコット・ジャービス計画」EP006公開のお知らせと、当社内の2026年6月17日作業記録を踏まえ、技術担当者と経営者の双方が見落としやすい注意点をまとめます。

作業前: 日次バックアップ、RAM込みsnapshot、権限、空き容量、作業ログ保存先を確認する。
作業中: dry-runと事前チェッカーで、削除されるパッケージや失敗条件を読む。
作業後: PVE本体、VM、主要サービス、Guest Agent、残課題を検品してから完了扱いにする。

1. アップグレードは「コマンド」ではなく「判断作業」

Proxmox VEの大型アップグレードでは、手順書どおりに進めるだけでは足りません。現場では、今は進めてよいのか、一度止めるべきなのか、誰に確認すべきなのか、という判断が何度も出ます。

たとえば2026年6月17日の作業では、最初の pve8to9 --full で FAILURES: 1 が出ました。原因は systemd-boot メタパッケージで、ここで無理に進めず、削除対象を確認してから再実行しました。

このように、アップグレード作業の本質は「成功コマンドを知っていること」ではなく、危ないサインを見た時に止まれることです。

Proxmox VEアップグレードで事前棚卸し、dry-run確認、検品と記録を分けて進める判断フロー — アップグレードは、事前確認、dry-run、実行判断、再起動後検品を分けて考えると事故を減らせます。

2. 事前棚卸しで、止める条件を先に決める

作業前に見るべきものは、現在のバージョンだけではありません。対象ホスト、稼働VM、ストレージ、バックアップ、snapshot、管理権限、作業ログ保存先、緊急連絡先をそろえて初めて、アップグレードに入れます。

当社作業では、07:35にNrktTenchiがProxmox VE 8.4.16であること、root空き容量が十分あることをAPIで確認し、07:44にUSB-Backupへ当日分のVMバックアップ一式があることを確認しました。その後、稼働中VM 9台すべてにRAM込みsnapshotを作成しています。

バックアップが「存在する」だけでは不十分です。どこまで戻せるか、どの時点へ戻すためのものか、戻す権限と手順があるかまで確認します。

3. RAM込みsnapshotは「直前の稼働状態」へ戻るための保険

日次バックアップとsnapshotは、同じ「戻す材料」でも役割が違います。日次バックアップは保管と災害復旧の材料です。一方、作業直前のRAM込みsnapshotは、今まさに稼働しているVMの状態へ戻るための一時的な保険です。

2026年6月17日の作業では、VM 100, 110, 120, 130, 200, 210, 220, 230, 300の9台に pre_pve92_20260617_0748 を作成し、各タスクがOKであることを確認してから先へ進みました。

日次バックアップ、RAM込みsnapshot、復旧確認の役割の違いを示す図 — 日次バックアップ、作業直前snapshot、復旧確認は目的が違います。すべてを同じ保険として扱わないことが大切です。

4. dry-runで見るのは、成功ではなく「危ない差分」

dry-runや事前チェッカーで見るべきものは、成功メッセージだけではありません。削除されるパッケージ、メタパッケージの扱い、enterprise repositoryの混入、source listの切替、未適用更新、microcode、稼働中VM、権限不足を見ます。

今回の作業では、apt-get -s dist-upgrade で proxmox-ve が削除対象にならないこと、想定範囲のt64置換であることを確認してから本実行しました。PVE 9への切替後にenterprise source由来の401が出たため、該当sourceを無効化して再確認しています。

確認項目	見る理由	止める条件の例
バックアップ	戻り先がなければ作業は始められないため。	当日分なし、保存先不明、復旧手順不明。
snapshot	作業直前の稼働状態へ戻す材料になるため。	running VMでRAM込みsnapshotが取れない。
dry-run	本実行前に危ない削除やrepository差分を読むため。	proxmox-ve削除、想定外の大量削除、FAILURESあり。
再起動後	起動しただけでは業務復旧とは言えないため。	PVE/VM/主要サービス/ストレージに異常。

5. 再起動後の検品は、PVE本体だけで終わらせない

再起動後にWeb UIが見えたとしても、そこで完了ではありません。作業記録では、Proxmox VE 9.2.0、kernel 7.0.6-2-pve、PVEサービス異常なし、syslog error系抽出なし、VM 9台runningを確認しています。

さらに、各VMの主要サービスやQEMU Guest Agent状態、snapshot残存、旧kernelやold RRDなどの残課題も確認しました。こうした検品を残しておくと、次回の月次アップデート時に「前回どこまで片付けたか」が分かります。

当社では2026年7月以降、毎月第二月曜日07:30にProxmox VE月次アップデートを実施し、再起動が必要な更新が検出された場合はそこで停止して社長判断を仰ぐ運用へつなげています。

6. AI特命室では、作業を月次レポートに変える

Proxmox VEのアップグレードや月次更新は、技術者だけの作業で終わらせるともったいない分野です。経営者が知りたいのは、どのサーバーが動いているか、どこにリスクが残っているか、今月止めた判断は正しかったか、来月何を決めるべきかです。

ニリアコットAI特命室では、こうした作業ログを読みやすい月次レポートに整理し、バックアップ、復旧確認、VMware代替相談、Proxmox運用の自動化までつなげます。関連する入口として、第二十六話のバックアップ・復旧確認、Proxmox VEホスト本体のバックアップ術、第十七話のProxmox VE運用自動化もあわせてご覧ください。