Adaptive backup and recovery method for cloud host service system disk

Abstract

The application provides a cloud host service system disk adaptive backup and recovery method. When the backup task is started, the operating system type information of the target cloud host service is obtained, and the image export backup path or the mounting backup path is adaptively selected, so that the two types of system disks can complete the backup through the adaptive path. For the mounting backup path, the auxiliary recovery information is synchronously obtained and written into the extended attribute of the backup file during the execution of the backup, so that the block data file can be successfully imported as a startable system image during the recovery. In the recovery stage, the unified metadata reading, object storage uploading and image importing process are realized. Based on the target custom system image, multiple recovery modes are supported, and the system disk is recovered through the system disk replacement interface in the original machine recovery and disk overlay recovery. Therefore, the application realizes adaptive backup and unified recovery of system disks of different operating system types in a cloud service environment.

Description

Technical Field

[0001] This application relates to the field of data backup and data recovery, and in particular to an adaptive backup and recovery method for a cloud server service system disk. Background Technology

[0002] In a cloud computing environment, feasible technical means for data backup and recovery mainly include two methods: fixed image export backup and fixed cloud disk mounting block-level backup.

[0003] The fixed image export backup technology targets the system disk of a cloud host. It creates a snapshot of the system disk and generates a custom image, which is then exported to object storage for storage. During restoration, the image is regenerated and the instance is created again through the image import interface. This method relies on the cloud platform's full support for system image export capabilities. If the platform has image export restrictions for system disks of specific operating system types, the backup task will directly fail during the export phase.

[0004] Fixed cloud disk mounting block-level backup technology can serve as a reference in the backup and recovery of system disk data, but it cannot be directly applied to system disk processing. This method involves creating a snapshot of the cloud disk and generating a temporary cloud disk, which is then mounted to a backup agent for block-level data reading and saving. During recovery, the backup data is written back to the target cloud disk. While this method can obtain disk block data, it does not preserve the system architecture, boot mode, and other information necessary for restoring the system disk to a bootable instance. Therefore, it is difficult to generate a bootable custom system image using only block data via the image import interface.

[0005] However, these implementation methods suffer from drawbacks when dealing with specific operating system types, including the failure of backups for some system disks due to the single backup path and the lack of boot information required for recovery of block-level backup data. Therefore, an adaptive backup and recovery method for cloud server system disks is needed to improve the universality and compatibility of system disk data backup and recovery. Summary of the Invention

[0006] The purpose of this application is to at least address one of the aforementioned technical deficiencies, particularly the lack of universality and compatibility in the existing technology for system disk data backup and recovery.

[0007] Firstly, this application provides an adaptive backup and recovery method for a cloud server service system disk, the method comprising:

[0008] In response to a backup task for a target cloud host service, obtain the operating system type information of the target cloud host service;

[0009] Based on the operating system type information, determine whether to perform a first backup operation or a second backup operation on the system disk of the target cloud host service;

[0010] A first backup file is generated through the first backup operation, or a second backup file is generated through the second backup operation, and auxiliary recovery information corresponding to the system disk of the target cloud host service is obtained when the second backup operation is executed;

[0011] In response to the recovery task, the system disk is used to unify the recovery process. The first backup file or the second backup file is used as input data. Combined with the auxiliary recovery information, the cloud platform image import interface is called to generate the target custom system image.

[0012] Based on the recovery mode indicated by the recovery task, the target custom system image is used to perform the corresponding system disk recovery process on the target location.

[0013] As an optional implementation, determining whether to perform a first backup operation or a second backup operation on the system disk of the target cloud host service based on the operating system type information includes:

[0014] Create a backup task processing object, and use the backup task processing object to perform a query operation on the instance information of the target cloud host service to be backed up, so as to obtain the operating system type information of the target cloud host service and record the original image identifier of the target cloud host service.

[0015] When the operating system type information indicates that the operating system corresponding to the target cloud host service belongs to a first preset type set, it is determined to perform a first backup operation on the system disk of the target cloud host service.

[0016] When the operating system type information indicates that the operating system corresponding to the target cloud host service belongs to the second preset type set, it is determined to perform a second backup operation on the system disk of the target cloud host service.

[0017] Among them, the operating systems in the first preset type set support exporting their own system images to the object storage service, while the operating systems in the second preset type set do not support exporting their own system images to the object storage service.

[0018] When the backup task processing object fails to execute the query operation, a preset rollback process is executed;

[0019] The rollback process includes directly performing the first backup operation on the corresponding system disk and generating an exception message related to the query operation.

[0020] As an optional implementation, generating the first backup file through the first backup operation includes:

[0021] Create a first snapshot for the system disk of the target cloud host service;

[0022] Based on the first snapshot, call the image creation interface to generate a backup custom system image, and wait for the backup custom system image to reach a usable state;

[0023] Call the image export interface to export the backup custom system image to the target object storage service, obtain the object name and bucket name returned by the image export interface, and obtain the image file from the target object storage service based on the object name and bucket name;

[0024] The image file is stored in the backup storage system as the first backup file, and the backup metadata management module registers the image file as a system disk backup piece.

[0025] As an optional implementation, the step of generating a second backup file through the second backup operation and obtaining auxiliary recovery information corresponding to the system disk of the target cloud host service during the execution of the second backup operation includes:

[0026] Create a second snapshot for the system disk of the target cloud host service;

[0027] Query the original image information of the target cloud host service to obtain auxiliary recovery information corresponding to the system disk of the target cloud host service;

[0028] The auxiliary recovery information includes system architecture, operating system type, operating system version, and boot mode;

[0029] A temporary cloud disk is created based on the second snapshot, and the temporary cloud disk is mounted to the backup agent machine, which then performs block-by-block data read operations on the temporary cloud disk.

[0030] The number of shards corresponding to the block data read operation is a preset fixed value, which is used to ensure that the range of data read covers the entire disk range from the starting offset to the end of the system disk capacity.

[0031] The data obtained by the block data read operation is stored in the backup storage system as a second backup file;

[0032] Write the auxiliary recovery information into the extended attribute field corresponding to the second backup file;

[0033] Uninstall the temporary cloud disk;

[0034] And, the step of querying the original image information of the target cloud host service and obtaining auxiliary recovery information corresponding to the system disk of the target cloud host service includes:

[0035] When the original image information of the target cloud host service is found and the original image information contains complete auxiliary recovery information, the auxiliary recovery information is extracted from the original image information.

[0036] When the original image information is not found or is partially missing, the image creation interface is temporarily invoked based on the second snapshot to generate a temporary custom system image, and the auxiliary recovery information is extracted from the information of the temporary custom system image.

[0037] As an optional implementation, in response to the recovery task, the unified recovery process via the system disk uses the first backup file or the second backup file as input data, combines the auxiliary recovery information, and calls the cloud platform image import interface to generate a target custom system image, including:

[0038] Read the backup file path corresponding to the system disk to be restored and the auxiliary recovery information from the backup set metadata associated with the recovery task;

[0039] Read the first backup file or the second backup file according to the backup file path, and upload it to the target object storage service to obtain the corresponding object storage access identifier;

[0040] Call the cloud platform image import interface, and use the object storage access identifier and the auxiliary recovery information as input parameters of the image import interface to generate the target custom system image;

[0041] When the target custom system image reaches a usable state, the following steps are triggered: according to the recovery mode indicated by the recovery task, the target custom system image is used to perform the corresponding system disk recovery process on the target location.

[0042] As an optional implementation, the recovery modes include new instance recovery, original machine recovery, and disk overwrite recovery. The step of performing corresponding system disk recovery processing on the target location using the target custom system image, based on the recovery mode indicated by the recovery task, includes:

[0043] When the recovery mode is new instance recovery, the target custom system image is imported according to the unified system disk recovery process, the preset instance configuration parameters are obtained, and the identifier of the target custom system image and the instance configuration parameters are passed to the cloud platform instance creation interface to create a new cloud host service instance.

[0044] The system disk of the new cloud host service instance is generated based on the target custom system image;

[0045] When the recovery mode is original machine recovery, query the original instance and currently mounted cloud disk information of the target cloud host service, verify that the original instance is consistent with the cloud host identifier recorded in the backup set, and that the list of cloud disk identifiers currently mounted by the original instance corresponds to the source volume identifier recorded in the backup set. Then, stop the operation of the original instance, keep the system disk of the original instance mounted on the original instance, import the target custom system image according to the unified system disk recovery process, call the system disk replacement interface of the cloud platform, and replace the system disk of the original instance based on the imported target custom system image.

[0046] When the recovery mode is disk overwrite recovery, query the pending cloud host service instance and pending cloud disk information, stop the operation of the pending cloud host service instance, remove the system disk of the pending cloud host service instance from the ordinary cloud disk mount write-back list, import the target custom system image according to the unified system disk recovery process, call the cloud platform's system disk replacement interface, and replace the system disk of the pending cloud host service instance based on the imported target custom system image.

[0047] As an optional implementation, the method further includes a temporary resource cleanup step, specifically including:

[0048] During the execution of the backup task or the recovery task, task context information is maintained;

[0049] The task context information is used to record the identifiers of temporary resources created during task execution. These temporary resources include snapshot resources, temporary cloud disk resources, temporary image resources, or temporary object resources.

[0050] After the backup task or the recovery task is completed, the identifiers of each temporary resource recorded in the task context information are traversed, and the corresponding resource deletion interface is called to clear each temporary resource.

[0051] Secondly, this application provides an adaptive backup and recovery device for a cloud server service system disk, the device comprising:

[0052] The processing module is used to obtain the operating system type information of the target cloud host service in response to a backup task for the target cloud host service;

[0053] The processing module is further configured to determine, based on the operating system type information, whether to perform a first backup operation or a second backup operation on the system disk of the target cloud host service;

[0054] The processing module is further configured to generate a first backup file through the first backup operation, or generate a second backup file through the second backup operation, and obtain auxiliary recovery information corresponding to the system disk of the target cloud host service when performing the second backup operation;

[0055] The processing module is also used to respond to the recovery task by using the first backup file or the second backup file as input data and combining the auxiliary recovery information to call the cloud platform image import interface to generate the target custom system image through the unified recovery process of the system disk;

[0056] The processing module is further configured to perform corresponding system disk recovery processing on the target location using the target custom system image, based on the recovery mode indicated by the recovery task.

[0057] Thirdly, this application provides a computer device including one or more processors and a memory storing computer-readable instructions that, when executed by the one or more processors, perform the steps of the method described in the first aspect.

[0058] Fourthly, this application provides a storage medium storing computer-readable instructions that, when executed by one or more processors, cause the one or more processors to perform the steps of the method described in the first aspect.

[0059] As can be seen from the above technical solutions, the embodiments of this application have the following advantages:

[0060] Based on any of the above embodiments, the method provided in this application, when a backup task is started, creates a backup task processing object and queries the instance information of the target cloud host service, obtains the operating system type information and records the original image identifier, and divides the system disk into a first preset type set or a second preset type set according to whether the operating system supports exporting its own system image to the object storage service. A first backup operation is performed on the former, and a second backup operation is performed on the latter. The first backup operation involves creating a first snapshot, calling the image creation interface to generate a custom backup system image and waiting for it to become available, calling the image export interface to export it to the object storage service, obtaining the object name and bucket name, downloading the image file, and storing it in the backup storage system. The backup metadata management module registers it as a system disk backup piece. The second backup operation involves creating a second snapshot, creating a temporary cloud disk based on the snapshot and mounting it to the backup agent, setting the number of shards parameter to a fixed value so that a single read covers the entire disk, storing the read data as a second backup file in the backup storage system, and during this process, obtaining auxiliary recovery information including system architecture, operating system type, operating system version, and boot mode and writing it into extended attribute fields. When the original image information is unavailable or partially missing, auxiliary recovery information is obtained by temporarily creating an image. Therefore, both types of system disks can complete backups, and the second backup operation bypasses the dependency on the image export interface, with auxiliary recovery information and backup data bound and stored together.

[0061] During the recovery phase, the backup file path and auxiliary recovery information are read from the backup set metadata. The first or second backup file is uploaded to the target object storage service to obtain the object storage access identifier. The cloud platform image import interface is called, using the object storage access identifier and auxiliary recovery information as input parameters, to generate a target custom system image. Once the image reaches a usable state, subsequent recovery processing is triggered. Both types of backup artifacts are thus uniformly converted into a standardized target custom system image, unifying the recovery entry point and conversion path. Based on the recovery mode indicated by the recovery task, new instance recovery passes the target custom system image identifier and instance configuration parameters to the instance creation interface to generate a new cloud host service instance. For original machine recovery, after verifying the instance and backup set information, the original instance system disk remains mounted, and replacement is completed using the system disk replacement interface based on the imported image. For disk overwrite recovery, the system disk is removed from the list of mounted and written back to ordinary cloud disks, and recovery is also completed using the image import and system disk replacement interfaces. The system disk is handled differently from the data disk. During backup and recovery task execution, the task context information uniformly records the identifiers of temporary resources. After the task terminates, the identifiers are traversed, and the resource deletion interface is called to clear them. Therefore, this application realizes a complete technical solution from adaptive strategy selection, traffic splitting backup, auxiliary information preservation, unified recovery to temporary resource cleanup, overcoming the defect of fixed single backup method failure under specific operating system, and ensuring the backup success rate and recovery bootability of different types of system disks. Attached Figure Description

[0062] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0063] Figure 1 A flowchart illustrating an adaptive backup and recovery method for a cloud server service system disk provided in one embodiment of this application;

[0064] Figure 2 A schematic diagram of the backup strategy selection process for an adaptive backup and recovery method for a cloud server service system disk provided in one embodiment of this application;

[0065] Figure 3 A schematic diagram of the ordinary system disk image export backup process of the adaptive backup and recovery method for the cloud host service system disk provided in one embodiment of this application;

