Rebuild A Dead Proxmox Host: What PBS Does Not Restore
Tech GuruQuick Answer
A guest backup is not a complete Proxmox host rebuild plan. Preserve the host's network, storage, firewall, identity, repository, passthrough, and key records separately, then rehearse recovery on an isolated blank target. Restore a representative guest only after its host dependencies are ready. Proxmox Backup Server can also hold separately configured file backups; the question is what your actual backup jobs include and what you have proved recoverable.
Evidence status: PBS documentation confirms guest and file-backup capabilities. No blank-host rebuild, cluster-database recovery, key-recovery test, or guest restore result is supplied here. This is a recovery inventory and rehearsal plan, not a tested bare-metal restore recipe.
What To Check
PBS documentation describes VM, container, physical-host, and file backups. A VM backup includes guest configuration and disk archives; that does not establish that a particular job contains every host dependency. Check the job scope rather than interpreting the title as a claim that PBS cannot back up host files.
The missing pieces are often the ones needed before a restore can begin: management networking, storage presentation, backup credentials, encryption keys, and the service startup order. Keep those records available without the failed host. A backup catalog you cannot reach or decrypt does not meet the recovery objective.
Key Concepts In Plain Language
- Host recovery records: The configuration, credentials, storage/network mappings, and keys needed to run restored guests.
- Guest recovery: Restoring a VM or container and checking its real service, not merely recreating its inventory entry.
- Recovery proof: A successful clean-target restore with the inputs, order, and missing dependencies recorded.
Technical Checklist
- Preserve
/etc/pve, cluster identity, network interfaces, DNS, repositories, storage definitions, firewall rules, users, certificates, and backup-job records. - Record passthrough IDs, IOMMU settings, USB mappings, encryption keys, mount dependencies, and any packages or kernel modules not recreated by a base install.
- Build on blank media, establish management and storage reachability, then restore the smallest infrastructure services before dependent guests.
- Prove a representative guest restore and document which host details had to be supplied outside PBS.
Interactive Operating Model
Use the detailed runbook and acceptance checks below with this overview. No test result is implied by the diagram.
Before You Start: Safe Defaults
Use a blank or isolated recovery target and protect the working system from overwrite. Keep the installation source, host records, PBS access details, encryption material, and management path outside the failed host. Separate standalone-host recovery from recovery of a member of an existing cluster.
- Keep backup credentials, encryption keys, repository details, and network notes outside the failed-host trust boundary.
- Record storage presentation, bridge and VLAN design, firewall policy, passthrough, users, certificates, and service startup order.
- Use a blank or isolated recovery target so the rehearsal cannot overwrite the working environment.
- Do not declare recovery complete when a backup catalog opens; restore and exercise a representative workload.
Go, Hold, Recover, Or Escalate
Hold a rebuild if the backup cannot be accessed or decrypted, the target disks are ambiguous, or cluster identity/rejoin steps are unresolved. Escalate cluster-state recovery rather than experimenting with a copied database on a live cluster.
Planned Checks And Recovery
The pmxcfs recovery guide identifies /var/lib/pve-cluster/config.db as the saved configuration database. Its replacement-host procedure requires nothing running on the new host, stopping pve-cluster, restoring the database with permissions 0600, adapting /etc/hostname and /etc/hosts, then rebooting and checking. VM/container data must still be recovered. Treat this as a scenario-specific recovery procedure, not a command to overwrite a healthy cluster member.
The same guide distinguishes moving a failed node's guest configuration from restoring a whole host. Manual guest ownership recovery requires the source node to be powered off or fenced and the guest's disks and other resources to be available on the destination. Local-only resources are not recovered by moving a configuration file. No such recovery was performed for this article.
Step 1: Audit what was actually backed up
List the guest backups and any separately configured host-file backups. Compare them with the host checklist below, including /etc/pve and cluster identity records. Mark each dependency as recoverable, documented for recreation, or missing. Do not count a file as protected solely because PBS is installed.
Step 2: Prepare the recovery inputs
Preserve network interfaces, DNS, repositories, storage definitions, firewall policy, users, certificates, backup jobs, passthrough IDs, IOMMU settings, USB mappings, encryption keys, mounts, and extra packages or kernel modules. Keep the records encrypted and accessible from the recovery workstation. Retain the saved cluster database for the appropriate supported recovery path; this article does not authorize blindly copying it onto a new node.
Step 3: Build the host foundation
Install onto the identified blank media in isolation. Recreate management and storage reachability from the reviewed records, then verify backup access and required keys. Use the official recovery procedure for the actual standalone or cluster scenario. Stop if the replacement's identity, storage presentation, or network differs unexpectedly.
Step 4: Restore dependencies before dependent guests
Choose a small representative infrastructure service, restore it, and exercise its normal client workflow. Continue in the documented service order. For each guest, record which bridge, storage mapping, credential, certificate, or passthrough detail had to be supplied outside the guest backup.
Step 5: Test service and recovery handoff
Check an allowed workflow, an access that should remain denied, monitoring, and restart behavior. Record the complete rebuild order and remaining gaps. Preserve the original backup and failed-host evidence; a rehearsal succeeds when another operator can explain the restore inputs and results, not merely when the UI lists guests.
Validation Checklist
- Backup scope explicitly distinguishes guest archives from separately protected host files and recreation records.
- The clean target can reach storage and PBS, use the required keys, and restore a representative workload.
- Client service, access restrictions, alert delivery, and service startup order have recorded results.
- Cluster identity and recovery steps are resolved before any live-cluster reconnection; host-only omissions are added to the recovery record.
Troubleshooting
- PBS is reachable but a restore cannot proceed: Check the selected backup, permissions, encryption material, and target storage against the recovery record.
- The guest starts but its service fails: Compare bridges/VLANs, DNS, firewall policy, mounts, credentials, and startup dependencies.
- The replacement conflicts with cluster state: Keep it isolated and use the supported scenario-specific recovery process; do not overwrite live cluster data to force a match.
Security, Privacy, Legal, And Recovery Boundaries
Security
Treat recovered credentials and certificates as sensitive, rotate anything that may have been exposed, and restore least privilege deliberately.
Privacy
Recovery copies can duplicate the most sensitive data in the environment; encrypt them and document who can access each location.
Legal
Preserve required records and licensed software while respecting data-location, retention, and incident-evidence requirements.
Recovery
The article distinguishes the backup of guests from the records needed to recreate the host; neither one substitutes for the other.
Record any local exception, its owner, its expiration condition, and the evidence required to remove it.
What The Evidence Does Not Prove
No bare-metal or cluster recovery was performed. Guest restore success would not prove that every passthrough device, custom module, encrypted dataset, or cluster dependency can be recreated. The documented pmxcfs procedure has target-state and data-availability preconditions; it is not a general instruction to overwrite a live cluster database.
Related TechGeeks Resources
- RAID, ZFS Snapshots, Sync, and Backup
- Homelab Backup Strategy: NAS, Offsite Copies, and Restore Tests
- How Do You Document a Homelab So Someone Else Can Recover It?
References
Next Action
Compare the recovery checklist with one actual guest restore. Every host detail supplied by hand is an input that needs its own protected copy or recreation instruction.
