StateWarden protects Proxmox VE virtual machines without installing any software inside the guest operating systems. The StateWarden Agent runs directly on the Proxmox host and protects every VM on that host through the hypervisor layer. This guide explains how agentless protection works, how backups of running and stopped VMs are produced, and the three restore paths: in-place restore, clone as a new VM, and Instant Boot.
Prerequisite: the Proxmox VE host runs agent version 1.2.0 or newer, installed and paired like any other Linux device. Keep the host agent current - version 1.6.1 resolved a backup failure that affected certain multi-disk VMs.
1. What Agentless Protection Means
Agentless protection has a simple operating model:
- Install the agent on the Proxmox VE host itself (see Installing the Agent) and pair it with your Realm (see Pairing Your First Device).
- The host registers in the Dashboard as a hypervisor. Its virtual machines appear automatically as child devices of the hypervisor - no pairing step, no guest credentials, no footprint inside the VM.
- Each VM gets its own device view showing its virtual hardware configuration (vCPUs, memory, virtual disks) and its power state. Backups, restores, and mounts are managed per VM from the same Dashboard views used for physical devices.
Because all work happens at the hypervisor layer, the guest operating system is irrelevant to protection: Windows, Linux, and appliances are handled the same way.
2. How VM Backups Work
Running VMs: Snapshots Without Pausing
For a running VM, the agent communicates with the virtual machine's QEMU process through the QEMU Machine Protocol (QMP) and creates a temporary QCOW2 overlay (a technique known as fleecing). The guest keeps writing to the overlay while the agent reads the frozen base image. The result is an accurately frozen, application-consistent snapshot taken without pausing or stunning the VM - the guest OS is not interrupted and notices nothing.
Incremental Backups: Changed Block Tracking
VM backups use QEMU dirty bitmaps for Changed Block Tracking (CBT). The hypervisor records which disk blocks changed between backup runs, and the agent reads only those blocks into the deduplication engine. The first backup of a VM is a full baseline; subsequent backups are incremental. For how CBT interacts with schedules and retention in general, see Mastering Smart CBT: Incremental Backups.
Powered-Off VMs
VMs that are powered off at the hypervisor level remain fully visible and manageable in the Dashboard. You can schedule and execute backups of a stopped VM without waking the guest OS; these backups are crash-consistent, matching the state of the virtual disks at rest.
Multi-Disk VMs
VMs with multiple virtual disks are fully supported. All disks are captured with isolated per-disk write layers, so parallel disks originating from the same backup cannot interfere with each other. The VM's hardware configuration is captured alongside the disk data, so restores reproduce the original machine 1:1.
3. Restore Options
Open the VM in the Dashboard, choose a restore point, and select one of the three restore targets.
Option A: In-Place Restore (Overwrite the Original VM)
The agent shuts the VM down gracefully (escalating to a hard stop if the guest does not shut down in time), writes the restore point's contents back over the VM's virtual disks, and powers the VM back on.
This is the fast path for reverting a broken or compromised VM to a known-good state. It is destructive: the current state of the VM is replaced by the restore point.
Option B: Clone as a New VM
The agent provisions a completely new virtual machine on the hypervisor from the restore point. The original VM is not touched. A free VM ID is allocated automatically, and you select the target datastore for the new disks.
To let a clone run side by side with the original, StateWarden automatically mutates the hardware identifiers baked into the restored machine:
- a new system UUID (
smbios1), - a new generation ID (
vmgenid), - regenerated MAC addresses on all virtual network interfaces.
This ensures the clone does not collide with the original on the network or on guest-side identity checks. If the original VM is still running and you want an additional safeguard, use the network-isolation option at restore time: the clone then starts without virtual network interfaces attached, and you can connect it to a network later from the Proxmox UI.
Option C: Instant Boot
Instant Boot starts the VM directly from the backup stream in seconds, without waiting for a full data copy. The agent exposes the restore point to the hypervisor as a Network Block Device (NBD); reads are streamed from the deduplicated backup on demand, and writes are absorbed by a local Copy-On-Write layer. The backup itself is never modified.
Instant Boot VMs are visibly tagged TEMPORARY in the Dashboard. They are intended for two situations: verifying that a backup boots, and bridging an outage while the original storage is unavailable.
When the VM should stay, use the Make Permanent action shown on the VM. It performs a live storage migration: the disk contents are copied onto physical hypervisor storage (a datastore you select, such as local-lvm) using a QEMU blockdev-mirror job, while the guest OS keeps running and serving traffic. Once the copy completes, I/O pivots to the physical disk and the temporary NBD layer is torn down - with no downtime for the guest.
For file-level recovery instead of a full machine, mount an individual VM disk from a restore point rather than booting it; see Instant Mount: File Recovery via Native iSCSI.
4. Operational Notes
Device Quota
Virtual machines do not consume Realm device quota. Only the paired hypervisor host counts as a device, regardless of how many VMs it carries. Storage written by VM backups counts toward the Realm's storage quota like any other backup. See Understanding Quotas and Fair Use.
Response Policies on Hypervisors and VMs
Ransomware response policies behave differently in a virtualization context:
- Per-VM overrides are inert. A VM has no agent of its own; it is managed by the parent host's agent, so the hypervisor's effective policy applies. One agent enforces one policy.
- Network Lockdown and Power Off never execute on hypervisor hosts. If the host's policy calls for one of these actions, the agent logs a warning instead, so a response action cannot cut off every guest VM at once.
Configuration details are covered in Ransomware Protection: Response Policies.
Protect the Hypervisor Itself
Agentless protection covers the guests, not the host's own operating system. Protect the Proxmox host like any other Linux device: assign it a backup policy covering its system disks, so the hypervisor installation itself can be rebuilt with a bare-metal restore if the host fails. The procedure is described in Bare Metal Recovery Walkthrough.
StateWarden: Resilience Engineered.