[0066] Figure 4 A schematic diagram of a special system disk mounting backup process for an adaptive backup and recovery method for a cloud server service system disk provided in one embodiment of this application;

[0067] Figure 5 A schematic diagram of the unified recovery process of the system disk in the adaptive backup and recovery method for cloud server service system disk provided in one embodiment of this application;

[0068] Figure 6 A schematic diagram illustrating the backup metadata saving process of an adaptive backup and recovery method for a cloud server service system disk provided in one embodiment of this application;

[0069] Figure 7 A schematic diagram of the data disk backup process for an adaptive backup and recovery method for a cloud server service system disk provided in one embodiment of this application;

[0070] Figure 8 A schematic diagram of the new instance recovery process of the adaptive backup and recovery method for the system disk of a cloud server service provided in one embodiment of this application;

[0071] Figure 9 A schematic diagram of the original machine recovery process of the adaptive backup and recovery method for the system disk of a cloud host service provided in one embodiment of this application;

[0072] Figure 10 A schematic diagram of the disk overwrite recovery process of the adaptive backup and recovery method for the system disk of a cloud host service provided in one embodiment of this application;

[0073] Figure 11 A schematic diagram of the temporary resource cleanup process for an adaptive backup and recovery method for a cloud server service system disk provided in one embodiment of this application;

[0074] Figure 12 This is an internal structural diagram of a computer device provided in an embodiment of this application. Detailed Implementation

[0075] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0076] First, let's explain the terms that may be involved:

[0077] ECS (Elastic Compute Service): Elastic computing service, specifically referring to Volcano Engine cloud server service in this article. An ECS instance typically consists of resources such as system disk, data disk, instance specifications, network, security group, and image.

[0078] EBS (Elastic Block Store): Elastic Block Storage, referring in this article to the Volcano Engine Cloud Disk Service. Both system disks and data disks are cloud disk resources, but they differ in their mounting, unmounting, and recovery methods.

[0079] TOS (TorchObjectStorage): Volcano Engine object storage service. In this solution, TOS serves as an intermediary storage for image export and import, used to save image objects generated by ExportImage, or to save system disk backup files uploaded during the recovery phase.

[0080] VPC (Virtual Private Cloud): A private network used to define the network environment in which cloud servers reside. When creating and restoring an ECS instance, you need to configure network parameters such as VPC, subnet, and security group according to the recovery target.

[0081] API (Application Programming Interface): In this article, it refers to the cloud resource operation interfaces provided by Volcano Engine, such as instance query, snapshot creation, image import, image export, and system disk replacement interfaces.

[0082] CreateImage: This is the Volcano Engine interface for creating custom system images based on system disk snapshots. In this solution, regular system disk backups will call this interface to create exportable custom system images; for special system disks, this interface can also be temporarily called to obtain image metadata when the original image is not searchable.

[0083] ExportImage: This is the interface for exporting custom system images to the Volcano Engine interface of TOS. Regular system disks can export image files through this interface; however, special system disks such as Windows, Red Hat, and SUSE have limitations that prevent them from being exported to TOS.

[0084] ImportImage: This interface imports image files or raw disk files from TOS into a custom system image for Volcano Engine. This solution uses this interface to generate a recovery image that can be used to create new instances or replace the system disk during the recovery phase.

[0085] ReplaceSystemVolume: This is the Volcano Engine interface for replacing the system disk of a target ECS instance based on a specified custom system image. This solution uses this interface to restore the system disk in both original machine recovery and disk overwrite recovery.

[0086] Snapshot: A snapshot refers to a copy of the data state of a cloud disk at a specific point in time. The backup system creates temporary cloud disks or custom system images using system disk snapshots or data disk snapshots.

[0087] Image: A cloud server template that contains operating system boot information and system disk data. The custom system image in this article can be used to create ECS instances or replace the system disk of an existing instance.

[0088] SystemVolume: The system disk refers to the cloud disk used by an ECS cloud server to boot the operating system. In addition to disk data, the system disk also depends on information such as system architecture, operating system type, operating system version, and boot mode.

[0089] DataVolume: A data disk refers to a non-system disk in an ECS cloud server used to store business data. Data disks are typically created as temporary cloud disks through snapshots, and then mounted to a backup agent for block-level backup and recovery.

[0090] Agent: A proxy program or proxy machine refers to the component or host that performs backup and restore tasks. In this solution, the Agent is responsible for scheduling...

[0091] Volcano Engine API, mounting temporary cloud disks, reading or writing cloud disk data, uploading or downloading TOS objects.

[0092] BackupSet: A backup set refers to the collection of data files and metadata generated by a single backup task. A backup set contains system disk backup pieces, data disk backup pieces, and catalog metadata describing these backup pieces.

[0093] Catalog: Directory metadata refers to a data structure that records information such as backup fragment path, size, offset, fragment number, source volume ID, and extended attributes. The recovery task uses the catalog to locate the backup fragments it needs to read.

[0094] extended_attrs (ExtendedAttributes): Extended attributes, which are used to store additional metadata required for system disk recovery, such as system architecture, operating system type, operating system version, and boot mode.

[0095] architecture: System architecture, such as x86_64, arm64, etc. This field is one of the parameters that Volcano Engine's ImportImage may need when importing system images.

[0096] os_type (OperatingSystemType): Operating system type, such as Windows, Linux, etc. Backup strategy selection and image import may both depend on this field.

[0097] os_version (OperatingSystemVersion): Operating system version, such as Windows Server version, Linux distribution version, etc. This field describes the operating system version corresponding to the imported image.

[0098] boot_mode (BootMode): Boot mode, such as BIOS or UEFI. If the boot mode is missing or incorrect during system disk recovery, the recovered ECS instance may fail to boot properly.

[0099] raw (RawDiskImage): The raw disk image format represents a full-disk data file saved according to the disk's logical addresses. In this solution, the single-disk backup file formed by mounting and backing up a special system disk can be considered a raw full-disk file.

[0100] qcow2 (QEMUCopyOnWrite2): A virtual disk image format. When a regular system disk is exported to TOS via ExportImage, a qcow2-like image file may be generated.

[0101] image_uri (ImageUniformResourceIdentifier): The access location of the image file in object storage. During the recovery phase, after the system disk backup file is uploaded to TOS, an image_uri is obtained. ImportImage reads the file based on this location and imports the image.

[0102] This application uses Volcano Engine as an example to systematically illustrate the adaptive backup and recovery method for the system disk of the cloud server service provided in this application. It should be understood that Volcano Engine is merely a feasible implementation method described based on a specific scenario, and this application can be used for all cloud computing services related to the underlying principles.

[0103] In cloud computing platforms, ECS cloud servers typically consist of multiple resources, including system disks, data disks, instance specifications, availability zones, VPCs, subnets, security groups, images, elastic public IPs, and object storage. Backing up an ECS cloud server requires not only preserving the business data on the system and data disks, but also metadata such as the operating system type, system architecture, boot mode, cloud disk specifications, and network configuration necessary for recovery. If only disk block data is preserved without system disk boot information, the recovered cloud server may not be recognized as a bootable instance by the cloud platform, or it may fail to boot its operating system.

[0104] Existing cloud server backup and recovery solutions typically rely on technologies such as cloud disk snapshots, temporary cloud disk mounting, image export, object storage relay, and image import. For ordinary data disks, a common practice is to create a data disk snapshot, create a temporary cloud disk based on the snapshot, mount the temporary cloud disk to a backup agent, and then have the backup agent read the cloud disk block data and write it to backup storage. During recovery, the target cloud disk is created, the backup data is written back to the target cloud disk, and then mounted to the target cloud server.

[0105] For system disks, a common approach is to create a system disk snapshot, create a custom system image based on the snapshot, export the custom system image to object storage, and then download the image file from object storage and write it to backup storage. During recovery, the image file is re-uploaded to object storage, the cloud platform's image import interface is called to generate the custom system image, and then a cloud host is created based on this image. This method is suitable for scenarios where the cloud platform supports system image export.

[0106] However, in the Volcano Engine ECS scenario, system disk backup and recovery faces more complex platform limitations. It has been verified that Volcano Engine Windows and Red Hat series system images cannot be exported to TOS; the current implementation also includes SUSE series systems under a similar special strategy. Furthermore, Volcano Engine system disks cannot be directly mounted and unmounted like ordinary data disks, nor can independent system disks be directly created for the agent machine to read. Therefore, system disk backup methods cannot be simply applied to data disks, nor can a fixed image export method be used for all system disks.

[0107] As the demand for full-system protection of cloud servers increases, backup systems need to select strategies among different operating systems, cloud platform capabilities, and recovery targets. Especially in Volcano Engine ECS, different backup paths are required for ordinary system disks and special system disks, and they need to be uniformly converted into a custom system image that Volcano Engine can recognize during the recovery phase, so as to support the recovery of newly created instances, the original machine recovery, and disk overwrite recovery.

[0108] For the fixed system disk image export and backup technology, a snapshot is first created on the ECS cloud host's system disk. A custom system image is then created based on the system disk snapshot and exported to object storage. The image file is downloaded from object storage and saved to backup storage. During restoration, the image file is uploaded to object storage, and the cloud platform's image import interface is called to generate the custom system image. A new cloud host is then created based on the imported custom system image. The advantages are a clear process, complete semantics of the system disk image, and ease of creating new instances based on the image during restoration. This technology is suitable for scenarios where the cloud platform allows system images to be exported to object storage.

[0109] Another related technology is fixed cloud disk mounting block-level backup technology, which involves creating a snapshot of the cloud disk and then creating a temporary cloud disk based on the snapshot. The temporary cloud disk is mounted to a backup agent, which reads the data from the temporary cloud disk block by block and writes it to backup storage. During recovery, the target cloud disk is created and the block data is written back. This technology is suitable for backup and recovery of ordinary data disks and can serve as a reference technology for special scenarios involving system disks, but it cannot directly and completely solve the system disk recovery problem.

[0110] The main drawback of fixed system disk image export backup technology is that, by default, the system disk image can be exported to object storage by the cloud platform. In Volcano Engine ECS, this premise does not hold true for system disks such as Windows, Red Hat, and SUSE, causing backup tasks to fail during the ExportImage to TOS stage.

[0111] Fixed cloud disk mounting block-level backup technology also has its shortcomings: This technology is suitable for ordinary data disks, but for system disks, recovery is not simply a matter of writing back to the cloud disk. It also requires meeting the image import parameters required by the cloud platform for creating instances or replacing system disks, such as system architecture, operating system type, operating system version, and boot mode. If only the system disk data is saved block by block without saving this metadata, it may not be possible to import it into a bootable custom system image during the recovery phase.

[0112] In summary, the relevant implementation methods have at least the following limitations:

[0113] The system disk image export path lacks compatibility. The solution of using a fixed system disk snapshot to create an image and export it to TOS cannot handle situations where system images from Volcano Engine Windows, Red Hat, SUSE, etc., cannot be exported to TOS, causing backup tasks to fail during the image export stage.

[0114] System disks and data disks have different resource constraints and cannot be treated the same as ordinary cloud disks. Volcano Engine's system disk cannot be directly mounted or unmounted like a regular data disk, nor can a separate system disk be directly created for the agent machine to read. Simply applying the data disk backup and recovery process will not complete the system disk recovery loop.

[0115] Block-level system disk backups lack image import metadata. If a special system disk is only read block by block to form a raw full disk file without saving the system architecture, operating system type, operating system version, and boot mode, then even if the full disk file is uploaded to TOS during the recovery phase, it may not be able to be imported into a bootable custom system image via ImportImage.

[0116] The recovery paths are inconsistent. A backup of a regular system disk image is exported as an image file, while a backup of a special system disk is mounted as a full-disk block data file. These two types of backups have different formats. If the system recovery process cannot uniformly convert both into a custom system image, then new recovery, original machine recovery, and disk overwrite recovery need to implement different logic, resulting in high system complexity and a high risk of errors.

[0117] The handling of the system disk in original machine recovery and overwrite recovery is unclear. When performing original machine recovery or disk overwrite recovery using Volcano Engine, the system disk cannot be unmounted and then written back to the proxy machine as a data disk. Instead, it should be completed by importing an image and calling the system disk replacement interface. Existing fixed data disk recovery solutions cannot meet this requirement.

[0118] Temporary resource residue poses a high risk. Backup and recovery processes create snapshots, temporary cloud disks, temporary images, TOS temporary objects, and mount relationships. Without a unified context management and cleanup process, cloud resources can easily remain after task failure or cancellation, consuming quotas and storage space.

[0119] The main technical problem solved by this invention is: in Volcano Engine ECS, how to automatically select different backup strategies for ordinary system disks and special system disks such as Windows, Red Hat, and SUSE that cannot be exported to TOS, and uniformly convert them into custom system images that can be used to create new instances or replace system disks through TOS and ImportImage during the recovery phase.

[0120] This is a technical issue because it directly involves specific technical aspects such as cloud platform system image export capabilities, system disk snapshot conversion, temporary cloud disk mounting and reading, image import parameter saving, and system disk replacement interface calls. If this issue cannot be resolved, the backup system will fail during the special system disk image export stage, or a bootable custom system image will be unable to be generated during the recovery stage.

[0121] Compared to existing technologies that use fixed image export backups or fixed cloud disk mount backups, the main innovation of this application lies in the following: When the Volcano Engine ECS backup task starts, it first determines whether the system disk is suitable for image export based on the instance's operating system type and name; for ordinary system disks, it continues to use the image export backup path of "system disk snapshot, CreateImage, ExportImage to TOS, download image file to backup storage"; for special system disks such as Windows, Red Hat, and SUSE, it changes to the mount backup path of "system disk snapshot, create temporary cloud disk based on snapshot, mount proxy machine, full disk single-piece read", and saves the system architecture, operating system type, operating system version, and boot mode required by ImportImage; during recovery, regardless of whether the system disk backup piece comes from the image export file or the full disk block data file, it is first uploaded to TOS, then ImportImage is called to generate a custom system image, and finally a new ECS instance is created or ReplaceSystemVolume is called to replace the target instance's system disk according to the recovery type, thus forming an adaptive backup and recovery scheme that can recover both ordinary and special system disks in a closed loop.

