How to Restore a VM or LXC Container from a Backup in Proxmox VE (Step-by-Step Guide)

You made a backup. Good. Now something's broken — a botched update, a fat-fingered rm -rf, a VM that just won't boot anymore — and you need that backup back. This is the part nobody practices until they're already panicking, which is exactly why it's worth walking through calmly, before you actually need it.

This guide covers restoring a full virtual machine or LXC container from a vzdump backup in Proxmox VE, using both the web GUI and the command line. If you're looking for how to pull a single file out of a backup without restoring the whole guest, that's a different feature called File Restore, and it only works with Proxmox Backup Server. We're covering the full restore here — bringing an entire VM or container back to life from an archive.

What You Will Learn

• What actually happens when Proxmox restores a backup, and why the VMID matters so much
• How to restore a VM or container from the Datacenter GUI in a few clicks
• How to restore from the command line with qmrestore and pct restore
• What live-restore is, and when it's worth using
• The errors you're most likely to hit, and what they actually mean
• A few habits that will save you from a bad day later

What Is Restoring a Backup?

Every Proxmox VE backup made with vzdump — whether it's a scheduled job or something you triggered manually — is a full snapshot of a VM or container's disks plus its configuration file. Restoring takes that archive and rebuilds a running guest from it: new disk images written to a storage of your choice, and a config file recreated on the node, either as a brand-new VMID or overwriting an existing one.

It's not incremental and it's not selective by default. You're not merging changes back in — you're recreating the machine as it existed at the moment that backup was taken. Everything since then is gone. That's obvious once you think about it, but it's easy to forget when you're restoring in a hurry.

Where the backup lives changes a few things about how restore behaves. A backup on local directory storage or an NFS/SMB share gets copied in as a plain file-based restore — it reads the archive sequentially and writes out the disk images. A backup on Proxmox Backup Server (PBS) is stored as deduplicated chunks rather than one big file, which is what makes a feature like live-restore possible — more on that below.

Why Would You Use It?

The obvious case is disaster recovery: a VM's filesystem gets corrupted, a container's root password is lost and nobody can get back in, a bad in-place upgrade leaves a guest unbootable. Restore is your rollback button.

But it's also a normal part of testing. Say you want to try a risky config change, a kernel upgrade, or a database migration script — you can restore last night's backup to a new VMID, test against the copy, and just delete it afterward if it doesn't work out. No snapshots to manage, no risk to the production guest. This is genuinely one of the more underused tricks in Proxmox VE. Most homelab users only think of restore as the emergency option and never realize it doubles as a disposable sandbox.

Prerequisites

• A working Proxmox VE 8.x or 9.x host with at least one existing vzdump backup — local, NFS/SMB, or on Proxmox Backup Server
• Root or a user account with the VM.Backup and Datastore.AllocateSpace permissions, at minimum
• Enough free space on the target storage for the restored disks — check this before you start, not after the job fails at 90%
• SSH or console access to the node, if you plan to use the command line instead of the GUI
• The VMID or CTID you're restoring to, and whether it's free or already in use

Step-by-Step Tutorial

Restoring a VM from the GUI

This is the easiest path for most people, and it's where I'd point a first-timer.

1. In the Proxmox VE web interface, click the storage that holds your backups in the left-hand tree (for example, local or your PBS datastore).
2. Open the Backups tab. You'll see a list of every backup on that storage, with the VMID, date, and size.
3. Select the backup you want and click Restore.
4. In the dialog, set the VM ID. Leave it as-is to overwrite the original guest, or change it to restore as a new, separate VM.
5. Pick the target Storage for the restored disks. This doesn't have to match where the original VM lived.
6. If the backup is on PBS and you're restoring a VM (not a container), you'll see a Live Restore checkbox. Leave it unchecked unless you specifically need the VM back online in seconds — we'll cover the tradeoff shortly.
7. Click Restore and watch the task log at the bottom of the screen. For a VM with a 32 GB disk on decent local storage, this usually takes somewhere between two and ten minutes, depending on disk speed and how compressible the data is.

When it finishes, the VM shows up in the resource tree under the VMID you chose. It won't start automatically unless you ticked the option to start it after restore — check the config, then power it on.

Restoring an LXC Container from the GUI

Same idea, slightly different dialog. Go to the storage's Backups tab, pick the container backup, and click Restore. You'll set the CT ID and target storage just like with a VM. There's no live-restore option for containers — LXC restores are fast enough on most hardware that it isn't needed, since a container's filesystem is usually a fraction of the size of a full VM disk image.

Restoring a VM from the Command Line with qmrestore

If you're comfortable in a shell, or you're scripting a recovery process, qmrestore does the same job as the GUI restore dialog.

qmrestore /mnt/pve/backup-nfs/dump/vzdump-qemu-888.vma.zst 601 --storage local-zfs

That restores the archive as a new VM with ID 601, writing disks to the local-zfs storage. If a VM with ID 601 already exists, this command refuses to run — you'll need to add --force to explicitly overwrite it:

qmrestore /mnt/pve/backup-nfs/dump/vzdump-qemu-888.vma.zst 601 --storage local-zfs --force

Double-check the VMID before you add --force. It's the one flag in this whole process that can quietly destroy a running VM's disks if you point it at the wrong number.

Restoring a Container with pct restore

