{{ $t('productDocDetail.updateTime') }}: 2026-04-29

The procedure for creating a backup is as follows:

1. Call the VM status query API to obtain the status of VM A. VMs can be backed up only when they have no ongoing tasks and are running or shut down.
2. Call the snapshot creation API to take snapshot S for VM A.
3. Call the snapshot details query API to query information (including checkPointID) and VM configuration (used for backup) of snapshot S.
4. Call the backup resource creation API to lock VM A with the type set to "Backup" for agentless backup.

Note: In the SCP&HCI 6.11.3 version, the APIs and related mechanisms for backup resources are as follows:

• The API for creating backup resources supports setting host_id (preferred running host): When creating, a list of hosts that support running will be filtered first (these hosts must be able to access all disks of VM A); if host_id is in this list, this host is selected; if not, the host with the least number of backup resources is selected from the list.

• The API for querying backup resources supports obtaining the actual running host’s host_id of the backup resource.

• The API for obtaining backup resource overview can obtain the number of backup resources running on each host.

5. Start a thread to periodically call the API for querying backup resources to obtain the remain_time (remaining time) of the backup resource. When detecting that the value of remain_time is small, call the API for updating backup resources to update the remain_time of the backup resource. Note: When remain_time < 0, the cloud platform will automatically delete the backup resource and terminate the current backup task. This mechanism is used to preventing VM A from becoming unavailable after the third-party backup software remains unresponsive for a long time.
6. Call the CBT bitmap query API to obtain the areas to be backed up in each disk.

(1)For the first backup, pass in checkPointID = 0 to perform a full backup. Then, areas to be backed up with valid data are returned.

(2)For subsequent backups, pass in the value of checkPointID from the previous backup to checkPointID to query changed data between the previous snapshot and this snapshot.

7. Check whether a custom BIOS file is used based on the VM configuration in the snapshot.

(1)If so, call the file download API to download the BIOS file and back it up.

(2)If not, do not back up the BIOS file.

8. Check whether TPM is enabled based on the VM configuration in the snapshot.

(1)If so, call the file download API to download the TPM file and back it up.

(2)If not, you can also call the file download API to download the TPM file. If the VM has no TPM file, an error will be reported.

9. Start backing up the changed data of all disks. The processing workflow for each transport mode is as follows:

(1) NBDSSL (including NBD) transport mode:

The backup app reads disk snapshot data by calling SFVDDK interfaces. The specific workflow is as follows:

A. Call the SFVDDK connect interface to establish a connection with SCP or HCI.

B. For each disk D of VM A, perform the following steps to back up until all disks are backed up:

a. Call the SFVDDK open interface to open the snapshot S of disk D.

b. Call the SFVDDK read interface to read disk data, and read the backup data from disk D to complete the backup.

c. Call the SFVDDK close interface to close disk D.

C. Call the SFVDDK disconnect interface to disconnect from SCP or HCI.

D. In case of abnormal termination, call the SFVDDK cleanup interface to clean up residual resources.

(2) HotAdd transport mode:

A. Select a backup proxy VM that can access all disks of VM A (i.e., the HCI host where backup proxy VM runs can access the storage where each disk of VM A is located):

a. Call the API for obtaining VM configuration information to get the storage where the disks of VM A are located; if multiple disks of VM A are distributed across different storages, obtain the corresponding storage list SL.

b. Call the API for querying storage lists to obtain the list of HCI hosts mounted to the storages, and further filter out the host list HL (HL must include hosts that mount all storages in the storage list SL).

c. Select a backup proxy VM on any host from HL; this backup proxy VM can access all disks of VM A.

B. Ensure that the backup proxy VM is powered on. Call the API for starting VMs to power on the backup proxy VM.

Note: Only when the backup proxy VM is running can the disks of VM A be hot-added to this host; when the backup proxy VM is powered off (including reboot), the already hot-added disks will be automatically deleted.

C. For each disk D of VM A, perform the following steps to back up until all disks are backed up:

