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

A base image is a public image on which multiple VMs can build their own system disks. There are two ways to create a VM from an image:(1) The system disk image of the VM is a full copy of the base image;(2) The system disk image of the VM is a newly created empty image linked to the base image. The changed data during the operation of the VM will be written to the system disk image, while the base image will not be modified. Such VMs are called linked VMs.

A linked VM takes the public base image as its underlying disk and relies on the base image for startup and operation. Only when data changes occur will the changes be recorded and redirected to the VM’s own system disk image.

Linked VMs have the following advantages:

• Since the base image is pre-imported, the deployment of a linked VM can be completed quickly.

• One base image can be used to derive multiple linked VMs. Each linked VM only needs to store its own incremental data, thus saving storage space.

When backing up and restoring linked VMs, additional processing related to the base image is required:

• During backup, it is necessary to back up the custom attributes and custom attribute binding relationships associated with the base image, as well as the base image disk data.

• During restoration, If the base image does not exist, the image needs to be created, and the custom attributes, custom attribute binding relationships, and base image disk data associated with the base image need to be restored. If the base image does not exist on the target storage, a replica of the base image needs to be synchronized to the target storage; that is, a replica of the base image needs to be created on the target storage.

When creating a VM from an image on the SCP, select the Linked Deployment to create a linked VM.

Figure 4‑1 Linked VM is created based on a base image

4.5.1Base Image Backup

1)To determine whether a VM is a linked VM, you can query whether the VM contains a base image via the OpenAPI for obtaining VM snapshot details:

SCP OpenAPI: GET /janus/20240725/servers/{server_id}/snapshots/{id}

If there is a disk containing the base_image_id field in the vmconf.hardware_option.disks array, the VM has a base image,where base_image_id uniquely identifies a base image.

2)Obtain and back up the base image details (including base image metadata):

SCP OpenAPI: GET /janus/20180725/base-images

The information of the target base image needs to be filtered from the result.Note: Filter parameters can be set in the request to query only the information of the specified base image.

3)Obtain and back up the custom attribute binding information, including the custom attributes bound to the base image:

SCP OpenAPI: GET /janus/20190725/custom-attributes/bindings

The custom attributes and custom attribute details bound to the base image need to be filtered from the result.

4)For linked VMs, query the CBT incremental bitmap of the system disk and the CBT incremental bitmap of the base image separately.

Note: When enabling or resetting CBT for a VM, use the new version API:PUT /janus/20240725/servers/{server_id}/cbt/status.

Use SCP OpenAPI to query the CBT bitmap:GET /janus/20240725/servers/{server_id}/cbt/changed-areas

• Query system disk CBT bitmap:base_image = 0, checkpoint_id = the checkpoint_id from the last backup.

• Query base image CBT bitmap:base_image = 1, checkpoint_id = 0.

Note: Only full backups back up base image disk data. Incremental backups do not need to back up base image disk data, since the base image disk data remains unchanged.

5)After obtaining the CBT bitmap of the base image, back up the base image disk data according to the steps in Section 3.4.The backup of system disks and data disks is consistent with Section 3.4.Both HotAdd mode and NBDSSL (including NBD) mode require processing:

• HotAdd mode:When using SCP OpenAPI: PUT /janus/20250725/servers/{server_id} to hot-add the system disk of the VM,set disks.open_base_image to 1 to indicate adding the base image disk; otherwise, it indicates adding the system disk.

• NBDSSL mode (including NBD):When opening the system disk of the VM using sfdisklib_open from sfvddk,if the flags include SFDISKLIB_FLAG_OPEN_BASE_IMAGE, it indicates opening the base image disk; otherwise, it indicates opening the system disk.

4.5.2Base Image Recovery

1)Verify whether the base image needs to be restored:

Use SCP OpenAPI: GET /janus/20180725/base-images to query base image information in the target resource pool:

• If the base image does not exist, the base image needs to be restored.

• If no replica of the base image exists on the target storage for restoration, synchronize the base image replica.

2)Restore the base image: create the base image first, then update its status:

• Use SCP OpenAPI: POST /janus/20180725/base-images to create the base image.

• Use SCP OpenAPI: PUT /janus/20180725/base-images/{baseimage_id} to update the base image status to AVAILABLE.

3)Restore base image disk data. Both HotAdd mode and NBDSSL mode (including NBD) require separate handling:

• HotAdd mode: When hot-adding a VM system disk using SCP OpenAPI: PUT /janus/20250725/servers/{server_id}, set disks.open_base_image to 1 to indicate adding the base image disk.

• NBD mode (including NBDSSL): When opening a VM system disk using sfvddk sfdisklib_open, the flags must include SFDISKLIB_FLAG_OPEN_BASE_IMAGE to indicate opening the base image disk.

4)If the base image exists but has no replica on the target storage, synchronize the base image replica to the target storage:

Use SCP OpenAPI: POST /janus/20180725/base-images/{base_image_id}/replicas/actions/sync to synchronize the base image replica.

5)Verify whether base image custom attributes need to be restored:

Use SCP OpenAPI: GET /janus/20190725/custom-attributes/bindings to query custom attribute binding relationships.

• If the custom attributes associated with the base image exist and are bound to the base image, no restoration is required.

• If the custom attributes associated with the base image do not exist, create the custom attributes.

• If the custom attributes associated with the base image exist but are not bound to the base image, bind the base image and the custom attributes.

6)Create custom attributes:

Use SCP OpenAPI: POST /janus/20190725/custom-attributes to create custom attributes.

7)Bind the base image and custom attributes:

Use SCP OpenAPI: POST /janus/20190725/custom-attributes/bindings/actions/bulk-create to bind the base image and custom attributes.

4.5.3Backup/Recovery Limitations of Linked VMs

1)Version requirement: The logic for separate backup of base images is only supported in SCP 6.11.3 and later versions.

Note: When enabling or resetting CBT for a virtual machine, use the new API:

PUT /janus/20240725/servers/{server_id}/cbt/status.

2) For disks associated with a base image, query the CBT incremental bitmap of the system disk and the CBT incremental bitmap of the base image separately.

Query the CBT bitmap using the SCP OpenAPI:

GET /janus/20240725/servers/{server_id}/cbt/changed-areas

• Query system disk CBT bitmap:base_image = 0, checkpoint_id = the checkpoint_id of the last backup.

• Query base image CBT bitmap: base_image = 1, checkpoint_id = 0.

3) When the HCI version is lower than 6.11.3, non-desktop-cloud linked VMs do not support separate base image backup, because the CBT bitmap of their system disk image already includes the base image CBT bitmap.You can query whether a VM is a desktop-cloud VM via the OpenAPI for obtaining VM configuration details or list:

SCP OpenAPI: GET /janus/20250725/servers/{server_id}

SCP OpenAPI: GET /janus/20250725/servers

When the value of the `application` field is "desk", the virtual machine is a desktop-cloud virtual machine.

4) Desktop-cloud VMs may also be linked VMs, but their backup logic varies across scenarios:

• A desktop-cloud VM may be in revert mode, in which case agentless backup is not supported.You can query whether a VM is a desktop-cloud virtual machine in revert mode via the OpenAPI for obtaining VM configuration details or list:

SCP OpenAPI: GET /janus/20250725/servers/{server_id}

SCP OpenAPI: GET /janus/20250725/servers

When the value of the `revert_mode` field is 1, the VM is a desktop-cloud virtual machine in revert mode.

• When the HCI version is lower than 6.11.3, desktop-cloud VMs still support separate base image backup.However, the base image CBT bitmap cannot be queried via the CBT bitmap API; only full base image data backup is supported

(when backing up via sfvddk, set the data read range to the full disk capacity).

• When the HCI version is 6.11.3 or later, desktop-cloud VMs behave the same as ordinary linked VMs,and base image data can be backed up using the CBT bitmap method.

5) Base image backup is only required during full backup of linked VMs; it is not required during incremental backup.

6) The base image ID is the unique identifier of the base image.The base image ID changes when the base image data is modified.Therefore, the same base image only needs to be backed up once in the entire backup system.At the same time, considering that the backup system storage may fail and render the base image unavailable,it is recommended to back up the base image regularly.

7) Linked VMs do not support quick recovery.

8) If a base image data restoration task is abnormally interrupted, the base image data is incomplete and cannot be used.The base image must be deleted after the task fails.Misuse of this incomplete base image may cause the virtual machine to fail to boot.

9) Linked VMs are subject to special restrictions and do not allow system disk deletion. Therefore, during overwrite restoration, the system disk data can be erased by using the OpenAPI for restoring the cloud host to its base image:

SCP OpenAPI:POST /janus/20240725/servers/{server_id}/recovery-baseimage