Separate Proxmox live restore from start-after-restore

Bottom line: Decide when the recovered VM may start before approving the restore command. Keep early start, completed restoration and application acceptance as separate milestones, with the intended VM identity and storage written down.

Source fact: what the authority says

The Proxmox qmrestore manual documents --live-restore as starting the VM immediately while restoration continues in the background, for PBS only. Its separate --start option starts the VM after it has been restored successfully and defaults to disabled. Without a specified storage target, restored volumes are allocated on their original storage. The manual exposes --force to allow overwriting an existing VM and --unique to assign a random unique Ethernet address.

What the source does not establish

This command reference establishes option meanings, not an application recovery-time guarantee or a qualification of guest behavior during background restore. This article does not approve overwriting an existing VM or reconnecting a recovered copy to production networks.

Applicability questions

• Is the backup source PBS and is early VM startup actually required?
• Which unused or expressly approved VM ID will receive the restore?
• Which target storage and network identity are intended?
• What evidence separately establishes restore completion and usable application recovery?

DSE recommendation: controlled next steps

The following steps are DSE recommendations based on the cited source.

DSE recommends a restore request with distinct fields for archive, VM ID, storage and startup mode. Require the recovery owner to choose ordinary completion followed by startup or the documented PBS live-restore branch. Avoid treating the two startup options as interchangeable conveniences.

Review existing VM identity before adding any overwrite option. For a proposed isolated recovery copy, decide the intended Ethernet address and network attachment with the network owner. Do not add --force merely because the first command encounters a conflict that has not been investigated.

Select target storage explicitly when the recovery design requires a different destination. Review the available destination and approved workload envelope before the run. Keep any bandwidth cap as a separately justified choice and confirm its units against the current manual rather than inventing a rate.

Define a proposed harmless application check and a separate restore-completion check. Assign an owner to each milestone, including the decision about when users may connect. Preserve the original backup and keep the recovered instance isolated until identity and service checks are accepted.

Verification and evidence

Proposed verification: restore an approved test backup into the agreed isolated target and record the effective options, selected storage and startup observations. If live restore is the selected branch, capture VM startup and the independently observed end of background restoration as two events.

Exercise the named application check only within the authorized test network and preserve actual results. Inspect the resulting VM identity before allowing wider connectivity. Retain the archive reference, command result and acceptance decisions together; a running VM alone must not close a still-unresolved restore-completion question.

Official references

• Proxmox — qmrestore(1) — official product documentation; confirm the installed release and configuration.

Source review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.