














DPX 4.16 provides agentless backup for QEMU virtual machines running on Proxmox VE 8.4 or later. It reads VM data through the Proxmox API and the Proxmox DPX Plugin on the host, then writes the backup to a vStor pool. You do not install DPX software inside the guest virtual machines for this protection model.
The current release supports RAW, VMDK, and QCOW2 virtual disks. LXC containers are not included in agentless Proxmox protection. Proxmox backup and restore jobs are managed in the DPX web interface, not the desktop interface.
If some workloads need application-aware or guest-level protection, you can use agent-based DPX backup alongside the agentless method. The Proxmox backup and recovery solution overview explains when each model fits.
Check these prerequisites before opening the DPX web interface:
user@realm format, such as root@pam, and the account must be able to list and back up the intended VMs.One Proxmox VE node definition in DPX represents the whole cluster. You enter any cluster member as the connection point, and DPX discovers the other members and their virtual machines. A standalone Proxmox server can be added in the same way.
For current version and disk-format details, check the DPX compatibility page for agentless Proxmox VE backup before deploying the job in production.
Open the DPX Master Server web interface and complete the initial connection:
Do not click Add until you review the plugin section described next.
The complete field reference is available in Adding a Proxmox VE Node.
The Proxmox DPX Plugin runs on the Proxmox host and lets DPX read virtual machine data through the Proxmox backup interface. It is separate from a guest agent and does not install software inside protected VMs.
In the Proxmox DPX Plugin section of the Add Node dialog:
You can add the node without SSH credentials, but a backup cannot run until the plugin is installed. DPX uses the SSH credentials for installation and version checks; the current documentation states that they are not stored in the node definition.
After the node is added, confirm that the cluster and its virtual machines appear in DPX before creating a job.
With the node and plugin ready, create the job in the DPX web interface:
DPX lets one backup job select VMs from more than one Proxmox cluster. Selecting a parent in the source tree also includes VMs added beneath that parent on a later run. Use that option carefully so new machines enter the intended protection policy.
Select the destination at the vStor pool level. DPX creates a separate vStor volume for every protected VM and seals a snapshot after each successful run. That snapshot becomes the VM’s recovery point.
See Creating a Proxmox Backup Job and Scheduling a Proxmox Backup Job for the full field-level procedures.
DPX uses an incremental-forever workflow for Proxmox VE. The first protected run is a base backup that copies the allocated data for each disk. Later runs transfer changed blocks when valid change tracking is available. DPX makes this decision per disk, so a VM can have a mix of base and incremental disk backups during one job run.
Disk format affects what happens after a VM is powered off or restarted:
| Disk format | Incremental backup | Behavior after a power-off or restart |
|---|---|---|
| QCOW2 | Supported | Change tracking persists, so incremental backup can continue. |
| RAW | Supported | Proxmox removes change tracking; the next backup is a base backup. |
| VMDK | Supported | Proxmox removes change tracking; the next backup is a base backup. |
DPX can also fall back to a base backup when no valid prior recovery point exists, including after the previous recovery point expires. Account for the larger transfer when sizing backup windows for frequently restarted RAW or VMDK workloads.
After the first run, review the job in DPX and confirm that each intended VM produced a recovery point. If a job protects several VMs and only some fail, DPX reports partial success. The successful VMs still have valid recovery points, while the failed VMs need investigation and another run.
For a useful operational check, record:
A green backup job is only the first half of the test. The next step verifies that the recovery point can produce a usable VM.
Use a non-production VM for the first restore test. If possible, restore it to an isolated network or leave it powered off until you have checked its identity and configuration.
DPX creates a new VM instead of overwriting an existing machine. It reserves a new VM ID and appends a timestamped -restored-... suffix to the original name. This behavior gives you a chance to validate the restored copy before it replaces any production role.
Follow progress in Job Monitor. The official Proxmox Restore procedure covers multi-VM ordering, alternate destinations, job options, and partial-success behavior.
Treat the restore as an acceptance test rather than proof that the job button works. Check the result against a short runbook:
Repeat this test on a schedule. A recent, measured restore gives you better evidence than an old job-success report.
Keep these boundaries in the design and the recovery runbook:
Check the compatibility guide again before an upgrade or a production design change. Product support can move faster than an implementation runbook.
This procedure gives you a working VM backup and a tested restore. The broader plan should also define job ownership, backup windows, retention, restore-test frequency, offsite recovery, and how Proxmox fits with the other workloads your team protects.
Use the DPX for Proxmox VE datasheet for a concise product overview, or read Beyond Proxmox Backup Server: When Do You Need More? when comparing a Proxmox-only backup design with a broader data protection platform. The DPX 4.16 release overview covers the other changes in this release.
No. DPX communicates through the Proxmox API and a Proxmox DPX Plugin installed on the Proxmox host. It does not install an agent inside the guest for this backup method.
Yes. The current DPX documentation says a single Proxmox backup job can select virtual machines from more than one cluster. Each protected VM receives its own vStor volume.
Yes. The restore workflow lets you select the target node and target storage. DPX creates the restored copy with a new VM ID and a timestamped name rather than overwriting an existing VM.
No. Agentless Proxmox protection in DPX 4.16 supports QEMU virtual machines. LXC containers are not supported by this job type.
Not always. DPX normally transfers changed blocks after the base backup, but it starts a new base when valid change tracking is unavailable. A power-off or restart clears Proxmox change tracking for RAW and VMDK disks, while QCOW2 tracking persists.
此内容由惯性聚合(RSS阅读器)自动聚合整理,仅供阅读参考。 原文来自 — 版权归原作者所有。