[0122] In summary, the technical concept of this application lies in the following: When a backup task is initiated, a backup task processing object is created, and instance information of the target cloud host service is queried. Operating system type information is obtained, and the original image identifier is recorded. Based on whether the operating system supports exporting its own system image to the object storage service, the system disk is divided into a first preset type set or a second preset type set. A first backup operation is performed on the former, and a second backup operation is performed on the latter. The first backup operation involves creating a first snapshot, calling the image creation interface to generate a custom backup system image and waiting for it to become available, calling the image export interface to export it to the object storage service, obtaining the object name and bucket name, downloading the image file, and storing it in the backup storage system. The backup metadata management module registers it as a system disk backup piece. The second backup operation involves creating a second snapshot, creating a temporary cloud disk based on the snapshot and mounting it to the backup agent machine, setting the number of shards to a fixed value to ensure that a single read covers the entire disk, storing the read data as a second backup file in the backup storage system, and during this process, obtaining auxiliary recovery information including system architecture, operating system type, operating system version, and boot mode and writing it to extended attribute fields. When the original image information is unavailable or partially missing, auxiliary recovery information is obtained by temporarily creating an image. Therefore, both types of system disks can complete backups, and the second backup operation bypasses the dependency on the image export interface, with auxiliary recovery information and backup data bound and stored together.

[0123] During the recovery phase, the backup file path and auxiliary recovery information are read from the backup set metadata. The first or second backup file is uploaded to the target object storage service to obtain the object storage access identifier. The cloud platform image import interface is called, using the object storage access identifier and auxiliary recovery information as input parameters, to generate a target custom system image. Once the image reaches a usable state, subsequent recovery processing is triggered. Both types of backup artifacts are thus uniformly converted into a standardized target custom system image, unifying the recovery entry point and conversion path. Based on the recovery mode indicated by the recovery task, new instance recovery passes the target custom system image identifier and instance configuration parameters to the instance creation interface to generate a new cloud host service instance. For original machine recovery, after verifying the instance and backup set information, the original instance system disk remains mounted, and replacement is completed using the system disk replacement interface based on the imported image. For disk overwrite recovery, the system disk is removed from the list of mounted and written back to ordinary cloud disks, and recovery is also completed using the image import and system disk replacement interfaces. The system disk is handled differently from the data disk. During backup and recovery task execution, the task context information uniformly records the identifiers of temporary resources. After the task terminates, the identifiers are traversed, and the resource deletion interface is called to clear them. Therefore, this application realizes a complete technical solution from adaptive strategy selection, traffic splitting backup, auxiliary information preservation, unified recovery to temporary resource cleanup, overcoming the defect of fixed single backup method failure under specific operating system, and ensuring the backup success rate and recovery bootability of different types of system disks.

[0124] The methods provided in this application will be described in detail below based on the corresponding implementation methods in some practical application scenarios.

[0125] Figure 1 This is a flowchart illustrating an adaptive backup and recovery method for a cloud server service system disk provided in one embodiment of this application, as shown below. Figure 1 As shown, this application provides an adaptive backup and recovery method for a cloud server service system disk, the method comprising:

[0126] S101. In response to a backup task for a target cloud host service, obtain the operating system type information of the target cloud host service;

[0127] S102. Based on the operating system type information, determine whether to perform a first backup operation or a second backup operation on the system disk of the target cloud host service;

[0128] S103. Generate a first backup file through the first backup operation, or generate a second backup file through the second backup operation, and obtain auxiliary recovery information corresponding to the system disk of the target cloud host service when performing the second backup operation;

[0129] S104. In response to the recovery task, the first backup file or the second backup file is used as input data through the unified recovery process of the system disk. Combined with the auxiliary recovery information, the cloud platform image import interface is called to generate the target custom system image.

[0130] S105. Based on the recovery mode indicated by the recovery task, use the target custom system image to perform the corresponding system disk recovery process on the target location.

[0131] To make the solution corresponding to this application easier to understand in practical application scenarios, the modular processing entities and their data flow that may be involved in this application may include:

[0132] Backup and recovery management terminal: responsible for receiving ECS ​​backup and recovery tasks created by users, parsing task configurations such as backup source, recovery target, backup storage, TOS bucket, concurrency parameters, and recovery mode, and scheduling ECSAgent to execute specific tasks.

[0133] ECSAgent: Deployed on the backup agent machine, it is responsible for performing the actual backup and recovery actions of the system disk and data disk, including calling the Volcano Engine API, mounting temporary cloud disks, reading cloud disk block data, uploading or downloading TOS objects, writing data to backup storage or reading data from backup storage.

[0134] The Volcano Engine APIService module encapsulates the interface capabilities of Volcano Engine ECS, EBS, Image, VPC, TOS, etc., including operations such as instance query, cloud disk query, snapshot creation, temporary cloud disk creation, cloud disk mounting, image creation, image export, image import, system disk replacement, and resource deletion.

[0135] System disk strategy selection module: Located in the Volcano Engine backup task processing logic, it is responsible for querying ECS ​​instance information, reading os_type, os_name and original image ID, and determining whether to use the image export backup strategy or the mount backup strategy for the system disk.

[0136] Image Export Backup Module: Used for backing up regular system disks. This module calls the Volcano Engine's CreateImage function to create a custom system image based on a system disk snapshot, then calls ExportImage to export the custom system image to TOS, and finally, ECSAgent downloads the image file to backup storage.

[0137] System Disk Mount Backup Module: Used for backing up special system disks such as Windows, Red Hat, and SUSE. This module creates a system disk snapshot, creates a temporary cloud disk based on the snapshot, mounts the temporary cloud disk to the backup agent machine, reads the data from the temporary cloud disk in full, and writes it to the backup storage.

[0138] Data Disk Mounting Backup Module: Used for data disk backup. This module creates a data disk snapshot, creates a temporary data disk based on the snapshot, mounts the temporary data disk to the backup agent, and reads data concurrently by shard and writes it to the backup storage.

[0139] Backup storage: Used to save backup pieces of system disk and data disk, backup set catalog, backup piece path, offset, size and extended attributes.

[0140] TOS Object Storage: Serves as a transit storage for exporting and importing images from the Volcano Engine. During a regular system disk backup, ExportImage exports the image to TOS; during restoration, the system disk backup is first uploaded to TOS, and then imported as a custom image via ImportImage.

[0141] Backup metadata management module: Responsible for recording backup information of system disks and data disks. For special system disks, it also records image import metadata such as architecture, os_type, os_version, and boot_mode.

[0142] Recovery orchestration module: responsible for reading the backup set catalog, uploading the system disk backup to TOS, calling ImportImage to import custom system images, and performing new instance recovery, original machine recovery, or disk overwrite recovery according to the recovery mode.

[0143] Temporary resource cleanup module: responsible for cleaning up snapshots, temporary cloud disks, temporary custom images, TOS temporary objects and proxy machine mount relationships created during the task.

[0144] The connections and data flow between the components are as follows:

[0145] The backup and recovery management terminal sends backup or recovery tasks to ECSAgent.

[0146] ECSAgent accesses Volcano Engine ECS, EBS, Image, VPC, and TOS services through the Volcano Engine APIService module.

[0147] ECSAgent transfers backup chip data and recovery data between the backup storage and the backup storage.

[0148] ECSAgent transfers image files or raw system disk full disk files between itself and TOS.

[0149] After the backup is completed, the backup metadata management module writes the backup piece information to the backup set catalog, and the recovery orchestration module reads the catalog during recovery.

[0150] This application constructs an overall process consisting of operating system awareness, traffic splitting and backup decision-making, backup execution and auxiliary information preservation, recovery state normalization processing, and differentiated recovery execution. It also includes some temporary resource lifecycle management methods, which can be found in the relevant implementation methods.

[0151] First, at the initial stage of the backup task, the operating system type identifier of the target cloud host service is obtained through the cloud platform instance query interface. The system internally maintains a classification principle of a first set of operating systems and a second set of operating systems. This classification is based on whether the corresponding operating system supports exporting its own system image to the object storage service. If the identifier belongs to the first set, the current system disk is marked as exportable, and the system proceeds to the first backup path; if it belongs to the second set, it is marked as non-exportable, and the system proceeds to the second backup path. When information retrieval is abnormal, this solution adopts a default fallback to the first path fault tolerance strategy and simultaneously generates an exception record.

[0152] The first backup path corresponds to the exportable system disk. The technical process is as follows: create a snapshot of the system disk, call the image creation interface to generate a temporary custom image, and after the image status becomes available, call the image export interface to export it to the object storage service and obtain an access identifier. Then, download the image file from the object storage service, persist it as the first backup file to an independent backup storage system, and clean up the temporary image resources when the task ends.

[0153] The second backup path corresponds to the non-exportable system disk. The technical process is as follows: a system disk snapshot is created; a temporary cloud disk resource is created based on this snapshot; and this temporary cloud disk is mounted to the backup agent. The backup agent obtains the total capacity of the temporary cloud disk, forces the number of parallel shards for data read operations to a single fixed value, and sequentially reads the entire disk range from logical offset zero to the total capacity, generating a second backup file in a single block data format, which is then stored in the backup storage. Simultaneously, the system queries the original image information of the cloud host or, through a backup method of temporarily creating an image based on the snapshot, extracts and saves auxiliary recovery information such as system architecture and boot mode, and associates this information with the second backup file in the backup set metadata.

[0154] During the recovery phase, the solution employs a unified intermediate state conversion mechanism. Based on the backup set metadata, the recovery orchestration module reads the backup file paths and corresponding auxiliary recovery information. It uploads either the first or second backup file to the object storage service and obtains its access identifier. The cloud platform image import interface is then invoked, passing the access identifier and auxiliary recovery information as parameters to generate the target custom system image. The system then polls for the image to reach a usable state. This process effectively converts heterogeneous backup artifacts (image files and block data files) into a standardized system image recognizable by the cloud platform.

[0155] Subsequently, differentiated recovery is performed based on the recovery mode: For newly created instance recovery, the instance creation interface is called, passing in the target custom system image identifier and instance configuration parameters to generate a new cloud host, and the target data disk is mounted for data write-back; for original instance recovery, after stopping the original instance, the data disk is unmounted and mounted on the agent machine for write-back, while the system disk is directly replaced with the target custom system image by calling the system disk replacement interface, without performing unmounting and mounting operations. In disk overwrite recovery scenarios, the principle of separating the system disk and data disk is also followed, with the system disk handled using the replacement interface and the data disk handled using the mount and write-back method.

[0156] Furthermore, during task execution, the task context information structure is maintained, and cloud resources such as snapshots, temporary cloud disks, and temporary images are registered. After the task terminates, the context information is traversed, and the resource deletion interface is called sequentially to achieve deterministic reclamation of temporary resources and avoid resource leaks.

[0157] The method provided in this embodiment first obtains the operating system type information of the target cloud host service when the backup task starts. Based on this information, it adaptively selects between two types of backup operations, enabling both system disks that support image export and those that do not to complete the backup through their respective suitable paths. This overcomes the problem of backup failure at the backup stage when using a fixed single backup method for a specific operating system. For system disks that do not support image export, auxiliary recovery information is simultaneously obtained during the second backup operation, allowing the subsequent recovery stage to successfully import block data files into a bootable system image. During the recovery stage, a unified system disk recovery process is used to combine the first or second backup file with the auxiliary recovery information and uniformly call the cloud platform image import interface to generate a target custom system image. This converts backup artifacts of different forms into a standardized intermediate form, unifying the recovery orchestration logic. Finally, according to the recovery mode indicated by the recovery task, the target custom system image is used to perform corresponding system disk recovery processing on the target location, enabling new instance recovery, original machine recovery, and disk overwrite recovery to be completed based on the same set of recovery intermediate states. Therefore, this implementation method achieves closed-loop backup and recovery of system disks of different operating system types through adaptive strategy selection, auxiliary information preservation, and unified recovery conversion, thereby improving backup success rate and recovery flexibility.

[0158] As an optional implementation, determining whether to perform a first backup operation or a second backup operation on the system disk of the target cloud host service based on the operating system type information includes:

[0159] Create a backup task processing object, and use the backup task processing object to perform a query operation on the instance information of the target cloud host service to be backed up, so as to obtain the operating system type information of the target cloud host service and record the original image identifier of the target cloud host service.

[0160] When the operating system type information indicates that the operating system corresponding to the target cloud host service belongs to a first preset type set, it is determined to perform a first backup operation on the system disk of the target cloud host service.

[0161] When the operating system type information indicates that the operating system corresponding to the target cloud host service belongs to the second preset type set, it is determined to perform a second backup operation on the system disk of the target cloud host service.

[0162] Among them, the operating systems in the first preset type set support exporting their own system images to the object storage service, while the operating systems in the second preset type set do not support exporting their own system images to the object storage service.

[0163] When the backup task processing object fails to execute the query operation, a preset rollback process is executed;

[0164] The rollback process includes directly performing the first backup operation on the corresponding system disk and generating an exception message related to the query operation.

[0165] Figure 2 This is a schematic diagram illustrating the backup strategy selection process of an adaptive backup and recovery method for the system disk of a cloud server service provided in one embodiment of this application. For the backup strategy selection process, after the Volcano Engine ECS backup task starts, the system first creates a Volcano Engine backup task processing object. This object queries the information of the ECS instance to be backed up, obtaining the instance ID, operating system type, operating system name, original image ID, system disk list, and data disk list.