a. Hot-add the linked clone disk of snapshot S of disk D to the backup proxy VM:

① Call the Create VM disks API to hot-add a disk to the backup proxy VM. The cloud platform will automatically create a linked clone image of snapshot S of disk D of VM A and hot-add it to the backup proxy VM in Virtio mode. The input parameter description for the new disk is as follows:

• snapshot_id: Set to snapshot S.

• disk_id: Set to the disk_id of disk D (obtainable from the configuration information of VM A or the details of snapshot S).

• application_type: Set to "hotadd".

• id: Must not overlap with the IDs of existing disks of the backup proxy VM (e.g., ide0, ide1... iden).

• size_mb: Set to the size of disk D.

• preallocate: Set to "off".

• type: Set to "new_disk".

② Call the API for obtaining VM configuration to get the serial number N of the above hot-added disk (confirmed by the disk’s id) from the backup proxy VM configuration.

③ In the Guest OS of the backup proxy VM, use the disk serial number N to confirm the above new disk and obtain its device path P (used for data reading in the next step); for example, in Ubuntu, P is "/dev/disk/by-id/virtio-{N}".

b. Read disk data: In the Guest OS of the backup proxy VM, the backup app directly reads data from the disk device path P and completes the backup.

c. Delete the hot-added disk: Call the VM disks action API to delete the disk. The cloud platform will remove the hot-added disk from the backup proxy VM and delete the linked clone image of snapshot S of disk D of VM A.

D. Power off the backup proxy VM: If the backup proxy VM has no other backup or recovery tasks to perform, call the API for stopping VMs to power off the VM to release cluster resources (this step is optional).

10. Call the backup resource deletion API to release backup resources.

11. Call the snapshot deletion API to delete snapshot S.

Note:

1. The third-party backup software should create an obvious description to indicate that the snapshot is automatically created during the backup. Example: Automatically created by a third-party backup software. Do not delete it.
2. A validity period can be set for a backup resource to be created. If the validity period ends, HCI can cancel the backup.
3. VM templates, NFV VMs, component-based VMs, placeholder VMs, VMs with Turbo mode enabled, and backup proxy VMs do not support backup. Do not perform a backup before these VMs are filtered out during the VM list query. Otherwise, an error will be reported.
4. Only disks in qcow2 format are supported to agentless backup and recovery. If physical disks (including Oracle RAC shared disks), USB disks, virtual shared disks (including VS storage, iSCSI storage, and FC storage), and other disks are mounted to VMs, third-party backup vendors should skip these disks, as opening them will generate an error.
5. iSCSI and NAS disks mounted to VMs do not support backup.
6. For encrypted VMs, the data read during backup is ciphertext (including NBDSSL and HotAdd transport mode) and can only be used to overwrite data of the original VM in the original cluster.
7. It may require several queries to return all the CBT bitmap data.
8. Third-party backup vendors are responsible for clearing their snapshots, even if errors occur. The API for creating VM snapshots supports the lifespan parameter (i.e., snapshot expiration time, in seconds): If a third-party fails to clean up the snapshot due to an exception and the snapshot exists for longer than the lifespan, the cloud platform will automatically clean up the snapshot.
9. Third-party backup tasks may be canceled or terminated due to issues on SCP and can be tried again next time.
10. Disks can be specified for third-party backup and recovery, and CBT needs to be enabled only for these disks, as enabling CBT will affect the write performance of a disk.
11. When the backup proxy VM is powered off (including reboot), the already hot-added disks will be automatically deleted; Third-party backup tasks need to try again next time.
12. The maximum number of disks that can be hot-added to a backup proxy VM at the same time is limited by the maximum number of disks that a VM can add. If this limit is exceeded, third parties need to back up disks in batches.
13. The maximum number of disks supported by VMs in different HCI versions is as follows: HCI 6.10 series supports a maximum of 16 disks, and HCI 6.11 series and later versions support a maximum of 64 disks.