VM Backup Compatibility Matrix: Supported Platforms and Versions

A VM backup compatibility matrix shows which hypervisor and platform versions a backup product can connect to, and which backup and restore functions work on each. As listed in the Vinchin Help Center on September 20, 2026, Vinchin Backup & Recovery protects VMware vSphere 5.0 to 8.0 U3, Microsoft Hyper-V on Windows Server 2012 R2 to 2022, Proxmox VE 7.2 to 9.1, XCP-ng 7.4 to 8.3, Citrix Hypervisor 8.0 to 8.4, oVirt 4.0 to 4.5, Red Hat Virtualization (RHV) 4.0 to 4.5 and Oracle Linux Virtualization Manager (OLVM) 4.3 to 4.5, plus other platforms. A version appearing on that list answers only one of three questions: whether the tool can connect, whether the platform vendor still supports that version, and whether incremental backup will work on your VMs.

Key Takeaways

• Read every matrix in two passes. The version pass tells you whether a tool can connect; the capability pass tells you whether incremental backup, instant restore, and cross-platform restore work on that version and configuration.

• Five of the eight core platform lines include versions their own vendors no longer support: vSphere 7.0, Proxmox VE 7 and 8, XCP-ng 8.2, RHV 4.x and Windows Server 2012 R2.

• Incremental backup is decided per VM, not per platform. VMware needs VM hardware version 7 or later with change tracking enabled, Hyper-V’s RCT-based backup needs a Windows Server 2016 or later host, and libvirt/QEMU incrementals need qcow2 disks.

• Restore options differ by platform. The Vinchin Help Center documents Instant Restore for VMware, Proxmox VE, XCP-ng, Citrix, oVirt, RHV, and OLVM, but lists only Full, Granular, and Cross-Platform Restore for Hyper-V.

• Newest releases may not be listed yet. vSphere 9.x and Hyper-V on Windows Server 2025 do not appear in the Help Center’s VM backup list as of September 20, 2026. Confirm before upgrading hosts.

• Re-verify at each upstream deadline. The next one in this data set is January 12, 2027, when Windows Server 2016 extended support ends.

What Does Supported Mean in a VM backup Compatibility Matrix?

"Supported" can mean three different things. A matrix that does not say which one it means is incomplete.

This table (Table 1) lists three layers.

Three stacked layers (Connection, Capability, Lifecycle) with a VM at the top and one example failure per layer, so the reader sees that a green tick on one layer says nothing about the other two.

This article scopes to agentless, image-level VM backup taken at the hypervisor level. Databases, mail servers, and file systems inside the VM have their own version lists, covered in the FAQ.

Which Platforms and Versions Does Vinchin List for VM Backup?

The tables below reproduce the Supported Environments section of the Vinchin Help Center as of September 20, 2026. Vinchin Backup & Recovery takes VM backups from the hypervisor level without installing agents inside guests. Where the Help Center writes a family such as "5.x" or "4.X.X", that wording is kept.

This table (Table 2) shows the core virtualization platforms and listed versions.

The following table (Table 3) shows other virtualization, private cloud, and container platforms.

Which Restore Methods are Documented for Each Platform?

Full and Granular Restore are documented for every platform in the following table. Instant Restore is documented for every listed virtualization platform except Hyper-V.

This table (Table 4) shows restore options documented in the Vinchin Help Center, by platform.

Does Its Own Vendor Still Support a Version on the Backup List?

Not necessarily. A backup vendor's list defines what the tool can read. It does not track whether the platform vendor still patches that version.

This table (Table 5) lists Vinchin-listed versions against upstream vendor lifecycle status.

Why Does the Same Platform Version Give Different Backup Results?

Because incremental backup depends on change tracking, and each platform's change tracking has its own prerequisites that vary by VM and disk, not just by version.

This table (Table 6) outlines the Change-tracking prerequisites that determine whether incremental backup works.