[0166] If the instance information query is successful, the system records the original image ID and reads os_type and os_name. When os_type or os_name contains Windows, or os_name contains Red Hat or SUSE, the system sets the system disk backup policy to the mount backup policy; otherwise, it sets it to the image export backup policy.

[0167] If instance information query fails, the system cannot determine the operating system type and will revert to the default image export backup strategy. This revert strategy is suitable for scenarios where information query fails occasionally, but for system disks that are actually Windows, Red Hat, or SUSE, subsequent image export stages may still fail. Therefore, successful instance information query is the optimal path.

[0168] Specifically, at the beginning of the backup task, based on the operating system attributes of the cloud host to be backed up, it automatically determines whether the system disk should be exported as an image or mounted as a backup path, thus laying the foundation for subsequent offloading and execution.

[0169] After the backup task is started, the system first creates a backup task processing object. This object serves as the context carrier for the entire backup process, responsible for state management and data transfer throughout the backup lifecycle. Once the backup task processing object is created, it immediately initiates an instance information query request to the cloud platform via the cloud platform's application programming interface. The query includes the instance identifier of the target cloud host service, the operating system type field, the operating system name field, the original image identifier, the system disk list, and the data disk list. The purpose of this query is to obtain a complete configuration profile of the cloud host to be backed up, enabling the backup system to accurately perceive the environmental characteristics of the backup source. After a successful query, the system records the original image identifier in the task context. This identifier can be used to query the original image information to obtain auxiliary recovery information during subsequent special system disk backup processes. Subsequently, the system reads the operating system type field and the operating system name field and enters the policy determination logic. The core basis of the determination logic is whether the target operating system supports exporting its own system image to the object storage service. In the specific implementation, when the operating system type field indicates Windows, or the operating system name field contains specific identifiers such as Red Hat or SUSE, the system determines that the system disk belongs to the second preset type set that does not support image export and sets the system disk backup policy to the mount backup policy. When neither the operating system type nor the operating system name field belongs to the above types, the system determines that the system disk belongs to the first preset type set that supports image export and sets the system disk backup strategy to the image export backup strategy. Since Windows, Red Hat, and SUSE operating systems may fail when calling the image export interface, they need to be categorized under a special strategy path. When a query operation fails, for example, due to network fluctuations or temporary unavailability of the cloud platform interface causing the instance information to fail to be obtained, the system cannot obtain the operating system type information. In this case, a preset rollback process is executed, defaulting to the image export backup strategy. During the rollback process, the system generates an exception message related to the query operation, which includes the identifier of the target cloud host service and a description of the reason for the query failure, for subsequent troubleshooting.

[0170] This implementation method creates a backup task processing object and performs an instance information query operation to obtain operating system type information and record the original image identifier. This enables the backup system to accurately perceive the system environment characteristics of the cloud host to be backed up, providing a basis for subsequent strategy selection. The method uses whether the operating system supports exporting its own system image to the object storage service as the technical standard for dividing the first and second preset type sets. This ensures that strategy determination has clear and verifiable conditions, rather than relying on empirical rules or external configurations. When the query operation fails, a preset rollback process is executed, defaulting to the first backup operation and generating an exception message. This allows the backup process to continue even in scenarios with occasional information retrieval anomalies, avoiding task interruption. Furthermore, the generation of the exception message facilitates subsequent analysis and troubleshooting of the query failure. Therefore, this implementation method balances the accuracy of determination, the robustness of the process, and the traceability of anomalies in the strategy selection stage.

[0171] As an optional implementation, generating the first backup file through the first backup operation includes:

[0172] Create a first snapshot for the system disk of the target cloud host service;

[0173] Based on the first snapshot, the image creation interface is called to generate a backup custom system image, and the backup custom system image is waited for to reach a usable state.

[0174] Call the image export interface to export the backup custom system image to the target object storage service, obtain the object name and bucket name returned by the image export interface, and obtain the image file from the target object storage service based on the object name and bucket name;

[0175] The image file is stored in the backup storage system as the first backup file, and the backup metadata management module registers the image file as a system disk backup piece.

[0176] Figure 3 This is a schematic diagram of the ordinary system disk image export backup process for an adaptive backup and recovery method for a cloud server service system disk provided in one embodiment of this application. For the ordinary system disk image export backup process, when the system disk adopts an image export backup strategy, the system executes the following steps:

[0177] Create a system disk snapshot for the system disk to be backed up.

[0178] A custom system image is created by calling the Volcano Engine CreateImage interface based on a system disk snapshot.

[0179] Waiting for the custom system image to become usable.

[0180] Use the Volcano Engine's ExportImage interface to export a custom system image to TOS.

[0181] Get the TOS object name and bucket name returned by the Volcano engine.

[0182] ECSAgent downloads the image file from TOS.

[0183] ECSAgent writes the image file to backup storage.

[0184] The backup metadata management module registers the image file as a system disk backup disk.

[0185] The temporary resource cleanup module cleans up system disk snapshots, custom system images, and TOS temporary objects.

[0186] The source of a regular system disk backup is a system image file exported by Volcano Engine, which is suitable for direct use as an input file for ImportImage.

[0187] Specifically, the process of exporting and backing up a regular system disk image corresponds to the first backup operation, and it is applicable to system disks that the policy selection module determines support for image export. The principle behind this process is to utilize the image creation and export capabilities provided by the cloud platform to convert the system disk data into a standard image file, and then download this image file to an independent backup storage system for storage. During restoration, this image file can be directly used as input to the image import interface.

[0188] After the strategy selection module determines to adopt the image export backup strategy, the system first creates a snapshot of the system disk to be backed up. A snapshot is a copy of the data state of the cloud disk at a certain point in time. The purpose of creating a snapshot is to obtain a static data source with guaranteed data consistency without affecting the normal operation of the original cloud host. After the snapshot is created, the system calls the create image interface based on the first snapshot, submitting the snapshot to the cloud platform's image service, which generates a backup custom system image. The essence of this step is to integrate and encapsulate the disk block data in the snapshot with the metadata required for operating system startup, forming a system image format that the cloud platform can recognize. After calling the create image interface, the system enters a waiting state, polling the generation status of the backup custom system image at a preset time period. The design consideration for waiting for the image to reach a usable state is that image creation is an asynchronous process, and its time consumption depends on the size of the system disk data and the processing capacity of the cloud platform's image service. If subsequent interfaces are called before the image is ready, the call will fail. When the backup custom system image reaches a usable state, the system calls the image export interface to export the image to the target object storage service. The image export interface transfers the image file from the cloud platform's internal storage to a separate object storage service, assigning an object name and a bucket name to the image file. After the system obtains the returned object name and bucket name, the backup agent downloads the image file from the target object storage service based on these names. Once downloaded, the backup agent writes the image file as the first backup file to the backup storage system. The backup metadata management module simultaneously registers this image file as a system disk backup piece, recording its storage path, size, and other metadata information. The temporary resource cleanup module cleans up system disk snapshots, backup custom system images, and temporary objects in the object storage service after the backup task is completed.

[0189] The first backup operation provided in this embodiment creates a first snapshot and generates a custom backup system image by calling the image creation interface based on the snapshot. After the image reaches a usable state, the image export interface is called to export it to the target object storage service. This allows the generation and export of the image file to be completed step-by-step, with each stage's state clearly defined and controllable. After obtaining the object name and bucket name returned by the image export interface, the image file is retrieved from the target object storage service based on the object name and bucket name and stored in the backup storage system. This ensures a clear path for the backup data and traceable storage location. The backup metadata management module registers the image file as a system disk backup piece, enabling the backup piece to be accurately located and read through the backup set metadata during the subsequent recovery phase. Therefore, this embodiment constructs a complete operation chain from snapshot creation to backup piece registration for system disks that support image export, ensuring that each step of the first backup operation is seamlessly connected, and that the source and storage location of the backup products are clearly recorded.

[0190] As an optional implementation, the step of generating a second backup file through the second backup operation and obtaining auxiliary recovery information corresponding to the system disk of the target cloud host service during the execution of the second backup operation includes:

[0191] Create a second snapshot for the system disk of the target cloud host service;

[0192] Query the original image information of the target cloud host service to obtain auxiliary recovery information corresponding to the system disk of the target cloud host service;

[0193] The auxiliary recovery information includes system architecture, operating system type, operating system version, and boot mode;

[0194] A temporary cloud disk is created based on the second snapshot, and the temporary cloud disk is mounted to the backup agent machine, which then performs block-by-block data read operations on the temporary cloud disk.

[0195] The number of shards corresponding to the block data read operation is a preset fixed value, which is used to ensure that the range of data read covers the entire disk range from the starting offset to the end of the system disk capacity.

[0196] The data obtained by the block data read operation is stored in the backup storage system as a second backup file;

[0197] Write the auxiliary recovery information into the extended attribute field corresponding to the second backup file;

[0198] Uninstall the temporary cloud disk;

[0199] And, the step of querying the original image information of the target cloud host service and obtaining auxiliary recovery information corresponding to the system disk of the target cloud host service includes:

[0200] When the original image information of the target cloud host service is found and the original image information contains complete auxiliary recovery information, the auxiliary recovery information is extracted from the original image information.

[0201] When the original image information is not found or is partially missing, the image creation interface is temporarily invoked based on the second snapshot to generate a temporary custom system image, and the auxiliary recovery information is extracted from the information of the temporary custom system image.

[0202] Figure 4 This is a schematic diagram of a special system disk mounting backup process for an adaptive backup and recovery method for a cloud server service system disk provided in one embodiment of this application. For the special system disk mounting backup process, when the system disk adopts a mounting backup strategy, the system executes the following steps:

[0203] Create a system disk snapshot for the system disk to be backed up.

[0204] Query the original image information to obtain the system architecture, operating system type, operating system version, and boot mode.

[0205] If the original image has been deleted or is unavailable, a custom image is temporarily created based on the system disk snapshot, and the system architecture, operating system type, operating system version, and boot mode are obtained from this temporary image.

[0206] Create a temporary cloud disk based on a system disk snapshot.

[0207] Mount the temporary cloud disk to the backup agent machine.

[0208] ECSAgent reads data from temporary cloud disks in blocks.

[0209] For special system disks, the number of shards is forced to be 1, so that the read range covers the entire disk range from offset 0 to the end of the system disk capacity.

[0210] The read data is written to the backup storage to form a single raw full-disk system disk backup piece.

[0211] Write the architecture, os_type, os_version, and boot_mode to the extended attributes of the system disk backup piece.

[0212] Uninstall the temporary cloud disk and clean up the temporary cloud disk, system disk snapshot, and temporary image.

[0213] This process does not rely on the Volcano Engine's ExportImage capability, so it can overwrite Windows, Red Hat, and SUSE system disks that cannot be exported to TOS.

[0214] Specifically, the special system disk mounting backup process corresponds to the second backup operation. It is applicable to system disks that are determined by the policy selection module to not support image export, namely system disks of operating systems such as Windows, Red Hat, and SUSE. The principle of this process is to bypass the dependence on the image export interface, and instead create a temporary cloud disk and mount it to the backup agent machine to read all block-level data on the disk. At the same time, it obtains and saves the auxiliary recovery information required to import the image during recovery, thereby completing the preservation of system disk data and the collection of information required for recovery without using image export capabilities.

[0215] After the strategy selection module determines to adopt the mount backup strategy, the system first creates a second snapshot of the system disk to be backed up. The purpose of snapshot creation is the same as the image export backup process, that is, to obtain a consistent data snapshot without affecting the operation of the original cloud host. After the snapshot is created, the system enters the auxiliary recovery information acquisition stage. The system queries the original image information of the target cloud host service. This original image is automatically generated by the cloud platform when the cloud host instance is created or is a base image specified by the user. From the original image information, the system can obtain four types of auxiliary recovery information: system architecture, operating system type, operating system version, and boot mode. If the query finds that the original image has been deleted or is unsearchable, or that some auxiliary recovery information fields are missing from the original image information, the system activates a backup plan: based on the second snapshot, it temporarily calls the image creation interface to generate a temporary custom system image, extracts the required auxiliary recovery information from the information of this temporary custom system image, and deletes the temporary custom system image after extraction. This backup plan takes advantage of the fact that the image creation interface supports various operating systems, indirectly obtaining the parameters required for recovery by temporarily creating an image. After the auxiliary recovery information is acquired, the system creates a temporary cloud disk based on the second snapshot and calls the cloud platform interface to mount the temporary cloud disk to the backup agent machine. After mounting, the backup agent performs block-by-block data read operations on the temporary cloud disk. It's important to note that this differs from data disk backup in that the system forcibly sets the number of shards parameter to a preset fixed value for the special system disk, for example, setting it to 1. This ensures that a single data read covers the entire disk range from the starting offset to the end of the system disk's capacity, thus generating a single full-disk block data file, rather than the concurrent shard read method commonly used in data disk backup. The design consideration for full-disk single-block read is that this file needs to be used as input to the image import interface during recovery, and the image import interface typically accepts a single complete image file; therefore, the backup output should be a complete full-disk data file. The backup agent stores the read data as a second backup file in the backup storage system and writes auxiliary recovery information into the corresponding extended attribute fields of the second backup file, binding the backup data and recovery parameters to the same backup set. After the backup is complete, the system unmounts the temporary cloud disk and cleans up the temporary cloud disk, the second snapshot, and any temporary images generated during the process.

