What is InCloud Sphere?
InCloud Sphere is a server virtualization platform developed by Inspur (Jinan Inspur Data Technology). It is built on a deeply customized QEMU-KVM hypervisor and targets enterprise private clouds, edge computing, and hyper-converged infrastructure.
The platform uses a two-tier control architecture. iCenter is the management node that provides the web console, REST APIs, and orchestration. iNode is the compute node that runs virtual machines. On top of these, three virtualized services abstract physical resources. ICSCompute handles CPU and memory, ICSStorage provides a cluster file system, and ICS Network delivers software-defined networking with a built-in Neutron module.
A single iCenter can manage up to 1,024 hosts, 32 clusters, and 10,240 VMs. Each VM supports up to 128 vCPUs, 55 virtual disks, and 16 NICs. The platform runs on heterogeneous hardware through its "one cloud, multiple chips" design, mixing x86 and ARM processors from Hygon, Zhaoxin, Kunpeng, Phytium, and Loongson.
Why Do You Need to Back Up InCloud Sphere
High availability is not backup. InCloud Sphere ships HA, live migration, DRS, and DPM. These features keep workloads running when a host fails, but they do not protect against logical corruption, accidental deletion, ransomware, or a site-wide disaster.
| Threat | Impact on InCloud Sphere | Protection gap left by HA |
|---|
| Ransomware | Encrypts VM disks and snapshots | HA restarts infected VMs, it does not restore clean data |
| Human error | Deletes a VM, disk, or protection group | HA replicates the mistake instantly |
| Storage corruption | Damages a CFS or LUN pool | HA fails over to the same corrupted data |
| Site failure | Loses an entire data center | HA is single-site by design |
| Compliance | Requires long-term retention and audit | HA provides no historical restore points |
Backups close these gaps. They give you point-in-time restore points, air-gapped copies, and the ability to meet RPO and RTO targets. For industries such as finance, healthcare, and government, where InCloud Sphere is widely deployed, a documented backup strategy is also a regulatory requirement.
Core InCloud Sphere Backup Strategies
Start with the classic 3-2-1 rule: keep three copies of data, on two media types, with one off-site. In an InCloud Sphere deployment, this often means a native backup pool on primary storage, a secondary copy on a backup appliance, and a third copy in object storage or a remote site.
Define RPO and RTO before choosing tools. RPO is the maximum acceptable data loss; RTO is the maximum downtime. A tiered approach maps workloads to protection levels.
| Workload tier | Example | Recommended protection | Typical RPO / RTO |
|---|
| Tier 1 (critical) | Databases, ERP, core banking | CDP or 15-minute incremental + SRM | Seconds / minutes |
| Tier 2 (business) | Application servers, middleware | Hourly CBT incremental | Hours / hours |
| Tier 3 (standard) | Test, dev, file servers | Daily incremental, weekly full | 24 h / hours |
Combine native protection with a third-party tool. Use InCloud Sphere's built-in snapshot and CBT features for fast local recovery. Add an external backup platform such as Vinchin for deduplication, compression, air-gapped copies, and cross-platform restore.
Retention should follow the GFS model (grandfather-father-son). Keep daily restore points for one to two weeks, weekly points for one to two months, and monthly points for a year or more. Align retention with compliance requirements such as MLPS 2.0 in China, which InCloud Sphere environments commonly follow.
Finally, test restores on a schedule. An untested backup is a hope, not a recovery plan. Automate a quarterly restore drill for one VM from each protection tier and log the result.
How InCloud Sphere Backup Works
InCloud Sphere provides several native data-protection mechanisms, each with a distinct role in the backup pipeline.
Snapshots
A snapshot captures the point-in-time state of a VM's disks and configuration. InCloud Sphere supports up to 32 snapshots per VM, with instant creation and batch deletion that does not degrade VM I/O. Snapshots use copy-on-write, so the initial snapshot is fast, but chains grow long if retained indefinitely.
CBT (Changed Block Tracking)
Introduced in V6.0, CBT records only the blocks that changed since the last backup. It works across raw, qcow2, and raw-device disk formats. Because CBT skips unchanged blocks, incremental backups are dramatically faster and impose near-zero load on the running VM.
CDP (Continuous Data Protection)
The platform's recorder feature captures I/O-level changes continuously. Unlike snapshots, CDP lets you roll a VM back to any I/O state before a failure, not just to a scheduled point. It is the strongest native option for RPO measured in seconds.
Backup storage pools
Administrators can designate a dedicated storage pool to hold backup data. This isolates backup writes from production I/O and lets you place copies on slower, cheaper disk.
VVDK
Inspur ships a disaster-recovery development kit modeled on VMware's VDDK. Third-party backup vendors use VVDK to read and write VM data through a standardized interface, which is how tools like Vinchin achieve efficient, consistent backups without in-guest agents.
Common InCloud Sphere Backup Methods
There is no single "best" method. Each approach below trades simplicity, performance, and recoverability differently.
| Method | Mechanism | Pros | Cons |
|---|
| Native snapshot | Copy-on-write point-in-time capture | Instant, no external tool | Limited to 32, chain-based, not a true backup |
| Native VM backup | Built-in scheduled job to a backup pool | No extra license, simple | Basic scheduling and retention |
| CBT incremental | Changed-block tracking since last point | Fast, low overhead | Depends on a healthy full baseline |
| CDP | Continuous I/O-level journaling | Second-level RPO | Higher storage and CPU cost |
| Third-party (Vinchin) | Agentless via VVDK/iCenter | Dedup, compression, GFS, DR orchestration | Requires a backup server |
Native snapshot and backup jobs are ideal for day-to-day local recovery. Use CDP for tier-1 systems where losing even a minute of transactions is unacceptable. Reserve CBT incremental for high-volume VMs with large disks, where full scans would exceed the backup window.
A common hybrid design runs native snapshots every few hours, CBT incremental backups daily, and a full backup weekly. The full baseline resets the incremental chain and protects against chain corruption.
Best Practices of InCloud Sphere Backup
Follow these operational rules to keep backups reliable and recoverable.
Separate backup storage from production. Direct backups to a dedicated backup pool or external target. Never store backups on the same LUN or CFS pool as the source VM.
Use CBT for large disks. For VMs with multi-terabyte qcow2 or raw-device disks, CBT incremental keeps backup windows short and avoids production I/O contention.
Cap snapshot depth. Do not let snapshot chains approach the 32-snapshot limit. Delete and re-create chains after major changes to prevent performance degradation.
Enable CDP only where needed. CDP consumes storage and CPU. Apply it selectively to databases and transaction systems, not to every VM.
Encrypt and air-gap copies. Enable encryption on backup transfer, and keep one copy immutable or offline to survive ransomware that targets the backup server itself.
Monitor backup jobs. Configure the platform's alarm system to alert on failed jobs. A silent failure is worse than no backup because it creates false confidence.
Document restore procedures. Write step-by-step runbooks for full-VM restore, file-level restore, and CDP rollback, including who is authorized to execute them.
InCloud Sphere Restore & Disaster Recovery Guide
Restore options in InCloud Sphere map to the protection methods you deployed.
Snapshot revert. Roll a VM back to a snapshot from the VM management page. This is the fastest fix for a bad patch or configuration change, but it reverts the whole VM.
Backup restore. Restore a VM or individual disks from a backup storage pool. You can restore to the original host or to a different iNode, which supports migration and hardware-refresh scenarios.
Recycle bin. Accidentally deleted VMs land in the platform's recycle bin, where they can be recovered without a backup. Confirm retention on this bin matches your operational needs.
CDP rollback. Select any recorded I/O point and restore the VM to that exact state. This is the go-to for logical corruption and ransomware, where reverting to the last consistent state is critical.
For cross-site resilience, InCloud Sphere offers SRM (Site Recovery) with protection groups. SRM replicates protected VMs at the virtualization layer using volume replication, achieving second-level RPO and minute-level RTO. Protection groups bundle VMs that fail over together, which is essential for multi-tier applications with boot-order dependencies.
The platform also supports an active-active stretched-cluster mode for same-city dual-site deployments. In this model, a mirrored storage pool survives the loss of either site without manual failover. Combine it with SRM for a true multi-layered continuity design.
Common InCloud Sphere Backup Issues & Troubleshooting
| Symptom | Likely cause | Resolution |
|---|
| Snapshot creation fails | Snapshot chain at 32-snapshot limit | Delete old snapshots or consolidate the chain |
| Incremental backup is slow | CBT baseline lost, full rescan triggered | Re-run a full backup to rebuild the baseline |
| Backup job reports full after minutes | Backing up unchanged data | Confirm CBT is enabled for the disk format |
| Restore hangs on large VM | Backup target I/O bottleneck | Move backup pool to faster storage or restore to a closer host |
| CDP consumes excessive storage | Journal grows during high write load | Tighten CDP retention or narrow the protected VMs |
| Backup fails on raw-device disk | Incompatible snapshot path | Use a VVDK-based third-party tool that supports raw LUNs |
| iCenter unresponsive during backup | Management node overloaded | Schedule backups off-peak or deploy iCenter HA (dual-node hot standby) |
Always check the platform's task and event log first. InCloud Sphere records every backup, snapshot, and restore as a task with a detailed event trail. Correlate the timestamp with the failure to isolate whether the fault is in the hypervisor, storage, or network path.
How Vinchin Protects InCloud Sphere
Vinchin Backup & Recovery is an agentless backup platform that integrates with InCloud Sphere through the iCenter and VVDK interface. It supports a wide range of Inspur InCloud Sphere KVM (ICS) versions, from V5R06 through V6R15, including aarch64 builds.
The agentless design means no software is installed inside each guest, which keeps VMs clean and reduces management overhead. Backup jobs run at the host level, reading VM data through VVDK for consistent, efficient transfer.
Vinchin adds capabilities the native tool lacks: global deduplication and compression to shrink backup storage, GFS retention for long-term archive, and transmission encryption. Its incremental and differential schedules pair with CBT for short backup windows.
During restore, Vinchin supports full-VM restore, granular file-level recovery, and instant recovery that mounts a backup point as a running VM in seconds.
A standout feature for InCloud Sphere is the option to preserve a VM's original MAC address on restore. Many applications bind licenses or configurations to a MAC address; preserving it avoids re-activation and reconfiguration after recovery.
Finally, Vinchin can tier backup copies to public cloud object storage such as AWS, Azure, Alibaba Cloud, or Tencent Cloud. This satisfies the off-site leg of the 3-2-1 rule without building a second data center.
Step 1: Select the InCloud Sphere VM to back up
Step 2: Choose the backup storage
Step 3: Configure the backup strategy
Step 4: Submit the job
Recognized globally with top ratings among enterprise users worldwide, Vinchin Backup & Recovery offers a fully featured 60-day free trial. Click below to experience trusted data protection firsthand.
FAQ
Q1: Does InCloud Sphere have built-in backup?
A1: Yes. It includes native VM backup jobs, snapshots, CBT, CDP, and a dedicated backup storage pool, plus SRM for site-level disaster recovery.
Q2: How many snapshots can one InCloud Sphere VM hold?
A2: Up to 32 snapshots per VM, with instant creation and batch deletion that does not affect running VM I/O.
Q3: What is the difference between CBT and CDP in InCloud Sphere?
A3: CBT tracks changed blocks for efficient scheduled backups. CDP journals I/O continuously for second-level RPO and rollback to any point in time.
Q4: Can I restore an InCloud Sphere VM to a different host?
A4: Yes. Backup restore lets you target a different iNode, and Vinchin supports cross-host and even cross-platform restore.
Q5: Is agentless backup available for InCloud Sphere?
A5: Yes. Tools such as Vinchin connect through iCenter and VVDK, so no in-guest agent is required.
Conclusion
InCloud Sphere is a capable KVM-based virtualization platform, but capability is not protection. A production-grade backup strategy layers native snapshots, CBT incremental, and CDP with an external platform for deduplication, air-gapped copies, and orchestrated disaster recovery.
Define RPO and RTO per workload tier, follow the 3-2-1 rule, cap snapshot chains, and test restores regularly. With the right mix of native features and a tool like Vinchin Backup & Recovery, InCloud Sphere environments can meet second-level RPO and minute-level RTO targets — turning backup into a true business-continuity asset.
