How to Reinstall Proxmox VE Without Losing Your VMs and Data (Step-by-Step Guide)

Introduction

Something's gone wrong with your Proxmox host. Maybe an update left the boot partition in a weird state, maybe you're switching from ext4 to ZFS, or maybe you just want a clean install without the accumulated cruft of two years of tinkering. Whatever the reason, the idea of wiping the OS drive is scary the moment you remember you've got a dozen VMs and containers actually doing useful work.

Here's the good news: reinstalling Proxmox VE doesn't have to mean rebuilding everything from scratch. The installer only touches the disk (or disks) you tell it to touch, and your VM data usually lives somewhere the installer never sees. Get the details right and you can have a fresh install talking to your old VMs within an hour.

This guide covers both situations you'll run into: keeping data on a separate disk or ZFS pool that survives the reinstall untouched, and the case where everything's on one drive and you need a real backup first. Commands below are current for Proxmox VE 9.x (built on Debian 13 "Trixie"), and everything except the ZFS import syntax works identically on 8.x.

What You Will Learn

• Why a Proxmox reinstall doesn't automatically destroy your VMs
• How to tell whether your VM disks are safe from the installer or not
• How to back up the configuration files that make your VMs "exist" as far as Proxmox is concerned
• The exact steps to reinstall and reconnect an existing ZFS storage pool
• The exact steps to reinstall and restore from a vzdump backup when your data isn't on separate storage
• Which commands do what, and the errors that trip people up

What Is This Feature?

There isn't a single "reinstall without losing data" button in Proxmox. It's really a combination of a few things Proxmox already does: the installer's disk selection screen, ZFS pool import/export, and the vzdump backup format.

The short version: a VM in Proxmox is really just two separate things glued together. There's the configuration — a small text file in /etc/pve/qemu-server/ (or /etc/pve/lxc/ for containers) that describes the CPU count, RAM, disk assignments, and network cards. And there's the disk image itself, which lives on whatever storage you pointed it at — a ZFS pool, an LVM-thin volume, a directory, or an NFS share.

Reinstalling Proxmox wipes the boot disk and rebuilds that config database from nothing. It does not touch any disk you don't explicitly select during setup. So if your VM disks live on a second drive, and you didn't select that drive in the installer, the raw data survives just fine — Proxmox just doesn't know it exists anymore until you tell it to look.

Why Would You Use It?

A few real scenarios where this comes up constantly:

• You installed on ext4 and now want ZFS (or the reverse) for the boot drive, and a conversion isn't practical.
• The boot drive is failing or you're moving to a new, faster NVMe drive.
• You inherited a messy install — half-finished experiments, leftover repositories, a subscription nag you never cleared — and want a clean baseline without rebuilding every VM by hand.
• You're going from a non-clustered single node to joining a cluster and want to start that node fresh.

None of these are emergencies. That matters, because it means you have time to do this properly instead of panicking and hoping for the best. Take the time — restoring from a bad backup is a much worse afternoon than making a good one.

Prerequisites