[0216] The second backup operation provided in this embodiment, targeting system disks that do not support image export, creates a second snapshot and a temporary cloud disk based on the snapshot. This temporary cloud disk is then mounted to the backup agent to perform block-by-block data read operations, bypassing the dependency on the image export interface and enabling data preservation for such system disks. The number of fragments in the block-by-block data read operation is set to a preset fixed value, ensuring that a single read covers the entire disk. The generated second backup file is a single full-disk data file, facilitating its use as input for subsequent image import. When obtaining auxiliary recovery information, it is preferentially extracted from the original image information. When the original image information is unavailable or partially missing, a temporary custom system image is generated based on the second snapshot using the image creation interface to extract auxiliary recovery information. This provides an alternative path for obtaining auxiliary recovery information and avoids the problem of being unable to import the image during the recovery phase due to missing original image information. The auxiliary recovery information is written into the corresponding extended attribute fields of the second backup file, binding the backup data with the parameters required for recovery. During recovery, it can be directly read from the backup set metadata. The step of unloading the temporary cloud disk clarifies the resource usage boundaries of the second backup operation. Therefore, this implementation method bypasses the limitations of image export while ensuring all the information required to generate a bootable system image during the recovery phase.

[0217] As an optional implementation, in response to the recovery task, the unified recovery process via the system disk uses the first backup file or the second backup file as input data, combines the auxiliary recovery information, and calls the cloud platform image import interface to generate a target custom system image, including:

[0218] Read the backup file path corresponding to the system disk to be restored and the auxiliary recovery information from the backup set metadata associated with the recovery task;

[0219] Read the first backup file or the second backup file according to the backup file path, and upload it to the target object storage service to obtain the corresponding object storage access identifier;

[0220] Call the cloud platform image import interface, and use the object storage access identifier and the auxiliary recovery information as input parameters of the image import interface to generate the target custom system image;

[0221] When the target custom system image reaches a usable state, the following steps are triggered: according to the recovery mode indicated by the recovery task, the target custom system image is used to perform the corresponding system disk recovery process on the target location.

[0222] Figure 5This is a schematic diagram of the unified system disk recovery process for the adaptive backup and recovery method of the cloud server service system disk provided in one embodiment of this application. During the unified system disk recovery process, the system disk adopts a unified image import recovery process.

[0223] Locate the system disk backup piece in the backup set catalog.

[0224] Read the system disk backup disk path and extended attributes.

[0225] Read the system disk backup fragment from backup storage.

[0226] Upload the system disk backup to TOS.

[0227] Get the uploaded image_uri.

[0228] Call the Volcano Engine ImportImage interface to import the system disk backup file in TOS as a custom system image.

[0229] Waiting for the custom system image to become usable.

[0230] Create a new ECS instance or replace the target instance's system disk based on the recovery mode.

[0231] Regardless of whether the system disk backup is an image file exported from a regular system disk or a raw full-disk file formed by mounting a backup from a special system disk, it is uniformly converted into a Volcano Engine custom system image during the recovery stage.

[0232] The unified system disk recovery process is a crucial part of the recovery phase. Its task is to convert two types of backup files with different formats generated during the backup phase—image files exported from ordinary system disks and full-disk block data files formed by mounting backups on special system disks—into a target custom system image that can be recognized by the cloud platform through a unified processing flow. This allows the recovery orchestration logic to operate without distinguishing between backup sources.

[0233] The principle and logic of this process are as follows: After the recovery task starts, the recovery orchestration module reads the backup file path and auxiliary recovery information corresponding to the system disk to be recovered from the backup set directory metadata associated with the recovery task. The backup set directory metadata serves as an index for the recovery task, providing all the location and parameter information required for recovery. The system reads the backup file from the backup storage system based on the backup file path. This backup file may be an image format file generated by the first backup operation or a block data format file generated by the second backup operation. After reading the backup file, the system uploads it to the target object storage service. After the upload operation is complete, the object storage service assigns an object storage access identifier to the uploaded file. This access identifier is used to specify the source location of the input file in subsequent image import interface calls. The system then calls the cloud platform image import interface, submitting the object storage access identifier and the auxiliary recovery information read from the directory metadata as input parameters. Parameters such as system architecture, operating system type, operating system version, and boot mode in the auxiliary recovery information provide the necessary configuration information for the image import interface to generate a bootable system image. After calling the image import interface, the image import process is executed asynchronously on the cloud platform side. The system sends query requests to the cloud platform at preset time intervals to poll and obtain the generation status of the target custom system image. When the query returns a status indicating that the target custom system image has reached a usable state, the system confirms that the image import process is complete. At this point, regardless of whether the original backup file was the first or second backup file, it has been successfully converted into the same standardized target custom system image, and the recovery orchestration module can perform subsequent recovery operations based on this image. This process, through two key steps—object storage upload and image import—converges two different backup paths into a single processing flow during the recovery phase, achieving unified recovery logic.

[0234] Figure 6 This diagram illustrates the backup metadata storage process of an adaptive backup and recovery method for a cloud server service system disk according to one embodiment of this application. It should be noted that in the aforementioned backup process, after backup is completed, the system writes each backup piece to the backup set catalog. For system disks, especially special system disks, the catalog needs to contain the extended attributes required for recovery.

[0235] The key fields are shown in Table 1:

[0236] Table 1

[0237]

[0238] Special system disk recovery depends on architecture, os_type, os_version, and boot_mode. If these fields are missing, raw full disk backups may not be imported into a bootable custom system image by the Volcano Engine.

[0239] The backup metadata saving process is the metadata recording step performed after the backup data is written to the backup storage system. Its task is to establish the directory metadata structure of the backup set, and to structurally register information such as the storage location of the backup data, fragment information, source volume identifier, and extended attributes required for recovery, so as to provide accurate data location and parameter reading basis for subsequent recovery tasks.

[0240] After the backup task completes all data read and storage operations on the system disk and data disk, the backup metadata management module begins the metadata saving process. The system writes the information of each backup piece into the directory metadata of the backup set. The directory metadata is a data structure that records all backup files and their attributes generated by a backup task. For each backup piece, the fields included in the directory metadata and their respective technical functions are as follows: The source volume identifier field is used to match the backup piece with the target system disk or data disk during recovery, ensuring that the recovery operation restores the correct backup data to the correct target disk; the backup piece path field records the storage location of the backup file in the backup storage system, and the recovery task locates and reads the backup file through this path; the backup piece size field records the number of bytes in the backup file, used in transfer progress statistics and import parameter calculations; the fragment sequence number field is used when backing up multiple data disk fragments for fragment sorting and combination during the recovery phase; the fragment offset field records the starting position of the fragment on the source disk, and the data is written back to the corresponding position on the target cloud disk based on this offset during recovery; the cloud host identifier field is used for task statistics and recovery association, enabling the backup piece to be traced back to its respective cloud host instance; the backup piece name field serves as the identifier for the backup file, used when generating the object name for object storage uploads, ensuring the consistency of the uploaded file name. For system disk backups, especially second backup files generated by mounting backup paths on special system disks, the directory metadata needs to additionally record four types of extended attribute fields: system architecture field, operating system type field, operating system version field, and boot mode field. These four fields are mandatory parameters in the image import interface call during the recovery phase; their absence will prevent the block data file from being successfully imported into a bootable custom system image. The metadata saving process occurs at the end of the backup phase. It undertakes the writing of backup data, provides data indexes and parameter sources for the recovery phase, and serves as a crucial bridge connecting backup and recovery.

[0241] Before reading the backup file path corresponding to the system disk to be restored and the auxiliary recovery information from the backup set metadata associated with the recovery task, the method further includes:

[0242] Parse the extended attribute fields recorded in the metadata of the backup set;

[0243] When the extended attribute field contains data items associated with system architecture and boot mode, it is determined that the system disk to be restored corresponds to the second backup file, and the auxiliary recovery information is read from the extended attribute field;

[0244] When there are no data items associated with system architecture and boot mode in the extended attribute field, it is determined that the system disk to be restored corresponds to the first backup file.

[0245] Clearly, backup metadata has the practical value of identifying and partitioning system disk types.

[0246] The unified system disk recovery process described in this embodiment first reads the backup file path and auxiliary recovery information from the backup set metadata, ensuring accurate identification of the backup data storage location and parameters required for image import during the recovery phase, with clear reading criteria. The first or second backup file is uploaded to the target object storage service, and an object storage access identifier is obtained, allowing different types of backup files to be provided to the image import interface in a unified manner. When calling the image import interface, the object storage access identifier and auxiliary recovery information are passed together, enabling either the image file or the full disk data file to be converted into a target custom system image with the assistance of the auxiliary recovery information. This unifies the recovery entry point and conversion path for both types of backup products. Subsequent recovery processing is triggered only after the target custom system image reaches a usable state, ensuring that image resources are ready when the recovery operation is executed. Therefore, this embodiment, through a unified metadata reading, object storage upload, and image import process, converts the first and second backup files, which have different forms, into the same standard intermediate form, eliminating the need for subsequent recovery operations to distinguish the backup source.

[0247] As an optional implementation, the method further includes:

[0248] Create a data disk snapshot for the target cloud host service's data disk;

[0249] A temporary data disk is created based on the data disk snapshot, and the temporary data disk is mounted to the backup agent machine;

[0250] Based on the preset concurrent processing quantity parameters and the storage capacity of the data disk, the read range corresponding to each shard is calculated, and the backup agent concurrently reads the data from the temporary data disk according to the read range corresponding to each shard.

[0251] The concurrently read data of each shard is written to the backup storage system, and the backup metadata management module records the source volume identifier, storage path, shard offset, shard size and shard sequence number corresponding to each data disk backup shard.

[0252] After the concurrent read operation is completed, the temporary data disk and the data disk snapshot are cleaned up.

[0253] Please see Figure 7 , Figure 7 This is a schematic diagram of the data disk backup process of the adaptive backup and recovery method for the cloud host service system disk provided in one embodiment of this application. For the data disk backup, this application also provides a corresponding implementation method, which is executed in conjunction with the system disk recovery during the recovery process.

[0254] Data disks are not included in the system disk policy selection; a snapshot temporary cloud disk mounting and backup process is uniformly adopted.

[0255] Create a data disk snapshot for each data disk.

[0256] Create a temporary data disk based on a data disk snapshot.

[0257] Mount the temporary data disk to the backup agent machine.

[0258] The sharding range is calculated based on the number of concurrent workers and the data disk capacity.

[0259] ECSAgent concurrently reads data from each shard and writes it to backup storage.

[0260] The backup metadata management module records the source volume ID, path, offset, fragment size, and fragment sequence number of the data disk backup fragments.

[0261] Clean up temporary data disks and data disk snapshots.

[0262] Specifically, the data disk backup process is independent of the system disk's strategy selection logic within the overall solution. Data disks uniformly employ snapshot and temporary cloud disk mounting backup methods and do not participate in the operating system type determination process. The principle of this process is similar in overall approach to the mounting backup process of a special system disk; both involve creating a temporary cloud disk through snapshots and mounting it to the backup agent for block-level reading. However, there are significant differences in the sharding strategy compared to the system disk. Data disks use concurrent sharding reads to improve backup efficiency, while system disks use forced single-shard reads to generate a complete full-disk file.

[0263] During the backup task, the system retrieves a list of data disks for the target cloud host service from the instance information query results and performs backup operations on each data disk in the list sequentially. For each data disk, the system first creates a data disk snapshot, then calls the cloud platform interface based on the data disk snapshot to create a temporary data disk, and mounts the temporary data disk to the backup agent. After mounting, the system calculates the read range corresponding to each shard based on the preset concurrent processing quantity parameters and the storage capacity of the data disk. Specifically, the total capacity of the data disk is divided according to the concurrent processing quantity, and each shard corresponds to a continuous range of disk logical addresses, including the start offset and end offset of the shard. Different processing threads or processes execute read operations in parallel between the shards, making full use of the concurrent processing capabilities of the backup agent. The backup agent concurrently reads data from the temporary data disk according to the read range corresponding to each shard and writes the data of each shard to the backup storage system. The backup metadata management module records the source volume identifier, storage path, fragment offset, fragment size, and fragment sequence number for each data disk backup fragment. This information is used during recovery to write each fragment back to its corresponding location on the target data disk in sequence. After concurrent read operations are completed, the system unmounts the temporary data disk and calls the resource deletion interface to clean up the temporary data disk and data disk snapshot. The data disk backup process is similar to the special system disk mounting backup process in terms of snapshot creation and temporary cloud disk mounting steps, but the difference lies in the reading method: data disks are read concurrently in fragments, while system disks are forced to be read as a single full disk.

[0264] As an optional implementation, the recovery modes include new instance recovery, original machine recovery, and disk overwrite recovery. The step of performing corresponding system disk recovery processing on the target location using the target custom system image, based on the recovery mode indicated by the recovery task, includes:

[0265] When the recovery mode is new instance recovery, the target custom system image is imported according to the unified recovery process of the system disk, the preset instance configuration parameters are obtained, and the identifier of the target custom system image and the instance configuration parameters are passed to the cloud platform to create an instance to create a new cloud host service instance.

[0266] The system disk of the new cloud host service instance is generated based on the target custom system image;

[0267] When the recovery mode is original machine recovery, query the original instance and currently mounted cloud disk information of the target cloud host service, verify that the original instance is consistent with the cloud host identifier recorded in the backup set, and that the list of cloud disk identifiers currently mounted by the original instance corresponds to the source volume identifier recorded in the backup set. Then, stop the operation of the original instance, keep the system disk of the original instance mounted on the original instance, import the target custom system image according to the unified system disk recovery process, call the system disk replacement interface of the cloud platform, and replace the system disk of the original instance based on the imported target custom system image.

[0268] When the recovery mode is disk overwrite recovery, query the pending cloud host service instance and pending cloud disk information, stop the operation of the pending cloud host service instance, remove the system disk of the pending cloud host service instance from the ordinary cloud disk mount write-back list, import the target custom system image according to the unified system disk recovery process, call the cloud platform's system disk replacement interface, and replace the system disk of the pending cloud host service instance based on the imported target custom system image.

[0269] During backup, the data disk does not participate in the strategy selection corresponding to the operating system type, and uniformly adopts snapshot and temporary cloud disk mounting backup methods; the data disk is read in a concurrent sharding manner during backup, which is different from the system disk, which sets the shard number parameter to a fixed value during mounting backup so that a single data read covers the entire disk range; the data disk is mounted to the backup agent and written back during recovery, which is different from the system disk, which generates a target custom system image by calling the cloud platform image import interface and restores based on the target custom system image.

