Entry / Article

Proxmox VEで作業用ディスクを除外し、復元試験まで終えたVMバックアップ

2026/10/12 1 min read

PVEのvzdumpでUbuntu Desktop VMを停止バックアップし、/work用ディスクをbackup=0で除外した。SSH切断による中断、fstabのnofail設定、別のVM IDへの復元試験から得た手順をまとめる。

PVEの仮想ディスク編集画面。Advanced表示時にBackupのチェックを外せる。

Ubuntu Desktop VMのOSディスクだけを残し、再生成できる/work用ディスクを除外したところ、120 GiBの仮想ディスクを6分44秒でバックアップできた。完了ログに記録されたアーカイブサイズは41.85 GiBだった。バックアップ容量と所要時間を把握できただけでなく、別のVM IDへ復元して起動まで確認できたことで、この構成を復旧手順として使える状態にできた。

この記事では、Proxmox VE（PVE）標準のvzdumpを使い、停止中のVMをUSB HDDへバックアップした手順と、途中で見つかった復元時の落とし穴を整理する。

本文中の仮想ディスク容量はPVEの表示に合わせてGiBで統一し、ログの引用だけは出力どおりの単位を残す。

バックアップの対象をOSディスクに絞った

バックアップ対象はGPUパススルーを設定したUbuntu Desktop VM。OS用のscsi0は120 GiB、LLMエージェントの作業領域である/work用のscsi1は200 GiBある。/workは再生成できるデータなので、OSやVM設定と同じ扱いで保管する必要はない。

バックアップ先には、PVEでbackupコンテンツだけを許可したUSB HDDを用意した。PVEのディレクトリ型ストレージでは、backupがvzdumpのバックアップファイルを置けるコンテンツ種別だ。Proxmox VEのストレージ仕様も、この用途でストレージごとにコンテンツ種別を選べるとしている。

最初は既存のusb-1tbを指定したが、次のエラーで実行できなかった。

could not get storage information for 'usb-1tb':
can't use storage 'usb-1tb' for backups - wrong content type

ストレージがactiveでも、backupを許可していなければ保存先には使えない。またバックアップ用途でSSD容量を消費したくなかったので、バックアップ専用にHDDでusb-4tbを作り、内容をbackupだけにした。

`backup=0`で`/work`ディスクを除外する

VMのディスク単位でバックアップ対象を外すには、PVEのGUIで対象ディスクを編集し、AdvancedにあるBackupのチェックを外す必要がある。CLIなら、既存オプションを保ったままbackup=0を付ける。

qm set 100 --scsi1 usb-1tb:100/vm-100-disk-0.raw,iothread=1,backup=0

設定後は、次のように確認できた。

scsi1: usb-1tb:100/vm-100-disk-0.raw,backup=0,iothread=1,size=200G

これは「容量を減らすだけ」の変更ではないので、除外したディスクがなくても、ゲストOSが起動できる設計にしておく必要がある。これをしておくと、バックアップのリストア確認で効いてくる。

まずは停止バックアップを選んだ

今回は、ディストリビューション更新やGPU周辺の大きな変更の前に、確実に戻れる地点を作るのが目的だった。そのため、無停止性より分かりやすさを優先してstopモードを選んだ。

vzdump 100 --storage usb-4tb --mode stop --compress zstd

通常のファイル型ストレージへ保存するvzdumpバックアップは、ここではフルバックアップとして扱う。差分保存や重複排除を必要とするほど頻繁な運用ではないため、Proxmox Backup Serverは導入しなかった。

初回はSSH上で直接実行したため、接続断とともに処理がシグナルで中断された。PVEのタスクログには、SSHセッション終了の直後にinterrupted by signalが記録されていた。

sshd-session: Connection reset by peer
vzdump: ERROR: Backup of VM 100 failed - interrupted by signal

次回からは、端末切断に依存しないようnohupで起動した。

nohup vzdump 100 --storage usb-4tb --mode stop --compress zstd 2>&1 &
tail -f nohup.out

このバックアップでは、期待どおりscsi1が除外された。

INFO: include disk 'scsi0' 'local-lvm:vm-100-disk-1' 120G
INFO: exclude disk 'scsi1' 'usb-1tb:100/vm-100-disk-0.raw' (backup=no)
INFO: include disk 'efidisk0' 'local-lvm:vm-100-disk-0' 4M

完了ログは以下のとおり。

INFO: transferred 120.00 GiB in 399 seconds (308.0 MiB/s)
INFO: archive file size: 41.85GB
INFO: Finished Backup of VM 100 (00:06:44)
INFO: Backup job finished successfully

VMの仮想ディスク容量は120 GiBでも、ゼロ領域の扱いとZstandard圧縮により、アーカイブは41.85 GBに収まった。

復元試験で`fstab`の依存を見つけた

バックアップファイルができても、復元できなければ意味がないので、リストア可能か実際に確認する。元のVMを残したまま、別のVM IDである104へ復元して起動を試した。

PVEのVM 104への復元タスク。EFIディスクとscsi0が復元されている。

復元後のqm config 104にはscsi1がなかった。これは意図どおりだったが、最初の起動ではログイン画面の後にデスクトップが表示されなかった。原因はゲストOSの/etc/fstabだった。

/workは除外したscsi1にあり、元のVMでは必須マウントとして設定していた。復元先にはそのディスクが存在しないため、起動処理が/workのマウントに依存していた。

元VMの/etc/fstabで/workをnofail付きに直してから、再度バックアップと復元を実施した。結果として、復元したVM 104は/workをマウントしない状態で正常に起動し、デスクトップも利用できた。

UUID=<WORK_DISK_UUID> /work ext4 defaults,nofail 0 2

この修正は、バックアップ方針とゲストOSの起動方針をそろえるためのものだ。backup=0にするディスクは、ゲスト側でも「なくても起動できる」と定義して初めて安全に除外できた。

復元試験では競合する設定にも注意する

別のVM IDへの復元では、OSディスクだけでなくVM設定も戻る。今回のVMにはGPUパススルー、USBパススルー、同じMACアドレスのNIC設定が含まれていた。そのため、元のVM 100と復元先のVM 104は同時に起動しないよう注意が必要。

復元試験の順序は次のようにした。

元のVMを停止する。
バックアップを別のVM IDへ復元する。
qm config <VMID>で、除外したscsi1が復元されていないことを確認する。
復元先のVMだけを起動し、ログイン、デスクトップ、GPU認識を確認する。
/workが未マウントでもOSが正常に使えることを確認する。

LXCのbind mountは別の方法で保護する

Samba用LXCでも、ホストのディレクトリをbind mountで見せる構成を使っていた。PVEの設定画面ではBackupが無効になっている。

Proxmox VEのコンテナ設定によると、bind mountの内容はvzdumpでバックアップされない。LXCバックアップで守るのは、rootfs（ルートファイルシステム）、Samba設定、ユーザー情報だ。共有データを置くホスト側ディスクには、別のバックアップ方針が必要になる。

まとめ

今回の検証で、次の4点を確認できた。

`backup=0`で作業用ディスクを除外するなら、ゲストOS側でもnofailを設定し、ディスクがなくても起動できるようにする。
バックアップ先は、ストレージがactiveであるだけでなく、backupコンテンツを許可する必要がある。
SSHから実行する長時間のバックアップは、nohupやtmuxで接続断の影響を避ける。
別のVM IDへ復元して起動を試し、GPUパススルー、MACアドレス、bind mountなどの復旧時の競合を確認する。