pct restore 600 /mnt/pve/backup-nfs/dump/vzdump-lxc-777.tar.zst --storage local-zfs

This restores container backup 777 as a new container with ID 600. Like qmrestore, it won't silently overwrite an existing container — if CTID 600 is already taken, remove or rename the existing container first, or pick a free ID.

Live-Restore for PBS-Backed VMs

This one's worth explaining properly, because the name is a little misleading. Live-restore only applies to VM backups stored on Proxmox Backup Server — not containers, and not backups sitting on plain directory or NFS storage.

Normally, a restore has to finish copying every byte of every disk before the VM can boot. Live-restore flips that: the VM starts almost immediately, and Proxmox pulls disk data from PBS in the background as the guest OS actually requests it, prioritizing whatever the running system needs right now.

The upside is obvious — a multi-hundred-gigabyte VM that would normally take twenty minutes to restore can be back online in under a minute. The tradeoff is that disk performance is noticeably worse until the background copy finishes, since every uncached read has to go fetch a chunk from PBS over the network first. And if the live-restore process itself fails partway — a network blip to the PBS server, for instance — the VM can be left in a genuinely broken, half-restored state. I'd only reach for this when downtime matters more than a slightly rough first few minutes: a production service that needs to come back now, not a homelab VM you can afford to wait on.

From the CLI, add --live-restore to qmrestore when the source archive is on a PBS storage.

Commands Explained

Common Errors

A handful of failures come up over and over. Here's what they actually mean.

• "unable to restore VM 601 - VM already exists on node" — the VMID you picked is in use. Either choose a different ID or add --force (qmrestore) if you genuinely intend to overwrite it.
• "no such logical volume" or "storage 'X' does not exist" — the backup's original storage reference no longer exists on this node, often after restoring on a different host than the one that made the backup. Pass --storage explicitly to redirect the disks somewhere that does exist.
• "unable to allocate space" or restore fails partway through with a full disk — the target storage doesn't have enough free space for the restored disk images. This is the one to check before you start, since a failed restore due to running out of space can leave partial disk images behind that need manual cleanup.
• "content type 'backup' is not available on storage 'X'" — you're pointing the restore at a storage that isn't marked to hold backup archives in its content type settings. This affects where the source archive is read from, separate from where the restored disks get written.

Troubleshooting

If a restore hangs at a low percentage for a long time, check journalctl -f on the node while it runs — for PBS-backed restores this usually points to a network issue between the Proxmox VE host and the backup server, not a problem with the archive itself.

If the restored VM boots but the network doesn't come up, check whether you restored it onto the same network as the original while it's also still running. Two guests with the same static IP or the same MAC address will fight over both, and neither will work reliably. This is exactly what --unique is for on the VM side — it's less of an issue for containers, since pct restore generates a fresh MAC by default.

If a container restore fails with permission or ownership errors on its files after booting, check whether the original was a privileged container being restored as unprivileged, or vice versa. Proxmox VE will generally preserve the original setting unless you override it, but if you did override it, UID/GID mapping shifts and file ownership inside the container will look wrong until you fix it.

Best Practices

Test a restore before you actually need one. Pick a low-stakes VM, restore its most recent backup to a throwaway VMID, and confirm it boots. A backup you've never restored is really just an assumption.

Restore to a new VMID when you're not sure, not over the original. Overwriting is faster, but it's a one-way door — a new VMID costs you a little disk space and lets you compare the restored guest against the live one before you commit to anything.

Keep at least a couple of restore points, not just the latest one. If last night's backup happens to be the one made five minutes after something silently broke, you'll want yesterday's as a fallback.

If you're on Proxmox Backup Server, run a verify job against your datastore on a schedule. It confirms the chunks a restore would actually need are intact, rather than finding out during a real emergency that a chunk went missing.

Frequently Asked Questions

Can I restore a VM backup to a different Proxmox VE node than the one that made it?

Yes. Copy or make the backup accessible from the new node — shared storage or a PBS datastore both work well for this — then restore normally. You may need to pass --storage explicitly if the original storage name doesn't exist on the new node.

Does restoring overwrite my current backups?

No. Restore only reads from the backup archive; it doesn't touch other backups on the same storage. It does overwrite the VM's disks and config if you restore to an existing VMID, though.

What happens to snapshots if I restore a backup?

If you restore over an existing VMID, any snapshots on that VM are gone — the disks and config are fully replaced. If you restore to a new VMID instead, the original VM and its snapshots are untouched.

Can I restore just one disk from a multi-disk VM?

Not with a standard vzdump restore — it restores the whole VM, all disks included. To pull a single file or directory instead of a whole disk, you'd use PBS's File Restore feature, which is a separate tool from the full restore covered here.

How long does a restore actually take?

Depends entirely on disk size and storage speed. A small container might restore in under a minute. A 200 GB VM on spinning disks over NFS could take twenty minutes or more; the same VM on local NVMe storage might take two or three.

Conclusion

Restoring isn't complicated once you've done it — the GUI walks you through it in a handful of clicks, and the CLI tools aren't much more than an archive path and a target ID. The part that actually matters is doing it once before you're under pressure, so that when a VM does go sideways at an inconvenient hour, you already know exactly what the process looks like and roughly how long it'll take. That's the difference between a stressful ten minutes and a genuinely bad night.