[0270] When the recovery mode is a newly created instance recovery, a new data disk is created and mounted to the backup agent. The backup data of the data disk is read from the backup storage system and written back to the new data disk. After the write-back operation is completed, the new data disk is unmounted from the backup agent and mounted to the newly created cloud host service instance.

[0271] When the recovery mode is original machine recovery, query the original cloud host service instance and the currently mounted cloud disk information, stop the operation of the original cloud host service instance, unmount the data disk to be recovered from the original cloud host service instance and mount it to the backup agent machine, read the backup data corresponding to the data disk from the backup storage system and write it back to the data disk. After the write-back operation is completed, unmount the data disk from the backup agent machine and remount it to the original cloud host service instance.

[0272] When the recovery mode is disk overwrite recovery and the recovery object is a data disk, query the target cloud host service instance and target cloud disk information, stop the operation of the target cloud host service instance, unmount the target data disk from the target cloud host service instance, mount it to the backup agent, read the backup data from the backup storage system and write it back to the target data disk. After the write-back operation is completed, unmount the target data disk from the backup agent and remount it to the target cloud host service instance.

[0273] Figure 8 A schematic diagram of the new instance recovery process of the adaptive backup and recovery method for the system disk of a cloud server service provided in one embodiment of this application; Figure 9 A schematic diagram of the original machine recovery process of the adaptive backup and recovery method for the system disk of a cloud host service provided in one embodiment of this application; Figure 10 This is a schematic diagram of the disk overwrite recovery process of the adaptive backup and recovery method for the system disk of a cloud host service provided in one embodiment of this application; the following is a schematic diagram of the disk overwrite recovery process. Figures 8 to 10 The relevant implementation methods are described in detail, including three recovery modes.

[0274] For the recovery process of a newly created ECS instance, when the recovery mode is recovery of a newly created ECS instance, the system performs the following steps:

[0275] Import a custom system image using the unified system disk recovery process.

[0276] Configure the instance name, instance specifications, availability zone, VPC, subnet, security group, billing method, and system disk specifications according to the recovery target.

[0277] Enter the imported custom system image ID into the instance creation parameters.

[0278] Call the Volcano Engine instance creation interface to create a new ECS instance.

[0279] Create the target data disk and mount it to the backup agent machine.

[0280] Read the data disk backup piece from the backup storage and write it to the target data disk.

[0281] Mount the restored data disk to the new ECS instance.

[0282] Whether to start a new ECS instance depends on the user's configuration.

[0283] The new recovery process is the first of the three recovery modes. The principle of this process is to use the target custom system image generated by the unified system disk recovery process as the system disk template, and combine it with the user's preset instance configuration parameters to create a brand new cloud host service instance through the cloud platform's instance creation interface.

[0284] The recovery orchestration module first executes a unified system disk recovery process, importing the backup file as the target custom system image and waiting for the image to reach a usable state. Once the image is ready, the system reads the instance configuration parameters preset by the user in the recovery task. These parameters include instance name, instance specifications, availability zone, private network, subnet, security group, billing method, and system disk specifications, used to define the various attributes of the newly created cloud server instance. The system uses the identifier of the target custom system image and the aforementioned instance configuration parameters as parameters to call the cloud platform's instance creation interface. The instance creation interface executes the instance creation process on the cloud platform side, where the source of the system disk is specified as the target custom system image. Therefore, the system disk content of the newly created cloud server service instance is consistent with the source system disk content during backup. After the instance creation interface returns, the new cloud server service instance is in a created state. Subsequently, the system creates a new data disk and mounts it to the backup agent. The backup agent reads the backup data from the data disk from the backup storage system and writes the backup data back to the new data disk. After the write-back operation is complete, the backup agent unmounts the new data disk and mounts it to the newly created cloud server service instance. After the data disk recovery is complete, the system determines whether to start the new cloud server service instance based on the startup options configured by the user in the recovery task. The new recovery process is executed after the unified system disk recovery process. The system disk recovery relies on the image import and instance creation interface, while the data disk recovery relies on the proxy machine write-back method. The processing paths for the two types of disks are independent and parallel.

[0285] For the original machine recovery process, when the recovery mode is original machine recovery, the system performs the following steps:

[0286] Query the original ECS instance and the currently mounted cloud disk information.

[0287] Verify whether the relationships between the original instance and the instances and cloud disks in the backup set meet the recovery conditions.

[0288] Stop the original ECS instance.

[0289] Unmount the data disk that needs to be restored from the original instance and mount it to the backup agent machine.

[0290] Read the data disk backup piece from the backup storage and write it back to the data disk.

[0291] After the data disk is restored, it will be mounted back to the original ECS instance.

[0292] The system disk is not uninstalled directly from the original instance.

[0293] Import a custom system image using the unified system disk recovery process.

[0294] Call the Volcano Engine ReplaceSystemVolume interface to replace the original instance system disk based on the imported custom system image.

[0295] Whether to start the original ECS instance depends on the user's configuration.

[0296] The original machine recovery process is the second of the three recovery modes. The principle of this process is to use the target custom system image generated by the unified recovery process of the system disk to replace the system disk of the original instance through the system disk replacement interface, and at the same time restore the data disk by mounting the agent machine to write back.

[0297] After the recovery task starts, the system first queries the original instance and currently mounted cloud disk information of the target cloud host service to obtain the original instance's identifier, the list of currently mounted cloud disk identifiers, and other configuration information. After the query is complete, the system performs a verification operation, comparing the original instance's identifier with the cloud host identifiers recorded in the backup set to confirm the consistency between the recovery target and the backup source. Simultaneously, it compares the list of currently mounted cloud disk identifiers of the original instance with the source volume identifiers recorded in the backup set to confirm that the backup set records the backup data for the corresponding cloud disk. After successful verification, the system stops the original instance, putting the instance into a stopped state. After the instance stops, the recovery methods for system disks and data disks diverge. For data disks, the system unmounts the data disks to be recovered from the original instance and mounts them to the backup agent. The backup agent reads the corresponding backup data from the backup storage system and writes it back to the data disk. After the write-back operation is complete, the backup agent unmounts the data disks and remounts them to the original instance. For system disks, the system's processing method is completely different; the system disks are not unmounted from the original instance but remain mounted to it. The system executes a unified system disk recovery process, importing the backup file as a target custom system image. Once the image is usable, it calls the cloud platform's system disk replacement interface to replace the original instance's system disk with a system disk generated based on the imported target custom system image. The system disk replacement interface performs the system disk replacement operation internally within the cloud platform. After the replacement is complete, the original instance's operating system environment is rolled back to its state at the time of backup. After both the system disk and data disk are restored, the system decides whether to start the original instance based on user configuration. During the original machine recovery process, the processing paths for the system disk and data disk are separated. The system disk is restored via interface replacement, while the data disk is restored via mount write-back. This design adheres to the cloud platform's specific restrictions on system disk operations.

[0298] For disk overwrite recovery, when the recovery mode is disk overwrite recovery, the system performs the following steps:

[0299] Query the target ECS instance and target cloud disk information.

[0300] Stop the target ECS instance.

[0301] If the object to be restored is a data disk, the target data disk is unmounted from the instance, mounted to the agent machine, the backup data is written back, and then it is mounted back to the target instance.

[0302] If the object to be restored is the system disk, then the system disk will be removed from the list of regular cloud disks to be mounted and written back.

[0303] Import a custom system image using the unified system disk recovery process.

[0304] Call the ReplaceSystemVolume interface to replace the target instance's system disk.

[0305] Whether to start the target ECS instance depends on the user's configuration.

[0306] Disk overwrite recovery is the third of the three recovery modes. The principle of this process is to use different recovery paths depending on the type of the object being recovered: when the object being recovered is a data disk, the method of writing back by mounting a proxy machine is used; when the object being recovered is a system disk, the method of image import and system disk replacement interface is used.

[0307] After the recovery task starts, the system first queries the target cloud host service instance and target cloud disk information to obtain the identifier of the instance to be processed, the list of currently mounted cloud disks, and the type information of each cloud disk. After the query is completed, the system stops the operation of the target cloud host service instance. After the instance stops, the system performs branch processing according to the recovery object. When the recovery object is a data disk, the system unmounts the target data disk from the target cloud host service instance and mounts it to the backup agent. The backup agent reads the backup data from the backup storage system and writes it back to the target data disk. After the write-back operation is completed, the backup agent unmounts the target data disk and remounts it to the target cloud host service instance. When the recovery object is a system disk, the system's processing method is fundamentally different from that of data disk recovery. In this case, the system removes the system disk from the list of ordinary cloud disk mounts and write-backs, meaning that the system disk does not participate in the mount and write-back process. The system executes a unified system disk recovery process, imports the backup file as a target custom system image, and after the image reaches a usable state, calls the cloud platform's system disk replacement interface to replace the system disk of the target cloud host service instance with a system disk generated based on the imported target custom system image. During this process, the system disk remains mounted on the target cloud host service instance. The recovery process for the system disk differs from that for the data disk. This difference reflects the varying resource operation permissions between system and data disks on the cloud platform. The system disk cannot be arbitrarily mounted and unmounted like a data disk; it can only be replaced through a dedicated system disk replacement interface. After disk recovery is complete, the system determines whether to start the target cloud host service instance based on user configuration. The disk overwrite recovery process includes a conditional branch that determines the subsequent processing path based on whether the recovery object is a data disk or a system disk. Data disks follow the mount write-back path, while system disks follow the image import and replacement interface path.

[0308] This implementation refines the recovery mode into three types: new instance recovery, original machine recovery, and disk overwrite recovery, allowing the recovery operation to select the corresponding processing path according to actual needs. In new instance recovery mode, the identifier of the target custom system image and instance configuration parameters are passed to the instance creation interface. The system disk of the new cloud host service instance is generated from the target custom system image, ensuring that the recovered instance has a system environment consistent with the backup source from the outset. In original machine recovery mode, the correspondence between the original instance and the list of cloud host identifiers and cloud disk identifiers recorded in the backup set is first verified to ensure that the recovery target matches the backup source before proceeding with subsequent operations. After successful verification, the original instance is stopped, and the system disk of the original instance remains mounted on the original instance. The system disk is replaced based on the imported image through the system disk replacement interface. No unmounting or mounting operations occur during the system disk recovery process, complying with the cloud platform's operational constraints on system disks. In disk overwrite recovery mode, the system disk is removed from the list of ordinary cloud disks mounted and written back. Recovery is completed through a unified image import and system disk replacement interface. The system disk is handled differently from the data disk. Therefore, in all three recovery modes, this implementation uses the target custom system image as an intermediate form for system disk recovery, and the system disk processing methods in original machine recovery and disk overwrite recovery follow the special restrictions of the cloud platform on system disk operations.

[0309] As an optional implementation, the method further includes a temporary resource cleanup step, specifically including:

[0310] During the execution of the backup task or the recovery task, task context information is maintained;

[0311] The task context information is used to record the identifiers of temporary resources created during task execution. These temporary resources include snapshot resources, temporary cloud disk resources, temporary image resources, or temporary object resources.

[0312] After the backup task or the recovery task is completed, the identifiers of each temporary resource recorded in the task context information are traversed, and the corresponding resource deletion interface is called to clear each temporary resource.

[0313] Figure 11 This diagram illustrates the temporary resource cleanup process of an adaptive backup and recovery method for a cloud server service system disk provided in one embodiment of this application. Snapshots, temporary cloud disks, temporary custom images, TOS temporary objects, and proxy machine mounting relationships created during the backup and recovery task are all registered in the task context. When the task ends, fails, or is canceled, the system cleans up temporary resources according to the task context.

[0314] After a successful recovery, the new instance and target data disk are marked as persistent resources and will no longer be deleted as temporary resources. Imported images and TOS temporary objects remain temporary resources during the recovery process and will be cleaned up after the task ends.

[0315] For example, after the backup task is completed, the first snapshot, the first custom system image, and the temporary objects in the target object storage service can be cleaned up, or the temporary cloud disk can be uninstalled and the temporary cloud disk, the second snapshot, and the temporary image generated during the process can be cleaned up, or the aforementioned temporary custom system image can be deleted.

[0316] The temporary resource cleanup process is an auxiliary step that runs through the entire backup and recovery process. Its task is to uniformly register all kinds of temporary cloud resources created during the execution of backup or recovery tasks, and to deterministically remove them after the task ends, so as to prevent quota occupation and storage space waste caused by temporary resource residues.

[0317] During the execution of backup or recovery tasks, the system maintains a task context information structure. Whenever a temporary resource is created during the task flow, such as a snapshot resource, temporary cloud disk resource, temporary image resource, or object storage temporary transfer object, the system registers the resource's identifier in the task context information. The task context information serves as a resource list, recording the identifiers and types of all temporary resources generated during the task that need to be cleaned up. Temporary resources that may be created in a backup task include: snapshot resources generated when creating a system disk snapshot; temporary cloud disk resources generated when creating a temporary cloud disk based on a snapshot; backup custom system image resources generated by calling the create image interface during a regular system disk backup; and temporary object resources generated in object storage when exporting an image to object storage service. Temporary resources that may be created in a recovery task include: temporary object resources generated when uploading backup files to object storage service; temporary image resources that may be generated when calling the image import interface to generate a target custom system image; and temporary mount relationships mounted during data disk recovery for writing back data. Newly created cloud host instances and target data disks are marked as persistent resources after successful creation and recovery and are not included in the scope of temporary resource cleanup. Importing the target custom system image generated by the image import interface and the temporary transit objects in the object storage service, these remain temporary resources after the recovery task is completed and require cleanup. After the backup or recovery task ends, regardless of whether the task ends normally, fails, or is canceled, the system iterates through the identifiers of various temporary resources recorded in the task context information and sequentially calls the corresponding cloud platform resource deletion interface to clear snapshot resources, temporary cloud disk resources, temporary image resources, and temporary object resources one by one. The cleanup order is usually arranged according to resource dependencies; for example, unmounting the temporary cloud disk first, then deleting the temporary cloud disk, and finally deleting the snapshot, to avoid deletion failures due to dependencies. The temporary resource cleanup process is at the end of the entire task flow, but it covers temporary resources generated in each step of the backup process and temporary resources generated in the recovery process, making it a global closing step.

