Free Hyper-V backup: how to back up Hyper-V virtual machines

What you will set up

BackupZit backs up Hyper-V virtual machines from the agent on the Hyper-V host; nothing is installed inside the VMs. Windows and Linux guests keep running while they are captured. A web console schedules the jobs, keeps the history and runs the restores. BackupZit is free and open source (AGPLv3), with no limit on hosts or VMs.

• What you need
• 1. Console
• 2. Storage
• 3. Agent on the host
• 4. Backup job
• 5. Consistent backups
• 6. Off-site copy
• Restoring
• Limits

What you need

• A Hyper-V host: Windows Server 2016 or newer with the Hyper-V role, or Windows 10/11 with Hyper-V. In a cluster, every host.
• A place for the BackupZit console: a small Linux VM with 2 vCPU, 2–4 GB RAM and a 16–20 GB disk. It stores no backup data itself, so it can run as a VM on the same Hyper-V host.
• Backup storage outside the host — for example an SMB share on a file server or NAS, a Linux server over SFTP, an S3-compatible bucket or a BackupZit hardened repository. The agent writes to it directly.
• Network: the agent reaches the console on TCP port 8443.

Step 1 — Install the console

The quickest way on Hyper-V is the ready-made VM image backupzit-appliance-vhdx.zip from the download page (Debian, PostgreSQL and the console, already set up):

1. Unzip backupzit-appliance-vhdx.zip into the folder where your VM disks live.
2. In Hyper-V Manager create a generation 1 VM with 2–4 GB RAM, connect it to a virtual switch and choose the extracted VHDX as its existing disk.
3. Start the VM. Its screen shows the address of the web console and the initial password of the user admin. Open https://<address>:8443, sign in and change the password. The browser warns once about the self-signed certificate.

On the VM's own screen you can sign in as bzadmin to set a static address, the server name and the time zone (the appliance starts in UTC, and schedules run in the console's time zone). Prefer an existing Debian, Ubuntu, AlmaLinux or Rocky Linux server? The one-line install script on the download page does the same there.

Step 2 — Add a storage target

In the console open Storage and add a target. Typical choices in a Windows environment:

Leave Encrypt backups on (the default): everything is encrypted with AES-256 on the host before it leaves it. The console then shows a recovery key — print the recovery sheet or put the key in a password manager, away from the backups. With the key, the storage location and its credentials you can restore even if the console is lost.

Step 3 — Install the agent on the Hyper-V host

1. In the console open Agents and click Create enrollment token. You get an enrollment code (BZ1-…) that is valid for 7 days and works for any number of machines.
2. Download the Windows agent MSI from the Agents page, run it on the host and paste the code when the installer asks for it. For several hosts, a silent install works through GPO, Intune or an RMM tool:

   msiexec /i backupzit-agent.msi /qn ENROLLCODE="BZ1-..."

   The console can also install the agent itself over WinRM: Agents → Install on a machine from here, with an administrator account that is used only for the installation and not stored.
3. Within a minute the host appears on the Agents page with the badge Hyper-V · N VMs.

The agent works through Hyper-V's own interfaces: the Hyper-V PowerShell module and the Windows Virtual Disk API. The console stores no Hyper-V credentials. In a cluster, install the agent on every host.

Step 4 — Create the backup job

1. Open Backup jobs, create a job and select the host's agent.
2. Choose Virtual machines (Proxmox VE, Hyper-V, VMware), then All VMs (and containers) on the host — VMs created later are included automatically — or tick individual VMs.
3. Pick the storage target from step 2.
4. Set a schedule, for example every working day at 22:00. Jobs can also repeat every 15 minutes to 12 hours, run once a month, or start after another job has finished.
5. Set the retention. Example: 3 most recent, 7 daily, 4 weekly, 6 monthly keeps about half a year of history with around 20 restore points.

What happens in each run:

1. A temporary recovery checkpoint (backupzit_…) is taken — the checkpoint type Hyper-V provides for backup applications. The VM keeps running.
2. The recovery checkpoint switches on Resilient Change Tracking (RCT) for the VM's disks; you will see .rct and .mrt files next to them. The first backup reads the whole disks; after that, RCT reports which blocks changed since the previous backup, and only those are read.
3. The disks are read as of the checkpoint in 1 MiB blocks — VHDX and VHD, including chains of earlier checkpoints. Empty blocks are not stored, and blocks already in the repository are not uploaded again. Each backup is still a complete restore point.
4. The checkpoint is removed and Hyper-V merges it in the background. The VM's configuration is stored with the backup: generation, CPU, memory, network adapters (switch, VLAN, MAC address), disk controllers, secure boot and TPM.

