Multi-Hypervisor Backup Strategy with Veeam v13 -- vSphere, Hyper-V, AHV, and Proxmox from One VBR Instance

Veeam v13 Series | Component: VBR v13 | Audience: Enterprise Architects, Backup Administrators

Most environments don't run a single hypervisor. You might have inherited a Hyper-V cluster alongside your vSphere infrastructure. The VMware migration drove some workloads to Proxmox or AHV while others stayed on vSphere. An acquisition brought a Nutanix cluster into the organization. Whatever the reason, multi hypervisor environments are the norm and Veeam VBR handles them from a single instance without requiring separate backup products per platform.

Here's how a single VBR instance manages backup across vSphere, Hyper-V, Nutanix AHV, and Proxmox VE simultaneously, what's shared versus what's platform specific, the licensing model across hypervisors, and the operational design decisions that keep a multi hypervisor VBR deployment manageable as it grows.

1. What One VBR Instance Covers

A single VBR v13 server can back up VMs across all four major hypervisors simultaneously. The management plane is unified: one console, one job list, one repository infrastructure, one set of backup copy jobs, and one SureBackup verification platform. What's different per hypervisor is the backup proxy architecture and the agent or plugin deployed on the target platform.

Worth calling out clearly: You can run content scan and malware scan verification on AHV and Proxmox backups. What you can't do is boot VMs from backup in a virtual lab and run application tests against live services. Full SureBackup with virtual lab is currently limited to vSphere and Hyper-V. For AHV and Proxmox workloads, periodic restore testing with a manual validation process is the alternative.

2. Proxy Architecture Per Platform

vSphere

VMware proxy servers can be Windows or Linux VMs (or physical servers). They connect to ESXi hosts via the VADP API to read VM data during backup. Hot add transport mode mounts VM snapshots directly to the proxy as virtual disks for the fastest local read performance. Network transport sends data over the network from ESXi to the proxy. Multiple vSphere proxies can run in parallel with automatic load balancing by VBR.

Hyper-V

Hyper-V proxy servers are Windows machines deployed either on the Hyper-V host itself (on-host proxy) or on a separate server with access to the same shared storage (off host proxy). The off host proxy approach is better for production clusters: it keeps backup I/O off the Hyper-V hosts and doesn't consume host CPU during backup processing. Off host proxies read VM data directly from the shared storage (CSV volume) via a storage fabric connection rather than through the host.

Nutanix AHV

The AHV Backup Proxy is a Linux VM that Nutanix and Veeam developed jointly. One proxy per AHV cluster. VBR deploys and manages the proxy appliance. You don't install it manually; you configure it in VBR's Backup Infrastructure and VBR handles deployment. The proxy communicates with the AHV cluster via the Nutanix REST API and handles the change block tracking that makes incremental AHV backups possible.

Proxmox VE

Proxmox VE backup uses a Linux based Veeam proxy deployed directly on the Proxmox nodes. VBR connects to the Proxmox API and deploys the proxy component. Proxmox backups are filesystem consistent. VBR uses the Proxmox API to snapshot VMs for the backup point, but there's no VSS integration and no transaction log truncation. Application item restores (AD, Exchange, SQL) are supported from Proxmox backups. The backup process itself is filesystem consistent rather than application aware.

3. Licensing in a Multi Hypervisor Environment

Veeam's licensing model is a mix of socket based and workload based depending on the platform. Getting this wrong is an expensive surprise that's avoidable.

If you're running a mixed environment with vSphere on socket licenses and adding AHV or Proxmox, you need VUL for the new platforms. The easiest path is converting the entire environment to VUL. VUL provides a per instance model that's often more cost effective than socket licenses for environments with many sockets and few VMs per socket, and it covers every platform Veeam supports from one license type.

4. Shared Infrastructure: Repositories and Copy Jobs

Repositories in VBR are platform agnostic. A backup repository that holds vSphere backups can also hold Hyper-V, AHV, and Proxmox backups. The same SOBR with a local performance tier and S3 capacity tier serves all four platforms from one configuration. This is one of VBR's most operationally useful properties in multi hypervisor environments: you don't have separate repository infrastructure per hypervisor.

Backup copy jobs also work across platforms. You can configure a copy job that sources from a backup job covering vSphere VMs, another covering Hyper-V VMs, and another covering AHV VMs, all copying to the same offsite repository. The copy target doesn't care where the source VMs ran.

5. Job Design for Multi Hypervisor Environments

The first real design decision: should you use one VBR job per hypervisor platform, or mix platforms within jobs? Keep them separate. There are practical reasons beyond preference.

• Separate jobs per platform make troubleshooting cleaner. A vSphere job failure doesn't show as a failure alongside AHV job results in the same job report. When something breaks, the fault isolation is immediate.
• Separate proxy assignment is only possible if the job is platform specific. You can't assign a vSphere proxy to an AHV backup job and vice versa. Mixed platform jobs that need proxy control require separate jobs anyway.
• SureBackup linking only applies to vSphere and Hyper-V jobs. If you mix platforms in a job and try to link it to SureBackup, only the vSphere and Hyper-V VMs in the job are included in SureBackup verification. AHV and Proxmox VMs are excluded silently, which can give a false sense of complete verification coverage.

Connect-VBRServer -Server "vbr-server.domain.local"

$cutoff = (Get-Date).AddDays(-1)

Get-VBRJob | Where-Object { $_.JobType -in 'Backup' } |
    Sort-Object TypeToString, Name |
    ForEach-Object {
        $job    = $_
        $result = $job.GetLastResult()
        $run    = $job.LatestRunLocal
        $lag    = if ($run) { [math]::Round(((Get-Date) - $run).TotalHours,1) } else { 999 }

        [PSCustomObject]@{
            Platform   = $job.TypeToString
            JobName    = $job.Name
            LastResult = $result
            LastRunHrs = $lag
            Status     = if ($result -eq 'Success' -and $lag -lt 25) { "OK" }
                         elseif ($result -eq 'Warning') { "WARNING" }
                         else { "ACTION NEEDED" }
        }
    } | Format-Table Platform, JobName, LastResult, LastRunHrs, Status -AutoSize

Disconnect-VBRServer

6. Operational Considerations

VBR Server Sizing

A multi hypervisor VBR deployment puts more concurrent jobs on the VBR server than a single platform deployment of the same total VM count. Each platform's proxy infrastructure communicates with VBR simultaneously during concurrent job windows. Size the VBR server's CPU, RAM, and database accordingly. The PostgreSQL tuning guidance from the VBR PostgreSQL article applies here: run Set-VBRPSQLDatabaseServerLimits and apply its output, especially if your environment has 500+ VMs across all platforms.

Network Topology for Proxies

Proxies need network paths to both the source (the hypervisor/storage) and the destination (the backup repository). In a multi hypervisor environment, this means your proxy placement needs to account for multiple source environments. Placing a vSphere proxy in the vSphere network works perfectly for vSphere backups. That same proxy has no access to the Nutanix storage fabric. Plan proxy placement for each platform separately and confirm network reachability before adding jobs.