[0318] This implementation maintains task context information during the execution of backup or recovery tasks, uniformly registering the identifiers of snapshot resources, temporary cloud disk resources, temporary image resources, and temporary object resources generated during the task. This ensures that all types of temporary resources are included in the management scope, preventing residual resources due to forgetfulness or omission. After the task ends, the identifiers of each temporary resource recorded in the task context information are iterated, and the corresponding resource deletion interface is called sequentially for cleanup. The scope and objects of cleanup are traceable. Because the cleanup operation is performed uniformly after the task ends, it does not rely on scattered calls to cleanup logic in various specific steps. The centralized timing of cleanup reduces the risk of missed cleanup. The coordination between the maintenance of task context information and the cleanup process ensures that the lifecycle of temporary resources is consistent with the task execution cycle. Temporary resources are reclaimed immediately after the task ends, reducing cloud resource occupation and storage space waste.

[0319] Based on the above embodiments, this application achieves the following technical effects:

[0320] Improve the success rate of backups for special system disks in Volcano Engine. For system disks such as Windows, Red Hat, and SUSE that cannot export images to TOS, ExportImage is no longer used. Instead, a temporary cloud disk is created by taking a snapshot of the system disk and mounted on a proxy machine for reading, thus bypassing the image export restriction.

[0321] The efficiency and integrity of the export path for regular system disk images are preserved. For regular system disks that support image export, the CreateImage and ExportImage methods are still used to avoid all system disks degenerating into full-disk block-level backups.

[0322] Ensure that special system disks can be imported during recovery. When backing up a special system disk, the system architecture, operating system type, operating system version, and boot mode are saved, allowing raw full-disk files to be imported as a custom system image via ImportImage during recovery.

[0323] This enables unified recovery of two types of system disk backup results. Both ordinary system disk image files and special system disk raw full disk files are converted into custom system images by uploading TOS and ImportImage, thus unifying the recovery orchestration logic.

[0324] Supports new recovery, original recovery, and disk overwrite recovery. New recovery creates an ECS instance based on the imported image; original recovery and disk overwrite recovery replace the system disk by calling ReplaceSystemVolume based on the imported image.

[0325] This reduces the risk of failure caused by mixing system disks and data disks. The system disk is restored through image import and system disk replacement, while the data disk is restored by writing back through a mounted proxy machine, which conforms to the resource differences between system disks and data disks in the Volcano Engine platform.

[0326] Maintain the efficiency of data disk sharding concurrency. The special strategy for the system disk only forces a full backup of the system disk as a single disk, while the data disk can still be split into backup shards and transmitted in parallel by concurrent workers.

[0327] Reduce the residual resources of temporary cloud resources. By registering and cleaning up snapshots, temporary cloud disks, temporary images, TOS objects, and mount relationships in the task context, the risk of resource residue after task failure or cancellation is reduced.

[0328] Reduce the complexity of the recovery logic. During the recovery phase, a custom system image is used as the intermediate form for system disk recovery, reducing the complexity of implementing recovery logic separately for ordinary system disks and special system disks.

[0329] Improve system bootability after recovery. By saving and using image import metadata, avoid imported images failing to boot due to missing boot modes or system architecture information.

[0330] This application also provides an adaptive backup and recovery device for a cloud server service system disk, the device comprising:

[0331] The processing module is used to obtain the operating system type information of the target cloud host service in response to a backup task for the target cloud host service;

[0332] The processing module is further configured to determine, based on the operating system type information, whether to perform a first backup operation or a second backup operation on the system disk of the target cloud host service;

[0333] The processing module is further configured to generate a first backup file through the first backup operation, or generate a second backup file through the second backup operation, and obtain auxiliary recovery information corresponding to the system disk of the target cloud host service when performing the second backup operation;

[0334] The processing module is also used to respond to the recovery task by using the first backup file or the second backup file as input data and combining the auxiliary recovery information to call the cloud platform image import interface to generate the target custom system image through the unified recovery process of the system disk;

[0335] The processing module is further configured to perform corresponding system disk recovery processing on the target location using the target custom system image, based on the recovery mode indicated by the recovery task.

[0336] The method provided in this embodiment first obtains the operating system type information of the target cloud host service when the backup task starts. Based on this information, it adaptively selects between two types of backup operations, enabling both system disks that support image export and those that do not to complete the backup through their respective suitable paths. This overcomes the problem of backup failure at the backup stage when using a fixed single backup method for a specific operating system. For system disks that do not support image export, auxiliary recovery information is simultaneously obtained during the second backup operation, allowing the subsequent recovery stage to successfully import block data files into a bootable system image. During the recovery stage, a unified system disk recovery process is used to combine the first or second backup file with the auxiliary recovery information and uniformly call the cloud platform image import interface to generate a target custom system image. This converts backup artifacts of different forms into a standardized intermediate form, unifying the recovery orchestration logic. Finally, according to the recovery mode indicated by the recovery task, the target custom system image is used to perform corresponding system disk recovery processing on the target location, enabling new instance recovery, original machine recovery, and disk overwrite recovery to be completed based on the same set of recovery intermediate states. Therefore, this implementation method achieves closed-loop backup and recovery of system disks of different operating system types through adaptive strategy selection, auxiliary information preservation, and unified recovery conversion, thereby improving backup success rate and recovery flexibility.

[0337] As an optional implementation, the processing module determines, based on the operating system type information, the specific method for performing a first backup operation or a second backup operation on the system disk of the target cloud host service, including:

[0338] Create a backup task processing object, and use the backup task processing object to perform a query operation on the instance information of the target cloud host service to be backed up, so as to obtain the operating system type information of the target cloud host service and record the original image identifier of the target cloud host service.

[0339] When the operating system type information indicates that the operating system corresponding to the target cloud host service belongs to a first preset type set, it is determined to perform a first backup operation on the system disk of the target cloud host service.

[0340] When the operating system type information indicates that the operating system corresponding to the target cloud host service belongs to the second preset type set, it is determined to perform a second backup operation on the system disk of the target cloud host service.

[0341] Among them, the operating systems in the first preset type set support exporting their own system images to the object storage service, while the operating systems in the second preset type set do not support exporting their own system images to the object storage service.

[0342] When the backup task processing object fails to execute the query operation, a preset rollback process is executed;

[0343] The rollback process includes directly performing the first backup operation on the corresponding system disk and generating an exception message related to the query operation.

[0344] This implementation method creates a backup task processing object and performs an instance information query operation to obtain operating system type information and record the original image identifier. This enables the backup system to accurately perceive the system environment characteristics of the cloud host to be backed up, providing a basis for subsequent strategy selection. The method uses whether the operating system supports exporting its own system image to the object storage service as the technical standard for dividing the first and second preset type sets. This ensures that strategy determination has clear and verifiable conditions, rather than relying on empirical rules or external configurations. When the query operation fails, a preset rollback process is executed, defaulting to the first backup operation and generating an exception message. This allows the backup process to continue even in scenarios with occasional information retrieval anomalies, avoiding task interruption. Furthermore, the generation of the exception message facilitates subsequent analysis and troubleshooting of the query failure. Therefore, this implementation method balances the accuracy of determination, the robustness of the process, and the traceability of anomalies in the strategy selection stage.

[0345] As an optional implementation, the specific method by which the processing module generates the first backup file through the first backup operation includes:

[0346] Create a first snapshot for the system disk of the target cloud host service;

[0347] Based on the first snapshot, the image creation interface is called to generate a backup custom system image, and the backup custom system image is waited for to reach a usable state.

[0348] Call the image export interface to export the backup custom system image to the target object storage service, obtain the object name and bucket name returned by the image export interface, and obtain the image file from the target object storage service based on the object name and bucket name;

[0349] The image file is stored in the backup storage system as the first backup file, and the backup metadata management module registers the image file as a system disk backup piece.

[0350] The first backup operation provided in this embodiment creates a first snapshot and generates a custom backup system image by calling the image creation interface based on the snapshot. After the image reaches a usable state, the image export interface is called to export it to the target object storage service. This allows the generation and export of the image file to be completed step-by-step, with each stage's state clearly defined and controllable. After obtaining the object name and bucket name returned by the image export interface, the image file is retrieved from the target object storage service based on the object name and bucket name and stored in the backup storage system. This ensures a clear path for the backup data and traceable storage location. The backup metadata management module registers the image file as a system disk backup piece, enabling the backup piece to be accurately located and read through the backup set metadata during the subsequent recovery phase. Therefore, this embodiment constructs a complete operation chain from snapshot creation to backup piece registration for system disks that support image export, ensuring that each step of the first backup operation is seamlessly connected, and that the source and storage location of the backup products are clearly recorded.

[0351] As an optional implementation, the processing module generates a second backup file through the second backup operation, and obtains auxiliary recovery information corresponding to the system disk of the target cloud host service during the execution of the second backup operation in the following specific ways:

[0352] Create a second snapshot for the system disk of the target cloud host service;

[0353] Query the original image information of the target cloud host service to obtain auxiliary recovery information corresponding to the system disk of the target cloud host service;

[0354] The auxiliary recovery information includes system architecture, operating system type, operating system version, and boot mode;

[0355] A temporary cloud disk is created based on the second snapshot, and the temporary cloud disk is mounted to the backup agent machine, which then performs block-by-block data read operations on the temporary cloud disk.

[0356] The number of shards corresponding to the block data read operation is a preset fixed value, which is used to ensure that the range of data read covers the entire disk range from the starting offset to the end of the system disk capacity.

[0357] The data obtained by the block data read operation is stored in the backup storage system as a second backup file;

[0358] Write the auxiliary recovery information into the extended attribute field corresponding to the second backup file;

[0359] Uninstall the temporary cloud disk;

[0360] Furthermore, the specific method by which the processing module queries the original image information of the target cloud host service and obtains the auxiliary recovery information corresponding to the system disk of the target cloud host service includes:

[0361] When the original image information of the target cloud host service is found and the original image information contains complete auxiliary recovery information, the auxiliary recovery information is extracted from the original image information.

[0362] When the original image information is not found or is partially missing, the image creation interface is temporarily invoked based on the second snapshot to generate a temporary custom system image, and the auxiliary recovery information is extracted from the information of the temporary custom system image.

[0363] The second backup operation provided in this embodiment, targeting system disks that do not support image export, creates a second snapshot and a temporary cloud disk based on the snapshot. This temporary cloud disk is then mounted to the backup agent to perform block-by-block data read operations, bypassing the dependency on the image export interface and enabling data preservation for such system disks. The number of fragments in the block-by-block data read operation is set to a preset fixed value, ensuring that a single read covers the entire disk. The generated second backup file is a single full-disk data file, facilitating its use as input for subsequent image import. When obtaining auxiliary recovery information, it is preferentially extracted from the original image information. When the original image information is unavailable or partially missing, a temporary custom system image is generated based on the second snapshot using the image creation interface to extract auxiliary recovery information. This provides an alternative path for obtaining auxiliary recovery information and avoids the problem of being unable to import the image during the recovery phase due to missing original image information. The auxiliary recovery information is written into the corresponding extended attribute fields of the second backup file, binding the backup data with the parameters required for recovery. During recovery, it can be directly read from the backup set metadata. The step of unloading the temporary cloud disk clarifies the resource usage boundaries of the second backup operation. Therefore, this implementation method bypasses the limitations of image export while ensuring all the information required to generate a bootable system image during the recovery phase.

[0364] As an optional implementation, the processing module, in response to the recovery task, uses the system disk unified recovery process, taking the first backup file or the second backup file as input data, and combining it with the auxiliary recovery information, calls the cloud platform image import interface to generate the target custom system image in the following specific ways:

[0365] Read the backup file path corresponding to the system disk to be restored and the auxiliary recovery information from the backup set metadata associated with the recovery task;

[0366] Read the first backup file or the second backup file according to the backup file path, and upload it to the target object storage service to obtain the corresponding object storage access identifier;

[0367] Call the cloud platform image import interface, and use the object storage access identifier and the auxiliary recovery information as input parameters of the image import interface to generate the target custom system image;

[0368] When the target custom system image reaches a usable state, the following steps are triggered: according to the recovery mode indicated by the recovery task, the target custom system image is used to perform the corresponding system disk recovery process on the target location.

[0369] The unified system disk recovery process described in this embodiment first reads the backup file path and auxiliary recovery information from the backup set metadata, ensuring accurate identification of the backup data storage location and parameters required for image import during the recovery phase, with clear reading criteria. The first or second backup file is uploaded to the target object storage service, and an object storage access identifier is obtained, allowing different types of backup files to be provided to the image import interface in a unified manner. When calling the image import interface, the object storage access identifier and auxiliary recovery information are passed together, enabling either the image file or the full disk data file to be converted into a target custom system image with the assistance of the auxiliary recovery information. This unifies the recovery entry point and conversion path for both types of backup products. Subsequent recovery processing is triggered only after the target custom system image reaches a usable state, ensuring that image resources are ready when the recovery operation is executed. Therefore, this embodiment, through a unified metadata reading, object storage upload, and image import process, converts the first and second backup files, which have different forms, into the same standard intermediate form, eliminating the need for subsequent recovery operations to distinguish the backup source.

