Outcome
You will restore one disposable VM backup to a different VM ID, verify the guest's data and service, and record a real recovery time. This test is deliberately isolated so it does not overwrite a running guest or create duplicate identities on your LAN.
Before you start
Choose a recent backup of a small disposable VM from guide 15. Confirm its source VM ID, date, guest-disk size, storage destination, and any needed encryption key. Select a different unused VM ID and a guest-disk store with enough free capacity. Restoring onto an existing VM or selecting the wrong target can replace data. Back up anything on the target first and verify the separate target ID before clicking Restore. Plan to keep the restored VM's network disconnected until you have changed any duplicate hostname, static IP, or service identity.
Steps
- Identify the backup. In the storage or PBS backup view, select the intended archive by VM ID and timestamp. Read the displayed metadata. Confirm it is a VM archive rather than a container archive and that it completed successfully. If multiple backups have similar names, stop and verify before proceeding.
- Choose a separate restore target. Open Restore and enter the unused test VM ID. Choose a storage target with enough space. Recheck both the source archive and destination ID. Do not overwrite the source VM or any existing guest. Record the start time.
- Isolate the restored guest. Before starting it, inspect its network device and disconnect it or attach it to an intentionally isolated test network. A restored clone can share the original's hostname, static IP, SSH host keys, and application identifiers; starting both on one LAN may cause conflicts.
- Boot and inspect locally. Start the restored VM and use its Proxmox console. Confirm the expected operating system starts, log in with known test credentials, and check an intentional test file or service state that existed when the backup was taken. If the workload uses a database, include an application-level integrity or query check; a boot screen alone is insufficient.
- Measure recovery. Record finish time, total restore duration, archive age, bytes restored if shown, and whether the observed recovery point and time meet your targets. Note anything required beyond the archive: keys, passwords, DNS, software licenses, or external data.
- Clean up carefully. Shut down the test restore. If you want to keep it, give it a distinct identity and network plan. Otherwise, delete only the separately restored test VM after verifying its ID and preserving the original guest and backup.
Check it worked
The restored VM boots from the chosen archive, contains the expected test data, and passes a workload-specific check. The source VM and its data are unchanged. You have a dated record of actual recovery time and any gaps.
If it fails or rollback
Leave the original VM and archive untouched. Inspect restore task logs for missing backup parts, credentials, target-space problems, or storage connectivity. If the restored guest will not boot, inspect its virtual hardware and console messages. Do not retry by restoring over the original. Resolve the fault, create a new test ID if needed, and repeat the drill.
Safety and data notes
A restored copy contains the same secrets and personal data as the source. Keep it isolated and remove it when no longer needed. If the test exposed a recovery gap, treat the backup as unproven for that workload until a successful repeat. Backups can also restore old vulnerabilities, so update the guest before exposing it.
Sources
Official Proxmox documentation checked 2026-09-29: VE backup and restore, VM configuration and network devices, PBS restore documentation.
Next guide
Continue to the monitoring and maintenance track, and repeat this drill after significant backup, storage, or workload changes.