Backup & Restore
Full-host backup and restore for Proxmox VE. Captures filesystem, configuration and installed components in a single archive, and reproduces the host on the same or a different Proxmox install with no external dependencies.
What it is, in one paragraph
/etc, /root, /var/lib/pve-cluster, plus optional custom paths), a structured manifest (JSON with the detected hardware, kernel parameters, network layout, ZFS state, users and cron entries), and an application inventory (all packages marked as manually installed by APT, plus the list of components installed by ProxMenux with their exact versions). Any of the three supported destinations — local archive, Proxmox Backup Server (recommended) or Borg — receives the same self-contained payload, and any of them can hydrate the target host without depending on the source being reachable at restore time.Video walkthrough
Prefer watching Backup & Restore in action before configuring it? This walkthrough covers a full end-to-end demo of the feature in ProxMenux.
External video on YouTube. Plays in privacy-enhanced mode (no cookies until you press play).
What it is not
The section covers host-level backup and restore: the Proxmox installation itself, not the workloads running on top of it.
- •It is not a VM/CT backup tool. Guest disks and RAM state are not captured by this feature; that is what
vzdumpis for. The guest configuration files (/etc/pve/nodes/<node>/qemu-server/*.confandlxc/*.conf) are captured, so after a restore the guest inventory reappears and disks can be re-attached from an existing PBS/local backup. - •It is not a cluster-wide operation. Each node backs up itself. Cluster membership is captured as part of
/etc/pveso a restored node can be re-added to its cluster, but restoring a full cluster requires per-node coordination. - •It is not a full disk image. Kernel binaries, the initramfs and the boot partition are not captured. On a restore, ProxMenux relies on the target host's own boot artifacts (regenerated automatically by
update-initramfsand the bootloader tool) and installs matching drivers against the target's running kernel.
The three pillars of a backup
A ProxMenux archive is structured around three self-contained payloads. The restore uses all three together to reproduce the source host on a target that may not even have the same kernel installed.
Every backup ships the same three payloads regardless of destination. The restore consumes all three: rootfs to lay down files, manifest to detect drift and cross-kernel differences, and application inventory to re-install packages and components against the target's own kernel.
The restore reproduces the source host, not the archive
Restoring a ProxMenux backup does not just extract the filesystem. The restore flow reads the manifest to detect drift between the source and the target (hardware differences, NIC renames, kernel version, ZFS pool identity), replays the filesystem, then triggers the correct component installer for every service that was installed on the source (NVIDIA driver, Coral TPU, AMD GPU tools, Intel GPU tools). Each installer runs against the target's current kernel, so the restored host does not depend on the source's kernel being present. When the target's kernel is newer than the backup's, a kernel-agnostic hydration pass merges the operator's own tuning (IOMMU tokens, VFIO device IDs, custom quirks, GRUB keys) into the target's fresh boot configuration without copying kernel-tied files verbatim.
Two interfaces, one backend
Every step of the backup and restore workflow is available from two entry points. Both call the same shell library, produce identical archives, and read the same job registry.
Where to go from here
Each subsection below covers one aspect of the workflow in depth. Start with How it works if the goal is to understand what the archive contains and why. Jump to Destinations to configure the target for the copy. Read Restoring and Cross-kernel restore for the recovery side.
- How it works — the three payloads (rootfs, manifest, applications) in detail, with the collectors that produce them and the format of each file.
- Destinations — comparison of local, Proxmox Backup Server (recommended) and Borg, and how to configure each one.
- Creating backups — one-off backups, the default path profile, adding custom paths, encryption for PBS.
- Scheduled jobs — new jobs vs. attaching to an existing PVE vzdump job, scheduling formats, the job detail modal.
- Restoring — the three actions on an archive (view, download, restore), Complete vs. Custom restore, the post-boot dispatcher and why the last ten minutes matter.
- Cross-kernel restore — direction-aware behaviour when the target kernel differs from the backup's, the safe-subset filter and the four hydration phases.