What Is Huawei FusionCompute?
Huawei FusionCompute is Huawei's cloud operating system for server virtualization. It virtualizes compute, storage, and network resources, then pools them so one server can host many isolated VMs. It is the foundation of the FusionSphere stack and runs on both x86 and ARM (Kunpeng) servers. It also ships with eBackup, Huawei's native backup component.
FusionCompute uses a two-part architecture. The CNA (Compute Node Agent) runs on every host and contains UVP, the KVM-based hypervisor, plus VNA, the management agent. The VRM (Virtual Resource Management) node provides the WebUI portal. Storage spans SAN, local disks, and FusionStorage Block.
Why Do You Need to Back Up Huawei FusionCompute?
FusionCompute's built-in HA restarts a VM on another host when a physical server fails. But HA is not a backup. It does not recover from accidental deletion, corrupted application data, ransomware encryption, or a failed patch — all of which damage the VM's data rather than the host hardware.
A dedicated FusionCompute VM backup solution restores to a specific point in time, independent of production storage. It lets admins roll back after a bad update or recover one deleted file without a full restore. Regulatory retention in finance and government also demands scheduled, provable recoverability.
Backup also enables migration and testing. You can restore a verified copy to an isolated sandbox and apply a risky patch there before touching production. You can also convert VMs to another platform during a migration project.
A sound strategy follows the 3-2-1 backup rule: keep three copies of data, on two different media, with one copy offsite. This protects against storage failure, site-wide disaster, and ransomware that specifically targets backup copies.
Finally, backup protects business continuity. Restoring a critical VM in minutes, rather than hours, is often the difference between a minor incident and a costly outage.
Key Challenges of Huawei FusionCompute Backup
Six platform-specific traits make FusionCompute backup harder than a generic KVM checklist suggests. Understanding each one is essential before you evaluate any backup tool.
Changed-block tracking can fail silently
FusionCompute's CBT works through eBackup on top of snapshots, but it is not available on every disk type. On preallocated (thick) and linked-clone disks, CBT can be unavailable or unreliable. Incremental jobs then degrade into full-disk scans, and backup windows balloon until they collide with production hours.
Raw device mapping (RDM) disks. FusionCompute maps a physical LUN directly to a VM, bypassing the VIMS file layer, so ordinary snapshot-based backup cannot capture them. Without explicit RDM support, these VMs stay unprotected.
Local-storage VMs complicate restores
Many clusters use host local disks instead of a shared SAN. When VM data lives on one CNA's local disks, backup must read it consistently, and restores must target the correct host.The VRM node itself needs protection. VRM is the cluster's single management brain. Losing it without a recovery path means losing the ability to manage every VM, even if the VMs still run.
Application consistency
SQL Server and Oracle running inside FusionCompute VMs need application-aware quiescing before a snapshot is taken. A crash-consistent-only backup can restore a database that fails integrity checks, so database-aware protection is not optional.
Scale and management overhead
Large clusters generate many backup jobs and restore points. Without centralized control and scalable storage, protecting hundreds of VMs becomes an operational burden that grows with the cluster.
Three Common Methods to Protect Huawei FusionCompute
There are three ways to protect FusionCompute workloads, each with a different risk profile. The right choice depends on your recovery-point and recovery-time targets.
Method 1: Native Snapshots
FusionCompute snapshots, taken through the VRM portal, are fast and useful for short-term rollback before a patch or upgrade.
But snapshots are not backups. They live in the same data store as the VM, so a storage failure destroys both. They also consume the same capacity and degrade I/O as chains grow.
Reserve snapshots for pre-change rollback. They are never a substitute for a scheduled, offsite backup.
Method 2: Export VMs (Templates / OVA)
FusionCompute can export a VM as a template for offline copies and migration. This suits archiving a few golden images or moving workloads between sites.
The drawback is operational. Export is manual and offline, there is no incremental export, and restore requires manual re-import. It cannot scale to hundreds of VMs.
Export produces a portable template or OVA. It fits occasional golden-image copies, but it cannot automate daily protection or meet strict recovery targets.
Method 3: Third-Party Backup Tool
A dedicated FusionCompute backup tool is the only method that delivers automation, incremental efficiency, granular restore, and FusionCompute disaster recovery together.
The right tool is agentless and protects at the hypervisor level. It adds reliable change detection that works even where native CBT fails. Huawei eBackup is also an option, but certified third-party tools add instant recovery and cross-platform migration.
A certified tool also centralizes management. One web console controls backup jobs, restore points, and retention across the whole cluster.
Common Huawei FusionCompute Backup Selection Mistakes
Most failed FusionCompute backup projects trace back to a small set of avoidable errors.
Treating HA or snapshots as backup
Teams assume high availability means data is safe. They later discover that HA and snapshots restore neither the right data nor the right point in time.
Assuming CBT always works
Relying on native CBT without a fallback means thick and linked-clone VMs silently lose incremental efficiency, and backup windows grow.
Ignoring RDM and local-storage VMs
If the vendor cannot explain how it handles these workloads, they will be left out of the protection scope — often discovered only during a restore test.
Forgetting the VRM node
Protecting only the VMs means the platform may be unrecoverable after a disaster, even if the VM data survives.
Skipping restore verification
A backup that has never been tested is a guess, not a guarantee. Schedule regular recovery drills to confirm restores actually work.
Core Requirements of Huawei FusionCompute Backup Software
When evaluating a FusionCompute VM backup solution, require these capabilities. Each one maps to a challenge described above.
| Feature / Requirement | Why It Matters |
|---|
| Official Huawei ecosystem support
| Look for a Huawei ISV partner or verified FusionCompute compatibility. This is the strongest signal that the tool was actually tested against the platform. |
| Agentless, API‑based architecture
| Backup should run at the hypervisor level through FusionCompute's APIs, with no agent inside each VM. This avoids per‑VM install, maintenance, and reboot overhead. |
| Reliable change detection with a fallback
| The tool must keep incremental jobs fast even where native CBT is unavailable, for example on preallocated thick disks. |
| RDM and local‑storage support
| Confirm that raw device mapping disks and VMs on local storage can be protected and correctly restored to the right host. |
| Instant and granular recovery
| Instant VM recovery mounts backup storage and restores a VM in seconds, while granular recovery pulls a single file from any restore point. |
| Cross‑platform migration
| The ability to restore a FusionCompute VM to VMware or another hypervisor protects against platform lock‑in and supports migration projects. |
| Application‑aware backup
| Support for SQL Server and Oracle quiescing keeps database restores transactionally consistent and recoverable. |
| Data security and immutability
| Encryption in transit and at rest, plus tamper‑proof retention, defends backups against ransomware and unauthorized changes. |
| Defined RPO/RTO and scalability
| The tool must meet your recovery targets through frequent incremental jobs and instant restore, and scale out by adding backup nodes under one console. |
How Vinchin Addresses Huawei FusionCompute Backup Challenges
Vinchin Backup & Recovery is a Huawei ISV partner and a winner of the Huawei Kunpeng Application Innovation Competition. It closes each FusionCompute-specific gap directly.
Vinchin supports over 15 hypervisors, including FusionCompute, VMware, and Proxmox. This breadth matters for organizations running a mixed virtualized estate.
Reliable change detection beyond native CBT
Vinchin performs agentless incremental backup on FusionCompute. Its advanced data-extraction technology works even when CBT is invalid, excluding swap blocks, deleted-file blocks, and partition gaps.
RDM and multi-disk handling
Vinchin supports the disk types native snapshots struggle with. It also lets you exclude specific disks from a multi-disk VM to cut bandwidth and storage.
Instant and granular recovery
Instant VM Recovery mounts backup storage over NFS and resumes the VM in about 15 seconds. Granular Restore downloads individual files without a full VM restore.
VRM and cluster-wide protection
Because Vinchin backs up at the hypervisor level, it can protect the VRM node like any other VM, keeping the management plane recoverable.
Storage and DR depth
Deduplication, compression, and BitDetector strip swap files and partition gaps. Offsite copy and cloud archiving satisfy the 3-2-1 rule, and cross-platform restore converts FusionCompute VMs to VMware.
Data security
Vinchin encrypts backup data in transit and at rest. Its storage-protection blocks unauthorized modification, defending backups against ransomware and tampering.
Forever-incremental backup and GFS retention
A single full backup followed by endless incrementals saves time and storage. GFS retention policies then control restore-point lifecycles for long-term compliance.
Scale-out and visibility. Backup node expansion, multi-tenant management, and the DataV dashboard support large clusters and cloud providers that need isolated tenant backup services.
Huawei FusionCompute versions supported by Vinchin: 6.5.1, 8.0, 8.5, 8.6, 8.7, 8.8
FAQ
Q1: Why does my FusionCompute incremental backup run as a full scan?
A1: Native changed-block tracking (CBT) can be unavailable on thick and linked-clone disks. Choose a solution with a change-detection fallback that keeps incrementals fast.
Q2: Can Vinchin back up RDM disks in FusionCompute?
A2: Yes. Vinchin handles the disk types that snapshot-based backup cannot cover, and it can exclude unneeded disks from a multi-disk VM to save bandwidth and storage.
Q3: Can I restore a FusionCompute VM to VMware?
A3: Yes. Vinchin performs cross-platform recovery (V2V), converting a FusionCompute VM to VMware or other supported hypervisors while preserving data consistency.
Q4: Can Vinchin restore VMs that live on local storage?
A4: Yes. Vinchin reads local-storage VMs consistently through the hypervisor and restores them to the correct CNA host, just like VMs on shared SAN storage.
Q5: Can Vinchin back up databases inside FusionCompute VMs?
A5: Yes. Vinchin adds application-aware protection for SQL Server and Oracle, quiescing the database before the snapshot so restores are transactionally consistent.
Conclusion
Choosing reliable Huawei FusionCompute backup software comes down to four checks: verified Huawei ecosystem support, a CBT fallback, correct RDM and local-storage handling, and VRM protection. These four checks map directly to the platform's native limitations.
Native snapshots and VM export cover only part of the need. A certified third-party tool delivers automation, granular restore, and FusionCompute disaster recovery together. Vinchin meets all four criteria as a Huawei ISV partner with documented version coverage. This makes it a dependable choice for protecting Huawei FusionCompute virtual machines.
