Prepare host recovery: Proxmox disaster recovery covers recovery planning. A restore test checks the explicitly agreed scope. Initial meeting.
Restoring a PVE host with PBS requires two separate layers: the Proxmox installation and its configuration, and the guests running on it. A successful VM backup job does not automatically protect both. The article includes an example for host backup and the order after a failure. As of October 2026.
Contents
- Back up before failure
- Example: back up host files with the backup client
- Order after a host failure
- Assess failure and prepare the target
- Recover host configuration carefully
- Restore guests from PBS
- Handle cluster replacement separately
- Document acceptance
- Sources
Back up before failure
The PVE backup function saves VM and container configurations and included guest data. Disk exclusions and container mount types affect coverage. Bind and device mount contents are not included. Record these data paths separately.
Proxmox Backup Client can back up files directly from a physical host. An archive of / does not automatically include other mount points. Check filesystem boundaries and the actual archives in the backup catalogue. A root.pxar alone proves neither complete host coverage nor bootable recovery.
| Required inventory | Document separately and retain securely |
|---|---|
| Host and boot | PVE/package versions, installation, partitions, boot mode and disk mapping |
| Network | NIC mapping, bridges, VLANs, IPs, routing and console access |
| PVE configuration | pmxcfs configuration, storage IDs, permissions, jobs and firewall |
| Local additions | /etc/network/interfaces, /etc/hosts, repository configuration, services and scripts |
| Recovery access | PBS repository, namespace, permissions, TLS trust and encryption keys |
The pmxcfs documentation describes /etc/pve as a database-backed filesystem. Its database resides at /var/lib/pve-cluster/config.db. A collection of individual /etc/pve files and a consistent database backup are different backup methods; the selected method must be checked. Configuration backups may contain secrets and need appropriately protected storage.
Example: back up host files with the backup client
A regular file backup of the host complements the guest backups. The following example backs up configuration directories and the root file system with the Proxmox Backup Client. Access uses a dedicated token with the DatastoreBackup role (values are placeholders):
export PBS_REPOSITORY='backup@[email protected]:store1'
export PBS_PASSWORD='<token secret>'
export PBS_FINGERPRINT='<fingerprint of the PBS certificate>'
# configuration and root file system as separate archives, include the EFI partition
proxmox-backup-client backup etc.pxar:/etc root.pxar:/ --include-dev /boot/efi
# check the existing snapshots
proxmox-backup-client snapshot list
File systems of other mount points are only included with --include-dev. After the first run, check in the catalogue which archives actually exist. After a failure, restore individual archives into a directory and compare them instead of copying over the running system:
proxmox-backup-client restore host/pve1/2026-10-21T02:00:00Z etc.pxar /root/restore-etc
The backup token belongs in a secret store, not in plain text in a script. The host's backup access should only write and read its own snapshots; deletion rights do not belong to it.
Order after a host failure
- Secure the old host against unintended restart and record the guest disk assignment.
- Provide a replacement or reinstall with a matching PVE version, console and management network.
- Configure and check the network using the documented NIC assignment.
- Attach PBS as storage (verify the fingerprint) and provide the key for encrypted backups.
- Retrieve host configuration from the archive into a comparison directory and adopt only the matching parts.
- Restore infrastructure guests (DNS, directory, firewall) before the applications that depend on them, each initially without starting.
- Start guest by guest, check network, IP conflicts and external dependencies and accept the application.
- Check the new backup job and close the log.
Assess failure and prepare the target
First establish whether only the boot medium failed, guest disks survived or the entire machine was lost. Preserve the mapping of surviving disks and do not approve installation onto them. Prevent the old host from restarting unintentionally before guests start elsewhere.
Install PVE on clearly identified replacement media with a software version suitable for the restore. Establish console access, management networking and target storage. NIC names and disk paths can differ on replacement hardware; do not copy network files without review. The PVE network documentation explains bridges and interface configuration.
Recover host configuration carefully
For a rebuilt standalone host, recreate the required configuration from the saved documentation and then restore guests from PBS. Extract file backups into a separate directory first, compare them and apply only suitable settings. The client restore function restores individual archives; it does not perform complete boot repair.
For targeted pmxcfs recovery, Proxmox documents transferring config.db to a new host with nothing running: stop pve-cluster, replace the database with permissions 0600, adapt the hostname and /etc/hosts to the lost host, reboot and verify. Guest data is still needed separately (manufacturer procedure). This is not a general command sequence for overwriting an existing cluster. Network and storage mappings must fit the target; the old identity must not remain active simultaneously.
Restore guests from PBS
Connect the reachable PBS using the correct datastore, namespace, permissions and verified TLS trust. For encrypted backups, supply the independently retained key. The PBS PVE integration documents connection and restore.
Explicitly select the backup point and target storage. Restore without starting the guest initially, then check bridge, VLAN, IP conflicts, passthrough and external data dependencies. For a test, use an unused ID and an isolated network. Before any container start, review all mpX entries; remove production bind/device mounts or redirect them to independent test copies. A new ID alone does not isolate these data accesses.
The PBS restore test guide covers guest validation in detail. Recover infrastructure dependencies before dependent applications. Record the order in the DR runbook.
Handle cluster replacement separately
If the remaining cluster survives, its authoritative configuration comes from that surviving cluster. Safely isolate the old node and its guests, check quorum and storage, then plan replacement using the documented node removal and cluster join. Do not import an old cluster database speculatively.
Joining overwrites /etc/pve on the joining node; that node must not contain guests. Where data survives on shared storage, manual guest recovery must meet the fencing and resource conditions in pmxcfs recovery. Moving a guest configuration does not restore missing local disks.
Document acceptance
Check host reboot, management access, storage, network, time service and cluster state where applicable. Then confirm guest data point, login and business workflow. Check a new backup job and record unresolved dependencies. The evidence must distinguish a guest-only check from a test that also covered rebuilding the host.
For recovery planning: disaster recovery. For a defined practical check with a report: restore test. A host failure scenario is explicitly included in the agreed test scope.
