VirtConsole 3.3.5 adds recovery drills on a schedule and alerts across your fleet. Recovery drills restore a backup into an isolated guest and check that it boots, and fleet alerts bring node, storage, backup and queue events into one place, routed to the channels you already use.
Recovery drills
A recovery drill restores one completed Proxmox Backup Server backup of an instance into a disposable guest, boots it, checks it from the node through the guest agent, records the outcome and the measured restore and boot times, and then destroys the guest.
- The drill guest has no network, no IP address and no billing, and it belongs to an admin account, so it never reaches the outside and never appears in customer lists.
- Start a drill by hand for one instance, or create an opt-in policy for a hypervisor group or a backup policy. A policy drills the instances you have not drilled for the longest time first.
- Checks cover the domain state, the guest agent, the mounted root filesystem and, if you set them, a listening TCP port and an HTTP path on the guest.
- A policy reports a failed drill, a drill that ran out of time and a stuck cleanup to your admins, and it records an instance with no recent backup as a failed proof.
- Per-node and global caps keep drills from competing with real work.
Read more in the recovery drills guide.
Fleet alerts
Fleet alerts give operators one place for incidents across the platform: nodes that stop reporting, storage pressure, failing backups, queue backlogs, HA state, expiring certificates, the licence state and the health of the Master host itself.
- Each fault opens one incident, repeats do not spam you, and the incident resolves itself when the condition clears.
- Acknowledge an incident, or silence a node, a kind of fault or a maintenance window, to stop notifications while the incident stays on record.
- Notices go to the admin channels you already use and to verified email recipients, with reminders and escalation when a fault gets worse.
- An incident settles before it closes, so a reading close to its threshold stays one incident.
Read more in the fleet alerts guide.
Volume protection policies
Standalone volumes can now protect themselves. A policy takes backups, snapshots or both, daily or weekly at a wall-clock time in a time zone you choose, and keeps them by count or by age. Schedules follow summer and winter time, a run that was missed because a volume was busy is recovered, and every run is kept in a history. A policy that fails repeatedly pauses itself and tells the owner. Policies are available in the user and admin panels and through the API.
Volume operations tracked to completion
Attach, detach, resize and delete on a volume show as pending while the node carries them out, and the volume updates when the node reports the result. The API answers a busy volume, a cooldown and the in-flight limit with distinct statuses and a retry hint. The OpenTofu provider and the MCP server wait for the final outcome before they report success.
Managed databases
- Restore an S3 backup, or any point in time, into a new database. The source database is only read while the new one is built.
- PostgreSQL 17 and newer take native incremental backups. Restores combine the chain and verify each part before use, and retention and deletion respect the chain.
High availability
Failure detection runs in bounded cycles with capped recovery jobs, so a large fleet stays responsive while guests are being recovered. Fleets that mix KVM and Proxmox nodes are served fairly in turn.
Proxmox
Every new VM takes a reserved ID that is unique across your platform and checked against the live cluster, and a rebuild, destroy, in-place restore or snapshot rollback checks the VM’s ownership before it acts.
Networking
- Node readiness shows whether a node can carry VPCs, including nodes that have no private IP.
- ARP isolation is applied per VPC.
- Supported images get explicit default routes on first boot.
Also in this release
- Backup policies can run on an explicit time zone.
- Rescue mode keeps the instance’s own hostname.
Thanks for building on VirtConsole. Questions along the way, reach us any time.