Veeam Backup & Replication v13 with Microsoft Hyper-V: A Complete Setup Guide
- What this covers
- Requirements and supported versions
- Before you connect anything
- Adding the Hyper-V host or cluster
- Configuring the off-host backup proxy
- Setting up a backup repository
- Creating and scheduling the backup job
- Replication to a secondary Hyper-V host
- Restoring a VM
- Known issues and limitations
What this covers
Microsoft Hyper-V has been supported by Veeam for years, but v13 brings a few changes worth knowing before you start clicking through wizards. This guide walks through a complete setup from scratch on Windows Server Hyper-V, including standalone hosts and clusters managed through System Center Virtual Machine Manager (SCVMM). You will end up with a working backup job, an off-host proxy taking the processing load off your hypervisor, and a replication job if you have a secondary site to replicate to.
One note before getting into it: Veeam strongly advises against installing VBR directly on your Hyper-V host. That rule applies in v13 just as it did before. Keep the backup server on a dedicated machine and deploy infrastructure components separately.
Requirements and supported versions
Veeam v13 supports Hyper-V on the following Windows Server host versions: Windows Server 2016, 2019, 2022, and 2025. Azure Local (formerly Azure Stack HCI) is also supported. Note that Windows Server 2012 and 2012 R2 are not supported in v13 — if you are still running those host versions, you cannot upgrade VBR to v13 without first upgrading your Hyper-V hosts. Windows 10 and Windows 11 Hyper-V are supported only as restore targets for Instant Recovery and as SureBackup virtual lab hosts, not for host-based backup jobs. If you need to protect VMs running on a Windows 10 or 11 desktop hypervisor, use Veeam Agent instead.
SCVMM is optional. You do not need it to use Veeam with Hyper-V. If you do use SCVMM, supported versions are 2016 through 2025. Registering a cluster or SCVMM server rather than individual standalone hosts is the smarter move in any environment where VMs might migrate between nodes. Veeam will track migrated VMs automatically when the cluster or SCVMM server is the registered object.
If you are protecting a Hyper-V cluster using the Linux-based VBR Software Appliance, both the Hyper-V nodes and the backup server must be in the same Active Directory domain. If they are not, you will need to manually edit the krb5.conf file on the appliance before the cluster can be added. This is a v13-specific consideration that catches people off guard.
Both Generation 1 and Generation 2 VMs are supported. Pass-through disks and guest disks connected via in-guest FC or iSCSI initiators are not supported for host-based backup. Veeam will skip them automatically during processing. If those disks need to be protected, attach a Veeam Agent inside the VM instead.
Before you connect anything
Three things need to be in place on the Hyper-V host before you add it to Veeam. First, file and printer sharing must be enabled in the network connection settings. Without it, Veeam cannot deploy its components and the wizard will fail at the review step. Second, the account you use to add the server needs local Administrator rights on the host. Third, the Veeam backup server needs network access to the host on the required ports: TCP 135, 137-139, 445, 6160 (Veeam Installer Service), 6162 (Veeam Data Mover), and TCP 2500-3300 (data transfer channels). Make sure firewall rules between the VBR server and Hyper-V hosts allow this range.
If the host is part of a cluster, add the cluster DNS name or SCVMM server to Veeam rather than individual node addresses. Adding individual nodes alongside a registered cluster is redundant and creates confusion in job targeting. Pick one approach and stick with it.
If you are currently using native Hyper-V replication on any VMs that you also plan to replicate with Veeam, disable native replication first. Running both on the same VM scope can cause VM ID collisions. Use Veeam for replication going forward.
Adding the Hyper-V host or cluster
Launch the New Hyper-V Server wizard
Open the VBR console and go to the Backup Infrastructure view. In the inventory pane, right-click Managed Servers and select Add Server. In the Add Server window, select Microsoft Hyper-V, then choose between Hyper-V Server (standalone host), Hyper-V Cluster, or SCVMM depending on your environment.
Specify the server name or address
Enter the DNS name or IP address of the standalone host, cluster name, or SCVMM server. Using the FQDN is preferred over IP. Click Next.
Specify credentials
Select or add a credential record with local Administrator access to the host. If this is a domain-joined host, domain Administrator credentials work here. Click Next.
Select hosts (cluster only)
If you are adding a cluster, Veeam discovers the member nodes and lists them. By default all nodes are selected. You can deselect any node you do not want managed, but in most cases leave all nodes checked.
Review components and finish
Veeam shows which components it will deploy on the host. Click Apply to deploy them, then Finish. After the wizard closes, you may be prompted to specify settings for connected volumes. This lets Veeam know which volumes are storage for VM data. Select the appropriate volumes and confirm.
Configuring the off-host backup proxy
By default, Veeam uses on-host backup mode, which means the Hyper-V host itself processes backup data. This works, but it puts additional CPU and I/O load on a machine that is already running production VMs. An off-host backup proxy is a separate Windows machine that takes over that processing role. For any environment handling more than a handful of VMs, deploying at least one off-host proxy is worth the effort.
Add the proxy machine as a Windows server
Go to Backup Infrastructure, right-click Managed Servers, and add the machine you want to use as a proxy. It needs to be a Windows Server machine with network access to both the Hyper-V host and the backup repository. The proxy machine must have access to the storage that backs the Hyper-V VMs if you want to use off-host mode with shared storage.
Add the off-host backup proxy role
Still in the Backup Infrastructure view, expand Backup Proxies, right-click Off-Host Backup Proxies, and select Add Off-Host Backup Proxy. The wizard will ask you to select the server you just added. Click Choose, select the server, and work through the traffic rules page. Set maximum concurrent tasks based on available CPU cores on the proxy, roughly one task per two cores is a reasonable starting point.
Present Hyper-V volumes to the proxy
For true off-host backup, the proxy needs visibility into the storage volumes that host VM data. If your Hyper-V VMs run on a SAN or shared storage, present those LUNs to the proxy machine and initialize them as offline disks in Windows. Veeam uses snapshots of those volumes rather than going back through the network to the Hyper-V host. If VMs live on local host storage, Veeam falls back to network mode automatically, which still offloads processing but transfers data over the network.
By default, Veeam automatically selects the best available proxy for each job run. You can explicitly assign a proxy to a specific job in the job wizard under the Storage step. This is useful if you have proxies in different network zones and want to ensure data does not travel across a slow link.
Setting up a backup repository
Veeam supports several repository types for Hyper-V backups. For this setup we are using a Windows Server repository, which is the most straightforward starting point. Go to Backup Infrastructure, expand Backup Repositories, right-click and select Add Backup Repository. Choose Microsoft Windows Server in the type selection.
Work through the wizard, pointing it at the server and the path where backup files should land. On the Repository page, set the maximum concurrent tasks limit. A good rule of thumb is to cap this at the number of CPU cores available on the repository server divided by two. Enable per-machine backup chains. This stores each VM's backup chain in a separate set of files, which significantly simplifies management and allows Veeam to remove individual VMs from a job without touching other VMs' backup files.
On the Mount Server step, select a Windows machine that is close to the repository. This machine is used during file-level and application item restores to mount backup files. If you are restoring VMs that ran Windows Server with Data Deduplication enabled, deploy the mount server on a machine running the same or newer Windows Server version with Data Deduplication enabled, or some restore types will fail.
Creating and scheduling the backup job
Launch the New Backup Job wizard
From the Home view, right-click Jobs, select Backup, then Virtual machine, and choose Microsoft Hyper-V. Give the job a descriptive name. The description field is worth filling in, especially if multiple people manage this environment.
Add virtual machines
Click Add, and the VM inventory tree opens, scoped to the Hyper-V infrastructure you registered. You can add individual VMs, entire hosts, or containers like folders or clusters. Adding at the container level is useful when VMs are added to the environment regularly because new VMs in that container are automatically included in the job on the next run.
Configure storage settings
Select the backup repository you created. Set your restore point retention. For most production workloads, 14 to 30 daily restore points is a reasonable range. Enable synthetic full or active full backups on a weekly schedule so you have a reliable recovery base that does not depend on a long incremental chain.
Configure guest processing
Enable application-aware processing if any VMs run Microsoft SQL Server, Exchange, Active Directory, or other VSS-aware applications. Veeam uses VSS inside the guest to quiesce applications before the snapshot, ensuring a transactionally consistent backup. Provide guest OS credentials on this step. Microsoft VSS integration is fully supported on Windows Server 2016 and later running inside Hyper-V VMs.
Set the schedule
Set a daily backup window that aligns with your RPO requirements. Most environments run nightly jobs with a backup window that closes before business hours. If you have VMs with tighter RPO requirements, consider a secondary backup job running at midday, or evaluate Veeam Replication for near-hourly protection.
Replication to a secondary Hyper-V host
Veeam supports VM replication between Hyper-V hosts, provided both sides run a supported Hyper-V version. Replication is always hypervisor-to-hypervisor, so you cannot replicate from a Hyper-V source to a VMware target using the replication job type. Hyper-V VMs with shared VHDX or VHDS disks cannot be replicated using the replication job. Use backup for those.
To create a replication job, go to Home, right-click Jobs, select Replication, then Virtual machine, and choose Microsoft Hyper-V. The wizard is structurally similar to the backup job wizard. At the Destination step, specify the target host and the path on that host where replica VHDX files should be stored. At the Job Settings step, specify the backup repository where replica metadata will be stored. The metadata repository should be close to the source, not the target.
Set restore points to keep between 3 and 7 for a typical DR replication job. More restore points increase storage consumption on the target host but give you more rollback options if the replica becomes compromised.
If replicating over a WAN link to a remote site, configure network throttling rules under Veeam settings to prevent the replication job from saturating the link during business hours. You can also enable WAN accelerators if you have a WAN accelerator component deployed at both sites.
Restoring a VM
Veeam offers several restore types for Hyper-V VMs. Entire VM restore brings the VM back to the original or a new host in its full state. Instant VM Recovery mounts the backup file directly and registers the VM on the target host so it can power on within minutes while Veeam migrates the data in the background. For individual files, use the file-level restore option which mounts the backup and lets you browse the file system inside. For SQL databases, Active Directory objects, or Exchange items, the Explorer tools provide application-aware granular recovery.
To start any restore, go to the Home view, open the Backups node, find the VM, right-click it, and select the restore type you need. Veeam will walk you through the restore options including target host and whether to power on after restore.
Known issues and limitations
A few things worth knowing before you go to production. First, do not install Veeam Backup and Replication on the Hyper-V host itself. This applies whether the host is standalone or a cluster node. The behavior becomes unpredictable and support will push back on it. Second, if VMs are migrating between hosts in a cluster that is not registered in Veeam, jobs targeting those VMs need to be updated manually. This is why registering the cluster rather than individual nodes matters. Third, pass-through disks are silently skipped during backup. If a VM uses pass-through storage and you do not have an agent backup covering those disks, that data is not protected.
On the v13 Software Appliance specifically, note that the Linux-based appliance requires domain membership to back up Hyper-V clusters. Standalone hosts do not have this requirement. This is a known limitation in v13.0.1 and may be addressed in a future update.
- Hyper-V host or cluster registered in VBR v13
- Off-host backup proxy offloading processing from the hypervisor
- Backup repository configured with per-machine chains
- Backup job with application-aware processing and a scheduled run
- Optional replication job to a secondary Hyper-V host for DR
Hyper-V is one of the more straightforward hypervisors to integrate with Veeam once you get the proxy and storage access sorted out. The on-host versus off-host decision is the one that trips people up most often. If your hosts have headroom to spare and you are protecting a small number of VMs, on-host is fine. If your hosts are running at capacity during backup windows, move the work to a dedicated proxy and your backup windows will shrink noticeably.