How Do You Verify Compatibility Before Deploying?

Compare exact versions, check capability prerequisites, then prove one incremental cycle and one restore on a pilot VM.

1. Record exact versions. Capture the host build and the manager version (vCenter, oVirt/RHV engine). Use the commands in the following table. Easy to get wrong: "vSphere 8.x" is not a version; the list names 8.0 U1, U2, and U3.

2. Compare against the vendor's list at the update level. Match hotfix suffixes such as Sangfor's "R1" and build-specific entries such as H3C's E-numbers.

3. Check lifecycle status on the platform vendor's page (Table 5 sources).

4. Check capability prerequisites from Table 6: VM hardware version, Hyper-V host OS, qcow2 disk format, and any platform-side plugin. Easy to get wrong: on RHV, the plugin must match the exact platform version and, below 4.4.7, goes on every host but not on the engine.

5. Run the pilot. Back up a representative VM twice and confirm the second run is incremental.

6. Test each restore mode you depend on. Use Table 4 to choose which to test, including a restore to the intended target platform. Easy to get wrong: testing only Full Restore and assuming Instant or Cross-Platform Restore behave the same.

7. Date-stamp the result and re-run before any host upgrade.

The following table (Table 7) is about commands for capturing version and configuration data.

These commands are standard on their platforms. Output details vary by version and configuration.

Which Action Fits Which Situation?

Decide by two facts: whether your exact version is on the backup vendor's list, and whether the platform vendor still supports it.

This table (Table 8) is a decision matrix.

Common Mistakes

• Treating a major-line entry as covering every update level within it.

• Checking the host version but not the manager version, or the reverse.

• Assuming Instant Restore exists on every listed platform.

• Forgetting that guest-level lists (databases, Exchange) are separate from the VM platform list.

• Sizing storage from the first successful incremental in a pilot without checking the disk or hardware-version conditions in Table 6.

How Do These Rules Apply in Typical Estates?

These are illustrative scenarios built from the tables above, not customer case studies.

The following table (Table 9) is scenario-based recommendations.

Troubleshooting: Compatibility Symptoms and Causes

FAQs

Q1: Should I check the compatibility list before upgrading my hypervisor, and should I take a backup first?

Yes to both. Proxmox VE documents that minor upgrades are ordinary package updates, while major upgrades such as 8.4 to 9.0 must be carefully planned and tested and should never be started without a current backup ready. Take a fresh backup, run a test restore, confirm the target version is listed by your backup vendor, and only then upgrade.

Q2: Are Windows client editions of Hyper-V covered?

The Help Center lists Windows 8.1, Windows 10 and Windows 11 (Desktop) under the Microsoft Hyper-V Server entry, alongside Hyper-V Server 2012 R2 to 2022. Hyper-V on Windows Server is listed separately for 2012 R2, 2016, 2019, and 2022.

Q3: Does Vinchin support standalone ESXi hosts or only vCenter?

Vinchin's VMware backup page states that it protects vSphere environments on standalone ESXi hosts or vCenter-managed hosts.

Q4: Does the VM platform list cover databases and applications running inside the VMs?

No. Database and application support is listed separately, for example Oracle Database 10g to 21c, Microsoft SQL Server 2008 to 2022, MySQL 5.5 to 8.0, PostgreSQL 12 to 16, and Exchange Server 2013 to 2019. Check both lists when application-level recovery matters.

Q5: Are Kubernetes clusters and cloud instances covered by the same list?

They are listed in separate sections. Kubernetes 1.28.15, 1.30.6 and 1.33.1 are listed, along with AWS EC2 and Huawei Cloud ECS instances.

Conclusion

Treat every compatibility list as a dated snapshot. Before adding a platform, upgrading a host, or planning a migration, compare the exact version, test one incremental cycle and one restore, and note the date. The matrix that matters is the one you verified on your own VMs, not the one printed on any vendor page, including this one.