VirtConsole 3.3.0 backs up both your KVM hypervisors and your Proxmox VE nodes to the same Proxmox Backup Server destination, from one panel, with one set of policies, schedules and retention rules. It is a release for both the management server and the hypervisor agent.
One PBS backend for KVM and Proxmox VE
A Proxmox Backup Server destination now works the same way whether the instance behind it is running on a plain KVM hypervisor or on Proxmox VE: same policies, same schedules, same retention rules, same restore flow, same panel. Other platforms that speak Proxmox Backup Server natively tend to stop at one hypervisor family. VirtFusion’s own PBS integration drives its own KVM agent only; its documentation names no Proxmox VE driver. Virtualizor’s backup destinations are FTP, SSH and local storage; OpenStack’s Cinder and Apache CloudStack’s backup framework do not support Proxmox Backup Server as a target on any hypervisor at all.
Real deduplication, not just compression
A KVM backup reads only the blocks that changed since the last one, over the guest’s own dirty bitmap, and every backup, full or incremental, lands in a PBS datastore that deduplicates chunks across every instance stored there. Where several other backup destinations save space with compression alone, this is content-addressed storage: two instances built from the same base image, or the same instance backed up twice, share the chunks they have in common. Virtualizor’s FTP, SSH and local destinations compress but do not deduplicate. Apache CloudStack’s native backup plugin stores full disk images with no deduplication either. OpenStack’s Cinder chunks and dedupes only within one volume’s own backup chain, never across volumes or tenants.
Verified at rest, not just after a restore
Every PBS snapshot carries a server-verified integrity state, shown against the backup in the panel as soon as PBS checks it, whether or not anyone ever restores it. Turn on verify-after-backup and a fresh backup is checked the moment it completes. VirtFusion’s own PBS integration checks integrity with a post-restore filesystem check only, not an independent state kept per snapshot. Virtualizor, OpenStack and Apache CloudStack document no independent at-rest verification at all.
Backups that outlive the instance
Destroying an instance now keeps its backups by default, in the panel’s database and on the destination itself. Customers browse and restore them from Compute > Backups after the instance is gone, and can opt in to deleting them instead with a “delete backups” choice on the destroy action, wherever destroy is offered: admin panel, admin API, user panel, user API and the billing-system API. A backup marked protected is never deleted this way, no matter which surface the destroy comes from. Apache CloudStack only keeps a destroyed instance’s backups if an admin manually avoids purging its database row; Virtualizor exposes a delete-on-destroy setting with no documented default or customer-facing view of what survived.
Restore any backup into a brand-new instance, billing included
Restoring a backup can build a brand-new instance instead of overwriting the one it came from, even when the original instance has already been destroyed. Billing follows the source instance’s own billing mode automatically: hourly, against a self-provisioning pack, or left alone for an externally billed account. Apache CloudStack can create a new instance from a backup too, but has nothing built in to carry billing across; VirtFusion and Virtualizor don’t document billing continuing automatically through a restore-to-new either.
Operations
The same request is never sent to a node twice: a repeat of an operation the platform already accepted answers with a stable reason instead of starting a second run, and a new admin Reconcile action, on the Backup Queue and Tasks views, checks with the hypervisor directly before releasing a job that looks stuck.
The admin backups list, in the panel and through the API, has a new filter for destroyed instances whose chosen backup cleanup hasn’t finished yet: a stat card, a filter chip and a badge. Creating an instance now turns on VNC only when a boot ISO is attached. The in-panel updater waits until no backup, restore or delete operation is running before it updates the management server, and restarts the hypervisor agent’s queue workers gracefully instead of dropping whatever they were doing.
This release needs the Slave agent 3.3.0 on every hypervisor for Proxmox Backup Server backups to work. Update it from the panel’s Update agent action.
API changes
Admin API action responses that used to return a bare string under data now nest it as data.task_id (or the relevant field name) across every affected route, so the shape is consistent whether the response carries one value or several. Admin create endpoints answer 409, 422 or 503 with a reason instead of a generic failure; customer-facing create endpoints answer 422 with a reason. Every change, with before and after examples, is listed at docs.virtconsole.com/api/changelog.
Thanks for building on VirtConsole. Questions or trouble along the way, reach us any time.