Choose the product that (1) lists your platform and your exact version, (2) can run incremental backup on your actual disk types, and (3) passes a test restore, ideally to a second platform. A shared “KVM-based” label does not mean these six platforms behave the same way for backup. Each one defines its own disk formats, management layer, and backup eligibility rules.
Key Takeaways
Version-level support decides eligibility. “Support H3C” or “support Sangfor” is not enough; check the exact CAS/UIS build, Sangfor HCI/SCP release, or ZStack version.
Incremental backup depends on disk type, not just platform. H3C documents that VMs on raw disks or block devices do not support incremental or differential backup.
Native backup is not a recovery strategy by itself. CISA recommends offline, encrypted backups that are tested for availability and integrity.
Restore flexibility is a selection criterion. If a platform change is plausible in 12-24 months, test a cross-platform restore during the PoC.
Run a proof of concept on your worst-case VMs. Pick VMs with raw disks, snapshots, large data disks, and busy databases, not the easiest ones.
What Makes These Six Platforms a Separate Selection Problem?
Each platform exposes its own management layer and backup interfaces, so a backup product has to integrate with each one individually.
H3C CAS consists of CVK (the virtualization kernel on each host), CVM (the management system), and CIC (the cloud business layer), per H3C’s component documentation.
ZStack Cloud is managed through management nodes and exposes RESTful APIs and Java/Python SDKs, per ZStack’s architecture white paper.
Sangfor builds HCI from aSV (server virtualization) and aSAN (storage), per the Sangfor HCI datasheet.
Inspur InCloud Sphere is an enterprise virtualization platform sold in standard, advanced, security and ARM versions, per Inspur.
Arcfra AECP bundles virtualization (AVE), storage, and Kubernetes services into a single platform, per Blocks & Files.
KAYTUS KayGrid is KAYTUS’s compute virtualization system and the compute layer within the KSRail hyper-converged platform, per KAYTUS.
Practical implication: a backup tool's "supported platforms" count tells you little. What matters is the depth of each row: versions, backup methods, and recovery options.
Platform Mechanics at a Glance
Platform
| Engine (as publicly documented)
| Native backup/CBT facts worth knowing
| What to verify with any backup vendor
|
H3C CAS/UIS | KVM is CAS's core virtualization engine since 2017 | CBT backup supported from CAS E0525; raw/block-device disks lack incremental support | Exact CAS/UIS build; disk format; VMs with snapshots |
ZStack Cloud | Bottom layer supports KVM and VMware | Has a native Backup Service API; "backup storage" in ZStack means an image repository, not a data-protection target | ZStack version; primary storage type; KVM vs VMware layer |
Sangfor HCI/SCP | aSV is a type-1 architecture with KVM as its core engine, integrated with the SFFS clustered file system | Storage layer (aSAN/SFFS) is vendor-specific | HCI vs Sangfor Cloud Platform release; storage layer behavior |
InCloud Sphere | Publicly described as KVM-based in 2018 launch coverage; confirm against current Inspur documentation | Not documented in the sources reviewed | Version; whether the iCenter/OpenStack layer is used |
Arcfra AECP | AVE is described as built on KVM (Blocks & Files); AECP also supports VMware vSphere as a hypervisor | Not documented in the sources reviewed | AVE vs vSphere clusters in the same estate |
KayGrid/KSRail | Engine not stated on KAYTUS public pages reviewed | KAYTUS lists VM backup, snapshot, and cloning as KayGrid features | Version: standalone KayGrid vs KSRail HCI |
How Does Incremental Backup Work on KVM-based Platforms?
The hypervisor records which disk blocks changed since the last backup, and the backup software reads only those blocks.
On upstream KVM/QEMU, libvirt implements this with QEMU block dirty bitmaps tied to checkpoints; per the libvirt documentation, the bitmaps must be consistent across the image backing chain to be usable for an incremental backup. Vendor platforms wrap this mechanism in their own implementation. H3C, for example, describes CBT as a per-disk bitmap that records incremental data.
A shared KVM engine does not give you a shared backup contract
Three documented facts fit together. First, incremental tracking depends on bitmaps that must stay consistent across the disk image chain (libvirt). Second, H3C's CBT backup requires intelligent disks with single-level image files and does not cover raw or block-device disks. Third, Sangfor's aSV sits on its own SFFS clustered file system, and ZStack supports several primary storage types. The common engine is therefore only the starting point: whether a given VM gets true incremental backup depends on its disk format, snapshot state, and storage layer.
Practical consequence: in an evaluation, list every VM by disk type and snapshot status before talking to vendors, and ask each one which of those VMs get incremental backup. A vendor can legitimately "support the platform" while a share of your VMs still fall back to full backups, which lengthens the backup window and increases storage use. This is an analysis of the documented constraints, not a measured result.
What Criteria Should You Use to Compare Backup Solutions?
Use seven criteria, ordered by how often they eliminate candidates.
Criterion
| Why it matters
| How to test
|
Exact version support | Eligibility is version-specific | Match your build against the vendor’s current support list |
Incremental eligibility per disk type | Determines backup window and storage | Back up a raw-disk VM and a VM with snapshots |
Agentless operation | Avoids installing agents in every guest | Confirm no guest agent is needed for crash-consistent backup |
Restore options | Whole-VM, file-level, instant restore, cross-platform | Perform each in the PoC |
Transport and load | LAN vs SAN/LAN-free affects production impact | Run a backup during business hours and watch host load |
Ransomware resilience | CISA recommends offline, encrypted, tested backups | Check immutability or WORM, separate credentials, offline copy |
Recovery objectives | RTO is how long a system can stay in recovery before the mission is affected | Time a full restore against your RTO |
Decision Matrix: Which Approach Fits Your Situation?
Your Situation
| Recommended direction
| Verify first
|
One platform, standard disks, small estate | Native backup may be enough for the first copy; add an independent copy | Does the native copy leave the platform? |
H3C CAS with raw or block-device disks | Plan for full backups on those VMs, or change disk format where policy allows | H3C incremental limits for your build |
Mixed estate (e.g., H3C + Sangfor + ZStack) | One backup product with a per-platform feature row for each | Differences in restore options per platform |
Platform change expected within 12–24 months | Prioritize cross-platform restore | Restore from platform A onto platform B in the PoC |
Ransomware exposure is the main concern | Immutable or offline copy with separate credentials | Who holds the delete rights |
Arcfra estate that mixes AVE and vSphere | Confirm both hypervisor types are covered | Support for each cluster type |
Platform-Specific Notes
H3C CAS/UIS
H3C's documentation states that CBT backup does not back up snapshots, so restoring from a CBT backup of a VM that had snapshots loses the snapshot information. It also says the VM's running state must not change during a CBT backup, or the job fails, and that only CBT full and CBT incremental modes are supported. Build this into change windows: do not schedule live migration or power operations during a backup.
ZStack
Do not confuse ZStack's backup storage (an image repository for templates and ISOs) with a data-protection target. ZStack also has a separate Backup Service with its own API; whether it is available depends on version and license.
Sangfor HCI/SCP
Inspur offers several editions (standard, advanced, security, ARM). Confirm that the edition and version in your data center are on the backup vendor's list.
Arcfra AECP
Because AECP can run VMware vSphere as well as AVE, an Arcfra estate can contain two different hypervisor types. Check coverage for each.
KayGrid/KSRail
KAYTUS documents VM backup, snapshot, and cloning as KayGrid features. Ask the backup vendor which KayGrid versions are covered and how disks are read.
Why Does Cross-Platform Restore Matter in This Section?
Because the platform you protect today may not be the platform you run in two years.
Choose the backup tool for the platform you may move to, not only the one you run.
Several of these platforms are explicitly positioned as alternatives. Sangfor presents aSV as a stable option after Broadcom's licensing changes, and Arcfra is positioned as a VMware alternative and can run vSphere alongside AVE. In an estate that is being re-platformed, backups are often the only complete copy of a VM that exists outside the source platform. If those backups can only be restored onto the platform they came from, the backup tool becomes a constraint on the migration.
Practical consequence: add one test to your PoC, restoring a VM backed up on platform A onto platform B, and record whether drivers, boot, and networking work afterward. This reasoning follows from the platforms' own positioning; it is not a prediction about any specific customer.
Other Factors to Check Before Purchase
After technical fit, check twelve commercial and operational factors: licensing, support, cost, repository options, security controls, auditability, reporting, alerting, compliance, multi-tenancy, scale, and regional support. These rarely appear in feature lists, but they decide whether a product that passes the PoC is still workable in year two.
Factor
| Why it matters
| What to ask or request
|
Licensing model | Per-socket, per-VM, per-capacity and subscription models behave very differently across a mixed estate and when platforms change. | What exactly is counted (sockets, VMs, TB)? Do standby DR hosts count? Does restoring or migrating a VM to another platform change the license? Vinchin, for example, publishes edition and scale tiers on its How To Buy page; compare any vendor against your own host and VM counts. |
Support SLA | "Support" can mean response time, resolution time, or only a ticket queue. | Request the severity matrix in writing: support hours, response targets per severity, escalation path, and whether platform-specific issues (a new CAS, SCP or ZStack build) are in scope. |
Maintenance cost | Renewal and upgrade terms plus the effort of re-validating after every platform upgrade add to the purchase price. | Renewal uplift limits, upgrade fees, how quickly support follows new platform builds, and the admin hours your own team will spend on repository care and restore testing. |
Backup repository options | The repository sets cost, restore speed, and survivability. NIST SP 800-53 CP-9 includes controls for separate storage and transfer to an alternate site. | Supported targets (local disk, NAS/SAN, object storage, tape), where deduplication and compression happen, how a second copy is made, and how capacity growth is forecast. |
Encryption and access control | NIST SP 800-53 CP-9(8) calls for cryptographic mechanisms to prevent unauthorized disclosure and modification of backup information. | Encryption in transit and at rest, key management and recovery (a lost key can make backups unreadable), role-based access, MFA, separate admin credentials from production, and whether deletion can require a second approver. |
Audit logs | Without logs, you cannot show who changed a policy, ran a restore, or deleted a backup. NIST AU-2 expects organizations to decide which events are logged. | Which events are recorded (logins, job and policy changes, restores, deletions), retention period, export to syslog or a SIEM, and protection of the log itself from tampering. |
Reporting | Managers and auditors need evidence, not only a console. | Reports for job success, missed RPO, capacity trend and restore-test results; scheduled delivery; export formats. A "success" status shows a job ran, not that a restore works. |
Alerting | A failed or missed job that nobody sees is an unprotected VM. | Supported channels, and whether alerts cover failed and missed jobs, repository space, failed verification and unusual deletions. |
Compliance requirements | Retention, data residency, immutability and evidence of restore testing vary by regulator and industry. | Map your obligations to product capabilities, and ask for documentation rather than assurances. This is not legal advice; confirm requirements with your compliance team. |
Multi-tenant management | Service providers and multi-department organizations need isolation and delegated administration. | Tenant isolation, per-tenant quotas, delegated roles, per-tenant reporting, and whether these work on all six platforms or only some. |
Scalability for large VM estates | A product that handles a 50-VM pilot may behave differently at several thousand VMs. | Documented limits per backup server, job concurrency, and scale-out options such as clustered servers or distributed backup nodes. Test with a realistic VM count; do not extrapolate from the pilot. |
Vendor support coverage by region | Time zones, languages, and local partners decide who answers at 3 a.m. during a restore. | Support hours in your time zone, available languages, local partners, and how issues are escalated when the fault sits with the hypervisor vendor rather than the backup vendor. |
Two points deserve extra attention in this estate. First, your support chain has two layers: the platform vendor and the backup vendor. Regional platform vendors may have support footprints that differ from the backup vendor's, so ask who owns an issue that spans both. Second, treat the security controls (encryption, access, audit logs) as a single test: if an attacker obtains production credentials, can they delete backups, and would the audit log show it? That is the same question as step 8 of the PoC below.
Vinchin Support Matrix for These Six Platforms
Vinchin publishes supported versions for these six platforms. The table below reproduces what Vinchin's own pages state (retrieved October 13, 2026). Version lists change with each Vinchin release, so confirm against the current help center before purchase.
Platform
| Versions published by Vinchin
| Official source
| Limits and notes
|
H3C CAS/UIS | CAS: E0506, E0526, E0530, E0535, E0706, E0709, E0710, E0718, E0730, v7.0
UIS: E0606, E0611, E0716, E0720, E0721, E0750, E0881, E0802P01
CAS/UIS CVD: E082P01, E0886, E0786P02, R0785P03 | Help center; H3C backup job guide
| CAS/UIS and CVD are separate entries. The backup job guide lists LAN as the transfer path for H3C. A job can contain VMs from one platform only. H3C's own CBT limits (raw/block disks, snapshots) are described earlier in this article; ask how Vinchin's incremental mode behaves on those disks for your build. |
Sangfor HCI/SCP | HCI: 5.x, 6.0.1, 6.0.1R1, 6.2.0, 6.3.0, 6.7.0, 6.7.0R2, 6.8.0, 6.8.0R1, 6.8.1, 6.9
SCP: 6.10.0, 6.10.0.R1, 6.11.1 | Help center; Sangfor HCI backup job guide
| HCI and SCP have separate sections. The guide lists LAN transfer with an optional RSA-encrypted transfer channel. Jobs cannot mix platforms. |
ZStack | ZStack ZSphere: 4.X.X
ZStack Cloud: 3.5, 3.7, 3.8, 3.9, 3.10, 4.0.1, 4.3.0, 4.3.28, 4.4.16, 4.5.1, 4.6.11, 4.7.11, 4.8.0, 5.X.X | Help center; ZStack ZSphere guide
| ZSphere and ZStack Cloud are listed separately; check which one you run. For ZSphere, a lightweight backup plugin is installed on each ZStack host. In the help center navigation, the ZStack Cloud restore section lists full, granular and instant restore but no cross-platform restore page, whereas ZSphere does; confirm if this matters to you. |
InCloud Sphere | ICS: V5R06B08, V5R06B213-b1, V5R06B314-b4, V5R08B117-b1, V5R08B214-b1, V6R00B015-b6, V6R00B117-b2, V6R05B017-b1, V6R05B114-b1, V6R05B317-b3, V6R08B011-b6, V6R10B025-b2, V6R10B115-b1, V5R08B111-b1-aarch64
ICS VVDK: V6R05B317-b3, V6R08B011-b6, V6R10B025-b2, V6R10B115-b1, V6R15A011-b5 | Vinchin InCloud Sphere page
| Not included in the help center's Supported Environments list at the time of retrieval, and no dedicated help-center backup guide was found. ICS and ICS VVDK are listed as separate entries. Match your exact build string. |
Arcfra | Arcfra 6.1.1 (product page); os6.1.1 and aoc4.4.0 (help center) | Vinchin Arcfra page; Help center
| One version is published. Arcfra announced AECP 6.3 in March 2026, so confirm coverage if you run a newer release. The pages do not say whether AECP clusters running vSphere are covered. |
KayGrid | V6R18B124-b2(6.18.1) | / | / |
General conditions from the same help-center guides: backup jobs cover VMs from one virtualization platform each; WORM protection can be enabled only on storage that has WORM enabled; and encrypted backups require the password to be entered at restore. Vinchin's How To Buy page lists KayGrid, InCloud Sphere, and Arcfra among supported platforms.
Proof-of-Concept Workflow (8 Steps)
1. Inventory VMs. Record platform, build, disk type, snapshot status, size, and criticality.
2. Match versions. Compare each build to the vendor's current support list. Failure point: a minor release not on the list.
3. Choose test VMs. Include one raw-disk VM, one VM with snapshots, one large data VM, and one database VM.
4. Connect the platform. Add the host or management endpoint to the backup console.
5. Run full, then incremental. Confirm the second job actually transfers only changed data.
6. Run business-hours load test. Observe host CPU, storage latency, and network.
7. Restore three ways. Whole VM to the original platform, file-level, and (if relevant) to another platform. Time each against your RTO.
8. Test the failure case. Remove or lock the backup repository access and confirm what an attacker with production credentials could delete.
Common Mistakes
Treating "KVM-based" as proof of compatibility.
Testing only the easiest VMs.
Counting a snapshot on the same platform as a backup.
Reading ZStack "backup storage" as a backup target.
Never restoring to a different host or platform until an emergency.
Reading a vendor's platform count as depth.
FAQs
Q1: Does a backup product that supports H3C CAS also support H3C UIS?
Not automatically. CAS and UIS builds are listed separately in Vinchin's help center, for example, so check the specific line and build.
Q2: Why did my incremental job run as a full backup?
Possible causes include disk type (raw or block devices on H3C), a changed or reset tracking state, or a first run after a configuration change. Confirm against your platform's documentation for the exact build.
Q3: Is the platform’s native backup enough if it writes to a remote server?
It can be the first copy. CISA's guidance is to keep offline, encrypted backups and test their availability and integrity, so add a copy that production credentials cannot delete.
Q4: What is the difference between ZStack “backup storage” and a backup repository?
ZStack backup storage holds VM image templates and ISO files. A backup repository belongs to the backup software.
Q5: Do I need a separate product for a mixed Arcfra AVE and vSphere estate?
Not necessarily, but confirm that the product supports both hypervisor types, since they are different platforms from a backup perspective.
Conclusion
The decisive questions are specific: does the product list your exact build, can your actual disks run incremental backup, and can you restore where you need to? Answer them with a proof of concept on your hardest VMs rather than a platform count, and keep one copy beyond reach of production credentials.