• A working Proxmox VE 8.x or 9.x install you plan to reinstall.
• A USB drive and the Proxmox VE ISO, written with something like Etcher or Rufus (or dd if you're comfortable with it).
• Root or SSH access to the host you're about to wipe.
• Somewhere to put a backup that isn't the disk you're about to erase — a USB drive, an NFS share, another machine, or a Proxmox Backup Server if you have one.
• Enough free space on that backup target for at least one full copy of your largest VM disks, if you're going the vzdump route.
• About 10-15 minutes for the actual OS install, plus however long your data transfer takes.

Step-by-Step Tutorial

Step 1: Figure out which situation you're in

Run this on the host you're about to reinstall:

pvesm status

Look at the Type column. If your VM disks live on storage marked zfspool, lvm, or lvmthin on a second physical disk (not the one Proxmox is booted from), you're in the lucky situation — the data survives a reinstall automatically, and you're following Path A below. If everything is on local-lvm or local and there's only one disk in the machine, you're in Path B, and you need a real backup first.

Not sure which physical disk backs which storage? Run lsblk and compare disk sizes and mount points against what pvesm status reported. It's worth five minutes of double-checking — guessing wrong here is exactly how people lose data.

Step 2: Back up your configuration either way

Regardless of which path you're on, the VM and container config files are small, and losing them is annoying even when the disk data is fine — you'd have to manually recreate every VM's hardware settings by hand. Back them up from another machine over SSH, or to a USB stick plugged into the host:

tar czf pve-config-backup.tar.gz \
  /etc/pve/qemu-server \
  /etc/pve/lxc \
  /etc/pve/storage.cfg \
  /etc/network/interfaces \
  /etc/hosts /etc/hostname

That tar command bundles up your VM configs, container configs, the storage definitions, and your host's basic networking so you're not reconstructing your bridge and VLAN setup from memory afterward. Copy the resulting file somewhere off the machine — a laptop, a NAS, anywhere that isn't the disk you're about to wipe.

Step 3 (Path A): Reinstall with a separate data pool

Boot the installer and, on the disk selection screen, pick only the boot drive. Leave your data disk (or disks) completely unchecked — the installer will not touch anything you don't select. Double- and triple-check the disk model and size shown on that screen before continuing, especially if the drives are similar sizes.

Finish the install normally: time zone, root password, network config, the usual. Once you're rebooted into the fresh install, SSH in and import your old pool:

zpool import

Run it with no arguments first — it lists every importable pool it can see without touching anything. Confirm the pool name is the one you expect, then import it for real:

zpool import your-pool-name

If ZFS complains that the pool was last used by another system (it will, because technically it was), add -f to force it:

zpool import -f your-pool-name

Once it's imported, add it back as storage in Proxmox — either through Datacenter → Storage → Add → ZFS in the web interface, or by restoring the storage.cfg entry from your Step 2 backup. Your VM disks are sitting right there on the pool. All that's missing is the config files telling Proxmox those VMs exist.

Step 4 (Path A): Restore the VM configs

Copy the config files from your Step 2 backup back into place:

tar xzf pve-config-backup.tar.gz -C /
systemctl restart pve-cluster pvedaemon pveproxy

Refresh the web interface and your VMs should reappear in the tree, pointed at the disks that were sitting on the imported pool the whole time. Start one and confirm it boots before you relax.

Step 5 (Path B): Back up everything with vzdump first

If your data was never on separate storage, you need an actual backup of the VM disks, not just the configs. Point vzdump at your external target — here it's an NFS share already added as storage named backup-nfs:

vzdump --all --mode snapshot --storage backup-nfs --compress zstd

--all backs up every VM and container on the host in one pass. --mode snapshot keeps things running while it backs up instead of shutting them down, which matters if you can't afford downtime right now. --compress zstd is the fastest of the compression options Proxmox ships, and the size difference versus gzip is small enough not to worry about for a one-off backup.

Let it finish completely — check the task log in the GUI, or watch the terminal output if you ran it over SSH. A partial backup because you unplugged the drive early is worse than no backup, since it looks fine until you actually need it.

Step 6 (Path B): Reinstall and restore

Run the installer as normal, selecting the same disk (or a new one if you're upgrading hardware). Once you're back up on the fresh install, add your backup storage back — NFS share, USB drive, or PBS — the same way it was configured before.

Restore VMs one at a time:

qmrestore /mnt/pve/backup-nfs/dump/vzdump-qemu-105-2026_07_20-02_00_01.vma.zst 105

And containers with the equivalent command:

pct restore 110 /mnt/pve/backup-nfs/dump/vzdump-lxc-110-2026_07_20-02_00_01.tar.zst

The number right after qmrestore or pct restore is the VMID you want it restored as — usually just the original ID, unless you have a reason to change it. Doing this through the GUI works too: go to your backup storage, click Backups, select the archive, and click Restore.

Commands Explained

Command	What it does
pvesm status	Lists every storage location Proxmox knows about and what type each one is (directory, ZFS, LVM, NFS, and so on).
lsblk	Shows every disk and partition attached to the machine, with sizes — useful for confirming which physical disk is which before you wipe anything.
zpool import	With no arguments, scans for ZFS pools that could be imported without actually importing them. Safe to run any time.
zpool import -f <pool>	Forces the import of a pool that ZFS thinks is still "owned" by a different (or the previous) system install.
vzdump --all --mode snapshot	Backs up every VM and container while they keep running, using a filesystem-level snapshot so the backup is consistent.
qmrestore	Restores a QEMU VM backup archive to a given VMID.
pct restore	Restores an LXC container backup archive to a given container ID.

Common Errors

"cannot import 'your-pool-name': pool was previously in use from another system" — This is ZFS being cautious, not broken. It just means the pool's last-known host doesn't match the one importing it, which is exactly what happens after a reinstall. Add -f and move on.

"unable to restore VM 105 - VM 105 already exists on cluster node" — Something on the fresh install already claims that VMID, usually because you tested a restore twice or the config file survived from a partial config restore. Delete the conflicting config in /etc/pve/qemu-server/105.conf or restore to a different ID with qmrestore ... 105 --unique.

Storage shows up as "unknown" in the GUI after importing a pool — You imported the ZFS pool at the shell but never told Proxmox about it as storage. Add it under Datacenter → Storage, matching the pool name exactly, or restore your old storage.cfg.

VM boots but has no network — Your bridge name changed, or the NIC got renamed by the new install (common if you swapped hardware). Check qm config <vmid> against what bridges actually exist with ip a, then edit the VM's network device to match.

Troubleshooting

If a VM won't start after restoring its config, check qm config <vmid> first. The most common issue is a storage name mismatch — the config still references a storage ID like local-zfs that doesn't exist under that exact name on the new install. Rename the storage to match, or edit the disk line in the config to point at the storage you actually created.

If zpool import shows nothing at all, double check the data disk actually got connected before boot — it's easy to leave a drive unplugged during a hardware swap. Run lsblk to confirm the kernel even sees it.

If the web interface itself won't load after restoring configs, give pve-cluster a minute to rebuild its database from the files you dropped in, then check systemctl status pve-cluster. A crash loop there usually means one of the restored files got truncated during copying — try the restore again from a fresh copy of the backup archive.

Best Practices

Keep VM storage on a separate physical disk from the boot drive whenever your hardware allows it. This one habit turns "reinstall the OS" from a data-recovery exercise into a fifteen-minute chore, and it's the single biggest thing you can do to make future reinstalls painless.

Back up /etc/pve on a schedule, not just before a planned reinstall. A cron job that tars it up nightly to another machine costs nothing and saves you from the reinstalls you didn't see coming — a dead boot drive doesn't ask permission first.

Write down your storage names before you wipe anything. It sounds obvious until you're rebuilding from memory at 11 PM and can't remember if it was local-zfs or zfs-data.

Test a restore on something low-stakes before you actually need one for real. Restoring a throwaway test VM from a backup archive takes a few minutes and tells you whether your backup process actually works — way better to find out now than during an actual outage.

Frequently Asked Questions

Will reinstalling Proxmox delete my VMs automatically?

No. The installer only touches disks you explicitly select. VMs on storage you didn't select survive untouched, though Proxmox won't know they exist until you reconnect that storage and restore the config files.

Do I need Proxmox Backup Server to do this safely?

No. Plain vzdump backups to an NFS share, a USB drive, or even local disk on another machine work fine for a reinstall. PBS adds deduplication and faster incremental backups, but it's not required here.

Can I reinstall a node that's part of a cluster this way?

You can, but it's a different process — you'd typically remove the node from the cluster first, reinstall, and rejoin, rather than trying to preserve its cluster membership through a wipe. That's worth its own dedicated guide.

What if I installed with ZFS on the boot drive itself, not a separate pool?

Then your VM disks were likely on that same boot pool, which means Path A doesn't apply — the installer would wipe that pool along with the OS. You need a vzdump backup (Path B) in this case.

How long does the whole process actually take?

The install itself is about ten minutes. Config restore is nearly instant. The variable is your backup and restore transfer time, which depends entirely on how much VM disk data you're moving and how fast your network or USB drive is.

Conclusion

A Proxmox reinstall looks intimidating mostly because it's rare enough that most people do it once and forget the details by the time they need it again. The actual mechanics are straightforward: know what's on the boot disk versus your data disk, keep a copy of your configs, and either reimport a pool or restore a vzdump archive depending on which situation you're in.

Do the five-minute check with pvesm status before you touch anything. It's the difference between a clean, boring reinstall and a bad night spent digging through backups you hoped you'd never need.