Proxmox VE 8 to 9 Upgrade: Backup Checklist

An in-place upgrade from Proxmox VE 8 to 9 has no undo button: if it fails halfway, the official way back is a fresh installation and a restore of every guest from backup. Proxmox VE 8 reached end of life in August 2026, so this upgrade is due on most hosts now. This checklist shows what to back up before you run apt dist-upgrade, how to prove that the backups work, and what to check after the first reboot.

Why the Backup Is Your Rollback

The Proxmox wiki is clear: a valid and tested backup is always required before the upgrade. The guide does not describe a way to go back to version 8 on the same installation. The only alternative to a working upgrade is a fresh install and a restore of your VMs and containers.

Version 9 changes a lot under the hood. The base moves from Debian 12 (Bookworm) to Debian 13 (Trixie). The kernel changes. Network interface names can change. /etc/sysctl.conf is no longer read. Containers that need cgroup v1 (systemd 230 or older) do not run. Most upgrades go through without problems, but you plan for the one that does not.

A good backup plan for the upgrade has three parts:

1. Current backups of all guests, on a server that is not the host you upgrade.
2. A backup of the host configuration, so that you can rebuild the node with the same network, storage, and cluster settings.
3. Proof that both backups can be restored.

Step 1: Run the pve8to9 Checklist

Before you change anything, run the checklist script that ships with the latest Proxmox VE 8.4 packages:

pveversion
pve8to9 --full

The script only reads and reports. It does not change the system, so you can run it on a production host at any time. Fix each warning, then run it again until it is clean. The official upgrade guide also lists these prerequisites:

If PBS runs on the same host, upgrade it with its own guide from version 3 to 4. Back up /etc/proxmox-backup before you start.

Step 2: Fresh Guest Backups to an Offsite PBS

Run a new backup of all guests directly before the upgrade. A backup from last week does not contain the changes since then. Use your PBS storage as the target:

# Replace offsite-pbs with the ID of your PBS storage
vzdump --all 1 --storage offsite-pbs --mode snapshot

Snapshot mode keeps the guests running. For a database server that must be fully consistent, stop the application or the guest first, or use the QEMU guest agent so that the file systems are frozen during the snapshot.

When the job is done, open the task log. Every guest must show Backup finished successfully. A job that skipped one guest is easy to miss in a long log.

PBS deduplicates the data. Only new chunks go over the network, so a fresh backup of all guests is usually much faster than the first full backup. For an explanation of why, see how fast incremental backups work.

Step 3: Back Up the Host Configuration

Guest backups contain the guests. They do not contain the node itself: network bridges, storage definitions, cluster membership, APT sources, or kernel options. If you must reinstall, you need these files.

The most important locations are:

• /etc/pve: guest configs, storage.cfg, users, firewall rules, and the keys in /etc/pve/priv.
• /var/lib/pve-cluster/config.db: the database behind /etc/pve.
• /etc/network/interfaces: bridges, bonds, and VLANs. Interface names can change in version 9, so you will compare against this file.
• /etc/hosts, /etc/hostname, /etc/resolv.conf.
• /etc/apt/: your repositories.
• /etc/default/grub or /etc/kernel/cmdline, and /etc/modprobe.d/: boot and driver options, for example for PCI passthrough.
• /etc/sysctl.conf and /etc/sysctl.d/: version 9 no longer reads /etc/sysctl.conf.
• /etc/frr/ if you use a Ceph full mesh or SDN with FRR.
• /root/.ssh/: keys for cluster and remote access.

The simplest way is a host backup with proxmox-backup-client to the same PBS. /etc/pve is a separate FUSE mount, and the client does not cross mount points by default. Add it with --include-dev:

export PBS_REPOSITORY='backup@pbs!upgrade@pbs.example.com:mydata'
export PBS_PASSWORD='<api-token-secret>'

proxmox-backup-client backup \
  etc.pxar:/etc \
  pve-cluster.pxar:/var/lib/pve-cluster \
  root.pxar:/root \
  --include-dev /etc/pve

As an extra safety net, also copy a plain archive to your workstation. A tar file is readable without any Proxmox tools:

tar czf /root/$(hostname)-pre-pve9.tar.gz \
  /etc /var/lib/pve-cluster /root/.ssh
scp /root/$(hostname)-pre-pve9.tar.gz admin@workstation:~/

The archive contains secrets: keys, tokens, and passwords. Store it like a password file. For more on host backups, see how to back up any Linux server to PBS.

Step 4: Verify the Backups and Test a Restore

A backup job that says "OK" only proves that data was written. Before the upgrade, prove that you can read it back.

qmrestore offsite-pbs:backup/vm/100/2026-11-04T18:00:00Z 9100 \
  --storage local-lvm --unique

For single files, the File Restore button in Proxmox VE is the fastest way. The file-level restore guide shows the GUI and the command line.

Step 5: Secure the Keys and the Access

Some things you cannot get back from a backup if the host is gone. Check them before the upgrade:

• Encryption key. If your PBS storage uses client-side encryption, Proxmox VE keeps the key in /etc/pve/priv/storage/<storage-id>.enc. If this file exists only on the host, a failed host takes the key with it, and nobody can read the backups. Keep a copy in a password manager. See PBS client-side encryption.
• PBS connection details. Write down the server, datastore, user or API token, and the certificate fingerprint. You need them to add the storage to a fresh node.
• Console access. Test the IPMI or iKVM login now. If the interface names change, SSH can be gone after the reboot.

After the Upgrade: Check Your Backups

When the node runs version 9, the backup work is not finished yet.

Run pve8to9 again. The guide asks you to run the checklist after the upgrade and before the reboot.

Check the network first. Compare ip link with your saved /etc/network/interfaces. If a name changed, fix the config from the console. Version 9 includes pve-network-interface-pinning to pin interface names.

Move sysctl settings. If you had settings in /etc/sysctl.conf, move them to a file in /etc/sysctl.d/. Your host backup has the old file.

Watch the first backup job. The reboot clears the dirty bitmaps of all VMs. The first backup after the upgrade reads each disk completely, so it takes longer. Deduplication still applies, so it does not upload the full disks again. From the second run, the backups are fast again.

Check that the PBS storage is still active. In the resource tree, check that your PBS storage on the node shows as active, and that the next scheduled job runs without errors.

Common Mistakes

• Old backups only. The last nightly job ran before a large change. Run a new backup directly before the upgrade.
• No host backup. The guests are safe, but the network and storage config is gone. A reinstall then takes hours instead of minutes.
• Encryption key only on the host. The backups exist, but nobody can read them.
• No console access. A changed interface name locks you out of SSH.
• Upgrade of all cluster nodes at once. Upgrade one node, check it, and move the guests before you upgrade the next one.

Wrapping Up

The upgrade from Proxmox VE 8 to 9 is routine for most hosts, but there is no way back on the same installation. Run pve8to9 --full, make fresh guest backups to an offsite Proxmox Backup Server, back up the host configuration, and test one restore. Keep the encryption key and the console access ready. Then a failed upgrade costs you a reinstall and a restore, not your data.