An example from the BackupZit test lab: a Linux VM with a 3 GB disk. The first backup read 3 GB; the next one, after 64 MB of new data, read 96 MB.

VMs that are turned off are read directly, without a checkpoint. On hosts older than Windows Server 2016 there are no recovery checkpoints: a production checkpoint is used and every backup reads the whole disks.

Step 5 — Make the backups application consistent

For a recovery checkpoint, Hyper-V asks the guest to prepare:

• Windows guests flush their applications (SQL Server, Exchange, Active Directory…) through VSS.
• Linux guests freeze their file systems if the Hyper-V daemons are installed — the hyperv-daemons package or hv-vss-daemon, depending on the distribution.

If the guest can do neither, the checkpoint is taken crash consistent — like after a power loss. The run page shows, per VM, which kind was used, so you can see at a glance which guests still need the daemons.

Step 6 — Keep an off-site copy (3-2-1)

The 3-2-1 rule: three copies of your data, on two different media, one of them off-site. Add a second job of the kind Backup copy, select the Hyper-V job as its source and an off-site target, such as an S3 bucket with Object Lock or a hardened repository in another building.

• The agent copies the existing backups; the VMs are not read again.
• Only data that is not yet at the destination is sent, encrypted with the destination's key.
• The copy has its own schedule and retention, e.g. 7 daily on the NAS and 12 monthly in the cloud.

VMs and single files can be restored from the copy like from the original. Automatic restore tests (weekly by default, under Settings → Restore tests) read random blocks of the newest VM backups and verify them against their checksums. More about immutable copies on the ransomware protection features.

Restoring

Open a backup run (from the job page or Activity) and choose Restore a Hyper-V VM. You can restore on the same host or on another Hyper-V host with the agent.

As a new VM next to the original

• Creates a second VM with new MAC addresses, so it can run on the same network as the original. By default it is named after the original plus "restored" and the date.
• Automatic checkpoints are turned off on it, so starting it leaves no checkpoint files behind.
• Guest network settings tied to a MAC address (for example netplan's match: macaddress in Linux cloud images) don't apply to the new adapters.

In place of the original VM

Tick turn it off and replace its disks. BackupZit turns off the existing VM, merges its checkpoints and swaps its disks for the restored ones. The VM keeps its ID, network adapters and MAC addresses, so jobs, monitoring and the guest's network keep working. The old disk files are not deleted but renamed to ….replaced-DATE — delete them once the restored VM works. If the original VM no longer exists, it is created again with a new Hyper-V ID.

What a restored VM gets

• Virtual switches are connected by name; if a switch doesn't exist on the host, the adapter stays disconnected.
• Every restored VM gets a new generation ID, so Active Directory domain controllers detect the restore safely.
• Options: the folder for the virtual disks and whether to start the VM after the restore.

Single files

Click Browse files in the VM table of a backup run to see the partitions and volumes on the VM's disks. You can browse NTFS, ext2/3/4 and XFS, also inside LVM, and download files (several as a ZIP) or restore them to a folder on any agent — no need to restore the whole VM for one lost document.

From the command line

Everything also works without the console, as administrator on the Hyper-V host — for example to rebuild a host after a disaster:

backupzit-agent hyperv list
backupzit-agent hyperv backup  --repo ... [--vmid N,N]
backupzit-agent hyperv restore --repo ... --vmid N --new --name NAME --folder D:\VMs --start latest

--vmid is the number shown by hyperv list. Without --new the VM is restored in place; --overwrite confirms that the disks of an existing VM may be replaced.

Limits to know

• Shared VHDX, VHD Set and pass-through disks are not backed up.
• Instant recovery (running a VM straight from the backup) is available for Proxmox VE and VMware, not yet for Hyper-V — it is planned. A Hyper-V restore copies the disks first.
• Hosts older than Windows Server 2016 have no recovery checkpoints and no RCT, so every backup reads the whole disks.

Next steps

Download BackupZit, see all Hyper-V features, or read the full chapter Hyper-V virtual machines in the user guide in the console. Running Proxmox too? See the Proxmox VM backup guide. Questions are welcome in GitHub Discussions; companies can get commercial support from MaxZit.