A restore Proxmox backup web UI is only worth having if you actually press the button, because a backup you have never restored is not a backup — it is a directory of hopeful .zst files. Stashboard V8.1 added LXC restore and V8.3 added VM restore, so the restore Proxmox backup web UI now covers both guest types straight from the host header menu. 🗃️
This post is built around a drill, not a disaster. Restore to a new vmid once a month, boot it, look at it, delete it — ten minutes with a restore Proxmox backup web UI, and it is the only thing that turns “I have backups” into “I have restores.” Then, and only then, the destructive path: restoring over a guest that already exists, and why it is fenced off behind two confirmations.
If you are new to this series, start with managing Proxmox from a web dashboard, then creating an LXC from the web UI and the clone and snapshot panel, which is the closest cousin to this feature.
A Backup You Have Never Restored Is Not a Backup
Everyone in this hobby has a backup job. Far fewer people have ever watched one come back.
The failure modes are boring and specific. The vzdump job has been writing to a storage that filled up three weeks ago. The archive exists but the storage it wants to land on no longer does. The container restores fine, but the bind mount holding the actual data was never in the archive. None of that shows up in a green checkmark on a backup schedule. It shows up the first time you try to restore — exactly the moment you cannot afford to find out.
A restore Proxmox backup web UI does not fix any of those problems. It fixes the friction that stops you discovering them. When a vzdump restore means SSH, pct restore, the right volid and the right argument order, you do it during an outage and never as practice. When it is a dropdown and a button, you do it on a Sunday morning with coffee.
That is the whole argument for a restore Proxmox backup web UI. Not convenience — rehearsal. Pair it with a real off-box target like a dedicated Proxmox Backup Server and the broader NAS backup and restore strategy, and the restore side finally gets the attention the backup side always got.
How the Restore Proxmox Backup Web UI Finds Your vzdump Archives
The host header menu gains two entries: Restore LXC and Restore VM. Both open the same shape of dialog, and both start by asking the node what it actually has.
Discovery works in two hops. First, the restore Proxmox backup web UI lists the node’s storages and keeps only the backup-capable ones — those whose advertised content includes backup. Then, for each of those, it calls GET .../storage/{storage}/content?content=backup and collects what comes back. Nothing is hardcoded; add a new backup storage tomorrow and it shows up without a config change.
The results are then filtered by guest kind, because a container archive and a VM archive are not interchangeable. Restore LXC keeps vzdump-lxc-* volumes. Restore VM keeps vzdump-qemu-*. You cannot accidentally point a QEMU archive at the container endpoint from the dropdown, which removes a whole category of confusing host-side errors.
Each entry in the dropdown shows the three things you need to pick correctly: the guest id the archive came from, the timestamp, and the size. That is usually enough to identify “the nightly from before I broke it” without opening a file browser.
⚠️ One scope limit worth knowing up front: Proxmox Backup Server datastores are skipped. The restore Proxmox backup web UI reads vzdump archives on the node’s own backup storages. PBS-based restores stay in the Proxmox console for now.
The Monthly Drill: Test-Restore to a New VMID
Here is the routine, and it is deliberately dull.
- Open the host header menu and pick Restore LXC (or Restore VM).
- Choose a recent archive from the dropdown. Pick something that matters — the guest you would actually panic about.
- Leave the target vmid alone. It is pre-filled with the next free id, so the restore lands beside the original instead of on top of it.
- Leave start after restore off if you want to inspect the config first, or on if you want to see it boot.
- Submit, and watch the task run to completion.
- Boot it, log in, confirm the data you care about is really inside, then destroy it.
Step 6 is the one people skip, and it is the only step that proves anything. A restore that produces a bootable guest with an empty data directory is a failed restore that looks like a successful one.
The target vmid field is where the restore Proxmox backup web UI makes the safe thing the default. It starts at the next free id, with a one-click “Use original” button beside it if you deliberately want the archive’s own id back. Two toggles ride along — unprivileged and start after restore — both honoured on the request. Aim a new-vmid restore at an id that turns out to be taken and you get a clean 409, not a mangled host error.
Do this once a month per critical guest, in a restore Proxmox backup web UI that makes it a five-minute job, and you will find your broken backup on a Sunday instead of at 2am.
Inside an LXC Restore: the Create Path, Reused
The container restore is not a separate code path bolted on the side. It reuses the same create path described in the create LXC guide, with three deliberate differences.
It POSTs to /nodes/{node}/lxc with ostemplate=<backup volid> and restore=1. That is Proxmox’s own convention: the “template” slot carries the archive, and the restore flag changes what the endpoint does with it. The Proxmox backup and restore documentation covers the same mechanics from the CLI side.
The first difference is disks. Instead of emitting a rootfs spec, the restore Proxmox backup web UI emits a storage override only. The archive already carries the rootfs sizes and layout, so re-declaring them would fight the archive rather than help it. You choose where it lands, not how big it is.
The second is that template-only fields are skipped entirely: password, SSH keys, network and DNS. Those describe a container being built from scratch. A restored container brings its own, and quietly overwriting them would be a surprise you discover much later.
The third is honesty about completion. Proxmox answers with a task UPID, not a result, so the restore Proxmox backup web UI polls that UPID to a terminal state. What you see is what actually finished — not what was merely accepted.
Restoring a VM Is a Different Shape
The QEMU path looks similar in the browser and is genuinely different on the wire.
A VM restore POSTs archive=<volid> to /nodes/{node}/qemu. There is no ostemplate, no restore=1 — the presence of archive is what tells Proxmox this is a restore. That is why V8.3 was a separate release from V8.1 rather than a checkbox: same idea, different request shape, different validation.
Everything around it stays consistent: the same discovery scan, the same next-free-vmid default with “Use original”, the same start-after-restore toggle, the same UPID polling. From the operator’s seat the restore Proxmox backup web UI behaves identically for containers and VMs — the differences belong in the code, not in your head at 2am.
Overwriting an Existing Guest Is Fenced Off for a Reason
Now the dangerous one. Restoring over an existing vmid sends force=1, and that does exactly what it sounds like: the current guest is replaced by the archive. Everything written since that backup is gone. There is no undo, no snapshot taken on your behalf, no second chance.
So the restore Proxmox backup web UI refuses to make that easy. Two conditions must hold before anything reaches the host:
- The target must exist and must be stopped. An overwrite aimed at a running guest is refused before any host call, and so is one aimed at a vmid that does not exist. Both are user errors with clear messages instead of half-finished operations.
- You must confirm twice, explicitly, with the target named. Not a generic “are you sure” — the restore Proxmox backup web UI spells out which guest you are about to replace.
The contrast with the new-vmid path is intentional. A new-vmid restore onto an occupied id is a clean 409 and nothing happens. An overwrite is a different verb, gated differently, and it looks different on screen for exactly that reason.
Practical advice: before any overwrite restore, take a snapshot of the doomed guest first from the clone and snapshot panel. If the archive turns out to be older or emptier than you thought, you still have a way back.
Gating the Restore Proxmox Backup Web UI: Two Switches, Both Off
Restore is destructive capability, so it is not on by default anywhere.
Stashboard:AllowProxmoxRestore— the master switch, under Settings → Restore guest.- Per-host
AllowRestore— an explicit opt-in on each individual Proxmox host.
Both are off out of the box, and both must be on before the restore Proxmox backup web UI will talk to a node at all. If either is off, the request dies with a deterministic 403 before any call reaches the host — nothing attempted, nothing partially applied, and an instant rejection rather than a timeout. Same double-gate model as every other write-capable feature in the dashboard: a fresh install cannot restore over anything, even if someone finds the button.
My own setup keeps AllowRestore on for the one node I actually practise on and off everywhere else. Turning it on for a drill and off afterwards is a perfectly reasonable habit.
Every Restore Leaves a Row: Audit and Errors
Every attempt that reaches the host writes a ProxmoxRestoreAudit row, visible on the Audit page’s Guest restore tab. Each row records who ran it, when, which host and node, the target vmid, the archive volid, whether it overwrote an existing guest, and whether it succeeded — plus the error if it did not.
That last field matters more than it sounds. Failed restores are the interesting ones: they are the evidence that a storage is full, an archive is truncated, or a target is unsuitable. A restore Proxmox backup web UI that only logged successes would hide precisely the data you need.
When Proxmox itself rejects something, the host’s message is surfaced verbatim as a 502. You get the real reason from the node, not a sanitised “restore failed” that sends you SSH-ing anyway.
Three things are deliberately out of scope: restoring from Proxmox Backup Server datastores, --bwlimit tuning, and live-restore. Those remain Proxmox-console territory.
Run the drill. Restore to a new vmid, boot it, look inside, delete it, and put it in your calendar for next month. A restore Proxmox backup web UI is not there to save you during the outage — it is there so the outage is not the first time you find out. 🧯