Assumptions

This runbook assumes:

• single node
• no active cluster
• fresh reinstall of the Proxmox boot/system disk
• guest data/backups will be available after reinstall
• guests will be restored from vzdump backups, not by reusing old raw config files

That last point is important: restore from backup, not old VM config, because Proxmox will handle any config differences more cleanly.

What to back up before reinstall

Be selective.

A. Proxmox host identity/config

Back up:

• /etc/hostname
• /etc/hosts

B. Networking

Back up:

• /etc/network/interfaces

C. Storage and cluster filesystem config

Back up:

• /etc/pve/storage.cfg

Even on a non-clustered node, this is still the correct Proxmox storage config file to preserve.

D. Mounted storage

Back up:

• /etc/fstab

This is important if you have local filesystems, backup mounts, NFS helper mounts, or other storage dependencies that must return after reinstall.

E. Guest backup inventory

Record:

• qm list
• pct list

And ideally keep a text inventory of which guests map to which backup files.

F. Guest backups

Take vzdump backups of every VM and CT.

This is the preferred recovery path.

---

BACKUP

Back up the required files

Example:

mkdir -p /root/pve-reinstall-backup

cp /etc/hostname /root/pve-reinstall-backup/
cp /etc/hosts /root/pve-reinstall-backup/
cp /etc/network/interfaces /root/pve-reinstall-backup/
cp /etc/fstab /root/pve-reinstall-backup/
cp /etc/pve/storage.cfg /root/pve-reinstall-backup/

qm list > /root/pve-reinstall-backup/qm-list.txt
pct list > /root/pve-reinstall-backup/pct-list.txt

Then tar it:

tar czf /root/pve-reinstall-backup-$(date +%F).tar.gz -C /root pve-reinstall-backup

Copy that archive off the host.

Take vzdump backups of all guests

Back up all VMs and containers to storage that will survive the reinstall or to external storage.

Example approach:

vzdump --all 1 --mode stop --compress zstd --storage 

If snapshot mode is not available for some guests/storage, use the appropriate fallback mode.

Afterwards verify the backups exist, for example on your backup datastore or mounted backup path.

Also record the file list:

find /path/to/backup/location -maxdepth 1 -type f | sort > /root/pve-reinstall-backup/vzdump-files.txt

Copy that off too if helpful.

Pre-reinstall validation

Before wiping anything, confirm:

• backup archive of config exists off-host
• vzdump backups exist and are readable
• you know where those backups are stored
• you know whether backup storage needs fstab to remount after reinstall
• you know the management IP, gateway, hostname, DNS
• you know which disk/LUN is the OS target

If backups are on separate mounted storage, make sure that storage will not be destroyed.

---

INSTALL

Install Proxmox VE 9.1 fresh

Boot the 9.1 ISO and install onto the system disk only.

Recommended during install:

• use the same hostname if possible
• use the same management IP if possible
• keep the basic bridge naming consistent if possible

Do not try to manually recreate everything during the installer beyond what is needed to get the node online.

9. First boot after install

After the first boot:

• confirm the node is reachable
• log in to the shell
• verify the clean install is healthy

Check:

pveversion -v
ip a

Do not restore guests yet.

---

RESTORE

Restore the core node configuration selectively

Now restore only the selected files.

A. Host identity

Restore:

• /etc/hostname
• /etc/hosts

B. Networking

Restore:

• /etc/network/interfaces

Be careful here if you are remote. If there is any risk of lockout, apply cautiously.

C. Mounted storage

Restore:

• /etc/fstab

Then mount:

mount -a

Validate all expected mounts appear.

Proxmox storage config

Restore:

• /etc/pve/storage.cfg

This brings back the Proxmox-defined storage entries, including cluster filesystem storage config semantics even on a standalone node.

Once restored, check in the UI or via CLI that the storages appear as expected.

Validate storage before guest restore

Before restoring any guests, make sure:

• backup storage is mounted
• any VM target storage is mounted/present
• all entries in storage.cfg resolve correctly
• no stale or invalid storage references remain

Useful checks:

mount
cat /etc/fstab
cat /etc/pve/storage.cfg
pvesm status

If pvesm status shows storage problems, fix those first.

Optional: remove local-lvm / LVM-thin after reinstall

If the installer recreated default LVM-thin and you do not want it, do this only after confirming nothing uses it.

Typical sequence:

1. confirm no guests/disks are on local-lvm
2. remove local-lvm from storage.cfg
3. optionally remove the underlying thin pool/LVs if you want to reclaim space

This step is environment-specific, so I would mark it as:

• Optional design cleanup
• only after validation
• only if you are sure the storage is unused

I would not make destructive LV removal an automatic part of the mainline procedure.

Restore guests from vzdump

Why this is better

Using vzdump:

• avoids relying on old raw config compatibility
• lets Proxmox restore with the current version’s expected config handling
• reduces risk from direct file restoration between major versions

Restore process

For each backup:

• restore to the correct target storage
• confirm VMID and guest name
• restore one guest at a time
• test before moving on

Examples:

VM restore

qmrestore /path/to/backup/vzdump-qemu--.vma.zst  --storage 

If restoring with the same VMID, use that VMID if free.

LXC restore

pct restore  /path/to/backup/vzdump-lxc--.tar.zst --storage 

Adjust storage names as needed.

Post-restore validation per guest

For each restored guest:

• check config in UI/CLI
• confirm NIC attachment/bridge
• confirm disk target storage
• start guest
• verify boot
• verify application/service health

Useful commands:

qm list
pct list
qm config 
pct config 

---

VALIDATE

Final validation

After all restores:

• confirm all expected storages are active
• confirm all mounts from /etc/fstab are present
• confirm networking is correct
• confirm backups run again
• confirm no unwanted local-lvm dependency remains if you chose to remove it

---

CONSIDERATIONS

External Storage

If you're using NFS or ZFS or other external storage that in on different physical or logical disks than Proxmox/Debian - then you can, with full backups and recovery plan - leave this in place - which avoids the guest backup and restore process. 

However, you will need to manually re-mount this storage post install if it doesn't automatically come back after restoring storage.cfg. 

In addition to the host config you already identified, also back up:

/etc/pve/qemu-server/
/etc/pve/lxc/

That gives you the guest definitions, and post install, you'll need to copy these back AFTER you have confirmed that the external storage is back in the same physical/logical location. If not, disks and resources won't be found and guests won't start. 

---

SUPPORT

Discuss this upgrade with your support provider before going it alone in an enterprise environment. There are many things that can go wrong, albeit it fairly simple to resolve, like udev naming network devices or disks unpredictably, and minor corrections to cfg files, etc. 

Plan, Test, Have support in place.