[0370] As an optional implementation, the recovery modes include new instance recovery, original machine recovery, and disk overwrite recovery. The processing module, based on the recovery mode indicated by the recovery task, utilizes the target custom system image to perform the corresponding system disk recovery process on the target location in the following specific ways:

[0371] When the recovery mode is new instance recovery, the target custom system image is imported according to the unified recovery process of the system disk, the preset instance configuration parameters are obtained, and the identifier of the target custom system image and the instance configuration parameters are passed to the cloud platform to create an instance to create a new cloud host service instance.

[0372] The system disk of the new cloud host service instance is generated based on the target custom system image;

[0373] When the recovery mode is original machine recovery, query the original instance and currently mounted cloud disk information of the target cloud host service, verify that the original instance is consistent with the cloud host identifier recorded in the backup set, and that the list of cloud disk identifiers currently mounted by the original instance corresponds to the source volume identifier recorded in the backup set. Then, stop the operation of the original instance, keep the system disk of the original instance mounted on the original instance, import the target custom system image according to the unified system disk recovery process, call the system disk replacement interface of the cloud platform, and replace the system disk of the original instance based on the imported target custom system image.

[0374] When the recovery mode is disk overwrite recovery, query the pending cloud host service instance and pending cloud disk information, stop the operation of the pending cloud host service instance, remove the system disk of the pending cloud host service instance from the ordinary cloud disk mount write-back list, import the target custom system image according to the unified system disk recovery process, call the cloud platform's system disk replacement interface, and replace the system disk of the pending cloud host service instance based on the imported target custom system image.

[0375] This implementation refines the recovery mode into three types: new instance recovery, original machine recovery, and disk overwrite recovery, allowing the recovery operation to select the corresponding processing path according to actual needs. In new instance recovery mode, the identifier of the target custom system image and instance configuration parameters are passed to the instance creation interface. The system disk of the new cloud host service instance is generated from the target custom system image, ensuring that the recovered instance has a system environment consistent with the backup source from the outset. In original machine recovery mode, the correspondence between the original instance and the list of cloud host identifiers and cloud disk identifiers recorded in the backup set is first verified to ensure that the recovery target matches the backup source before proceeding with subsequent operations. After successful verification, the original instance is stopped, and the system disk of the original instance remains mounted on the original instance. The system disk is replaced based on the imported image through the system disk replacement interface. No unmounting or mounting operations occur during the system disk recovery process, complying with the cloud platform's operational constraints on system disks. In disk overwrite recovery mode, the system disk is removed from the list of ordinary cloud disks mounted and written back. Recovery is completed through a unified image import and system disk replacement interface. The system disk is handled differently from the data disk. Therefore, in all three recovery modes, this implementation uses the target custom system image as an intermediate form for system disk recovery, and the system disk processing methods in original machine recovery and disk overwrite recovery follow the special restrictions of the cloud platform on system disk operations.

[0376] As an optional implementation, the processing module is also used for temporary resource cleanup, specifically for:

[0377] During the execution of the backup task or the recovery task, task context information is maintained;

[0378] The task context information is used to record the identifiers of temporary resources created during task execution. These temporary resources include snapshot resources, temporary cloud disk resources, temporary image resources, or temporary object resources.

[0379] After the backup task or the recovery task is completed, the identifiers of each temporary resource recorded in the task context information are traversed, and the corresponding resource deletion interface is called to clear each temporary resource.

[0380] This implementation maintains task context information during the execution of backup or recovery tasks, uniformly registering the identifiers of snapshot resources, temporary cloud disk resources, temporary image resources, and temporary object resources generated during the task. This ensures that all types of temporary resources are included in the management scope, preventing residual resources due to forgetfulness or omission. After the task ends, the identifiers of each temporary resource recorded in the task context information are iterated, and the corresponding resource deletion interface is called sequentially for cleanup. The scope and objects of cleanup are traceable. Because the cleanup operation is performed uniformly after the task ends, it does not rely on scattered calls to cleanup logic in various specific steps. The centralized timing of cleanup reduces the risk of missed cleanup. The coordination between the maintenance of task context information and the cleanup process ensures that the lifecycle of temporary resources is consistent with the task execution cycle. Temporary resources are reclaimed immediately after the task ends, reducing cloud resource occupation and storage space waste.

[0381] It should be noted that the division of the various modules in the above device is merely a logical functional division. In actual implementation, they can be fully or partially integrated into a single physical entity, or they can be physically separated. Furthermore, these modules can be implemented entirely in software via processing element calls; they can be fully implemented in hardware; or some modules can be implemented by processing element calls to software, while others are implemented in hardware. For example, a processing module can be a separate processing element, or it can be integrated into a chip within the device. Alternatively, it can be stored as program code in the device's memory, and its functions can be called and executed by a processing element. The implementation of other modules is similar. Moreover, these modules can be fully or partially integrated together, or they can be implemented independently. The processing element here can be an integrated circuit with signal processing capabilities. During implementation, each step of the above method or each of the above modules can be completed through integrated logic circuits in the hardware of the processor element or through software instructions.

[0382] Indicatively, such as Figure 12 As shown, Figure 12 This is a schematic diagram of the internal structure of a computer device 300 provided in an embodiment of this application. The computer device 300 can be provided as a server. (Refer to...) Figure 12 The computer device 300 includes a processing component 302, which further includes one or more processors, and memory resources represented by memory 301 for storing instructions, such as application programs, that can be executed by the processing component 302. The application programs stored in memory 301 may include one or more modules, each corresponding to a set of instructions. Furthermore, the processing component 302 is configured to execute instructions to perform the methods of any of the embodiments described above.

[0383] The computer device 300 may also include a power supply component 303 configured to perform power management of the computer device 300, a wired or wireless network interface 304 configured to connect the computer device 300 to a network, and an input / output (I / O) interface 305. The computer device 300 may operate on an operating system stored in memory 301, such as Windows Server™, MacOSX™, Unix™, Linux™, FreeBSD™, or similar.

[0384] Those skilled in the art will understand that Figure 12 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0385] This application provides a storage medium storing computer-readable instructions that, when executed by one or more processors, cause the one or more processors to perform the method provided in any embodiment.

[0386] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0387] The various embodiments in this specification are described in a progressive manner. Each embodiment focuses on the differences from other embodiments. The various embodiments can be combined as needed, and the same or similar parts can be referred to each other.

[0388] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. An adaptive backup and recovery method for a cloud server service system disk, characterized in that, The method includes: In response to a backup task for a target cloud host service, obtain the operating system type information of the target cloud host service; Based on the operating system type information, determine whether to perform a first backup operation or a second backup operation on the system disk of the target cloud host service; A first backup file is generated through the first backup operation, or a second backup file is generated through the second backup operation, and auxiliary recovery information corresponding to the system disk of the target cloud host service is obtained when the second backup operation is performed; In response to the recovery task, the system disk is used to unify the recovery process. The first backup file or the second backup file is used as input data. Combined with the auxiliary recovery information, the cloud platform image import interface is called to generate the target custom system image. Based on the recovery mode indicated by the recovery task, the target custom system image is used to perform the corresponding system disk recovery process on the target location.

2. The method according to claim 1, characterized in that, The step of determining whether to perform a first backup operation or a second backup operation on the system disk of the target cloud host service based on the operating system type information includes: Create a backup task processing object, and use the backup task processing object to perform a query operation on the instance information of the target cloud host service to be backed up, so as to obtain the operating system type information of the target cloud host service and record the original image identifier of the target cloud host service. When the operating system type information indicates that the operating system corresponding to the target cloud host service belongs to a first preset type set, it is determined to perform a first backup operation on the system disk of the target cloud host service. When the operating system type information indicates that the operating system corresponding to the target cloud host service belongs to the second preset type set, it is determined to perform a second backup operation on the system disk of the target cloud host service. Among them, the operating systems in the first preset type set support exporting their own system images to the object storage service, while the operating systems in the second preset type set do not support exporting their own system images to the object storage service. When the backup task processing object fails to execute the query operation, a preset rollback process is executed; The rollback process includes directly performing the first backup operation on the corresponding system disk and generating an exception message related to the query operation.

3. The method according to claim 2, characterized in that, The process of generating the first backup file through the first backup operation includes: Create a first snapshot for the system disk of the target cloud host service; Based on the first snapshot, the image creation interface is called to generate a backup custom system image, and the backup custom system image is waited for to reach a usable state. Call the image export interface to export the backup custom system image to the target object storage service, obtain the object name and bucket name returned by the image export interface, and obtain the image file from the target object storage service based on the object name and bucket name; The image file is stored in the backup storage system as the first backup file, and the backup metadata management module registers the image file as a system disk backup piece.

4. The method according to claim 2, characterized in that, The process of generating a second backup file through the second backup operation and obtaining auxiliary recovery information corresponding to the system disk of the target cloud host service during the execution of the second backup operation includes: Create a second snapshot for the system disk of the target cloud host service; Query the original image information of the target cloud host service to obtain auxiliary recovery information corresponding to the system disk of the target cloud host service; The auxiliary recovery information includes system architecture, operating system type, operating system version, and boot mode; A temporary cloud disk is created based on the second snapshot, and the temporary cloud disk is mounted to the backup agent machine, which then performs block-by-block data read operations on the temporary cloud disk. The number of shards corresponding to the block data read operation is a preset fixed value, which is used to ensure that the range of data read covers the entire disk range from the starting offset to the end of the system disk capacity. The data obtained by the block data read operation is stored in the backup storage system as a second backup file; Write the auxiliary recovery information into the extended attribute field corresponding to the second backup file; Uninstall the temporary cloud disk; And, the step of querying the original image information of the target cloud host service and obtaining auxiliary recovery information corresponding to the system disk of the target cloud host service includes: When the original image information of the target cloud host service is found and the original image information contains complete auxiliary recovery information, the auxiliary recovery information is extracted from the original image information. When the original image information is not found or is partially missing, the image creation interface is temporarily invoked based on the second snapshot to generate a temporary custom system image, and the auxiliary recovery information is extracted from the information of the temporary custom system image.

5. The method according to claim 1, characterized in that, In response to the recovery task, the unified recovery process via the system disk uses either the first backup file or the second backup file as input data, combines it with the auxiliary recovery information, and calls the cloud platform image import interface to generate a target custom system image, including: Read the backup file path corresponding to the system disk to be restored and the auxiliary recovery information from the backup set metadata associated with the recovery task; Read the first backup file or the second backup file according to the backup file path, and upload it to the target object storage service to obtain the corresponding object storage access identifier; Call the cloud platform image import interface, and use the object storage access identifier and the auxiliary recovery information as input parameters of the image import interface to generate the target custom system image; When the target custom system image reaches a usable state, the following steps are triggered: according to the recovery mode indicated by the recovery task, the target custom system image is used to perform the corresponding system disk recovery process on the target location.

6. The method according to claim 5, characterized in that, The recovery modes include new instance recovery, original machine recovery, and disk overwrite recovery. The step of performing corresponding system disk recovery processing on the target location using the target custom system image, based on the recovery mode indicated by the recovery task, includes: When the recovery mode is new instance recovery, the target custom system image is imported according to the unified recovery process of the system disk, the preset instance configuration parameters are obtained, and the identifier of the target custom system image and the instance configuration parameters are passed to the cloud platform to create an instance to create a new cloud host service instance. The system disk of the new cloud host service instance is generated based on the target custom system image; When the recovery mode is original machine recovery, query the original instance and currently mounted cloud disk information of the target cloud host service, verify that the original instance is consistent with the cloud host identifier recorded in the backup set, and that the list of cloud disk identifiers currently mounted by the original instance corresponds to the source volume identifier recorded in the backup set. Then, stop the operation of the original instance, keep the system disk of the original instance mounted on the original instance, import the target custom system image according to the unified system disk recovery process, call the system disk replacement interface of the cloud platform, and replace the system disk of the original instance based on the imported target custom system image. When the recovery mode is disk overwrite recovery, query the pending cloud host service instance and pending cloud disk information, stop the operation of the pending cloud host service instance, remove the system disk of the pending cloud host service instance from the ordinary cloud disk mount write-back list, import the target custom system image according to the unified system disk recovery process, call the cloud platform's system disk replacement interface, and replace the system disk of the pending cloud host service instance based on the imported target custom system image.

7. The method according to any one of claims 1-6, characterized in that, The method also includes a temporary resource cleanup step, specifically including: During the execution of the backup task or the recovery task, task context information is maintained; The task context information is used to record the identifiers of temporary resources created during task execution. These temporary resources include snapshot resources, temporary cloud disk resources, temporary image resources, or temporary object resources. After the backup task or the recovery task is completed, the identifiers of each temporary resource recorded in the task context information are traversed, and the corresponding resource deletion interface is called to clear each temporary resource.

8. An adaptive backup and recovery device for a cloud server service system disk, characterized in that, The device includes: The processing module is used to obtain the operating system type information of the target cloud host service in response to a backup task for the target cloud host service; The processing module is further configured to determine, based on the operating system type information, whether to perform a first backup operation or a second backup operation on the system disk of the target cloud host service; The processing module is further configured to generate a first backup file through the first backup operation, or generate a second backup file through the second backup operation, and obtain auxiliary recovery information corresponding to the system disk of the target cloud host service when performing the second backup operation; The processing module is also used to respond to the recovery task by using the first backup file or the second backup file as input data and combining the auxiliary recovery information to call the cloud platform image import interface to generate the target custom system image through the unified recovery process of the system disk; The processing module is further configured to perform corresponding system disk recovery processing on the target location using the target custom system image, based on the recovery mode indicated by the recovery task.

9. A computer device, characterized in that, The method includes one or more processors and a memory storing computer-readable instructions that, when executed by the one or more processors, perform the steps of the method as described in any one of claims 1-7.

10. A storage medium, characterized in that, The storage medium stores computer-readable instructions that, when executed by one or more processors, cause the one or more processors to perform the steps of the method as described in any one of claims 1-7.

Images