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

The procedure for recovering a backup to a new VM is as follows:

1. Obtain the VM configuration from the backup.
2. Modify the configuration, including group, run location, datastore, and NIC.
3. Call the VM creation API to create VM A based on the VM configuration in the backup.
4. If a BIOS file exists, call the file upload API to recover the BIOS file.
5. If a TPM file exists, call the file upload API to recover the TPM file.
6. Call the backup resource creation API to lock VM A with the type set to "Recovery" for backup recovery.
7. Recover data of all disks. The processing workflow for each transport mode is as follows:

(1) NBDSSL (including NBD) transport mode:

The third-party backup app writes backup data to virtual disks by calling SFVDDK interfaces. The 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 recover the disk until all disks are recovered:

a. Call the SFVDDK open interface to open disk D.

b. Call the SFVDDK write interface to write the backup data to disk D.

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.

B. Power on the backup proxy VM.

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

a. Hot-add 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 hot-add disk D of VM A to the backup proxy VM in Virtio mode. At this time, disk D is added to both VM A and the backup proxy VM. The input parameter description for the new disk is as follows:

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

• application_type: Set to "hotadd".

• id: Must not overlap with the IDs of existing disks of the backup proxy VM.

• 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, confirm the new disk through the disk serial number N and obtain its device path P.

b. Write disk data: In the Guest OS of the backup proxy VM, the backup app directly writes the backup data to the device path P (i.e., disk D) until the disk data recovery is completed.

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 (at this time, disk D is only added to VM A).

8. D. Power off the backup proxy VM (optional).
9. Release backup resources.
10. Power on VM A (optional).

Note:

1. Data can be recovered only when the VMs are shut down.
2. Data can be recovered only to the destination HCI with the same architecture, such as x86 and Arm, as the original HCI.
3. Third-party backup vendors need to add, delete, or modify parameters if data is recovered to a different HCI version.
4. You are advised to create disks in thin provisioning mode or dynamic provisioning mode, as creating disks in pre-allocating mode is time-consuming.