System recovery method and apparatus, electronic device, and storage medium

Abstract

The application discloses a system recovery method and device, electronic equipment and storage medium, the method is applied to virtualization platform cluster, the virtualization platform cluster includes first virtualization platform and multiple second virtualization platforms, comprising: in response to system recovery instruction, obtaining the backup data set of first virtualization platform, first configuration information, and the second configuration information of second virtualization platform, determining target virtualization platform from multiple second virtualization platforms according to first configuration information and second configuration information, extracting target drive matched with target virtualization platform from the preset drive library, constructing target system mirror image file according to backup data set and target drive, starting system mirror image file in target virtualization platform, and executing recovery operation. By the application, the problem that recovery can only be carried out on the original platform can be avoided, not only the flexibility and reliability of system recovery are improved, but also the operation threshold and time cost of system recovery are reduced.

Description

Technical Field

[0001] This invention relates to the fields of computer applications and data processing technology, and in particular to a system recovery method, apparatus, electronic device, and storage medium. Background Technology

[0002] With the deepening of enterprise informatization, virtualization platforms have become the mainstream infrastructure for supporting core business systems. Existing full-system backup and recovery solutions typically employ a combination of regular full backups and incremental backups to address the risks of hardware failure or data loss.

[0003] When system recovery is required, existing technologies typically operate within the same virtualization platform, i.e., restoring from a source instance on an ESXi platform to a target instance on an ESXi platform, or from a source instance on a KVM platform to a target instance on a KVM platform. This process usually relies on pre-deploying backup agents and specific drivers in the target environment. By reading the backup dataset, the operating system files are restored to the target disk, and an attempt is made to boot the system using the pre-installed driver environment, thereby completing the data rollback and business takeover.

[0004] However, in existing technologies, it is often difficult to directly achieve automated system recovery when facing the need for recovery in heterogeneous environments across virtualization platforms, or when the target machine is in a completely bare state without any operating system or prerequisite components. Specifically, existing solutions have the following shortcomings: 1. Poor compatibility: It only supports system recovery within the same virtualization platform. When the original system is migrated to a new hardware platform with different configurations, the recovered system often cannot start normally, making it difficult to meet the needs of cross-platform system recovery. 2. High operational difficulty: The system recovery operation requires a high level of technical skills from the user. Ordinary users are prone to recovery failure or data loss due to operational errors.

[0005] Therefore, how to achieve simple and effective system recovery is an urgent problem to be solved. Summary of the Invention

[0006] The purpose of this invention is to provide a system recovery method, apparatus, electronic device, and storage medium to solve the technical problems of poor compatibility and high operational difficulty in traditional system recovery solutions.

[0007] In a first aspect, embodiments of the present invention provide a system recovery method applied to a virtualization platform cluster, the virtualization platform cluster including a first virtualization platform and multiple second virtualization platforms, the system recovery method comprising: In response to a system recovery command, the system acquires the backup dataset and first configuration information of the first virtualization platform, as well as the second configuration information of the second virtualization platform. The configuration information includes hardware information, firmware information, and virtualization environment information. Based on the first configuration information and the second configuration information, a target virtualization platform is determined from a plurality of second virtualization platforms; Extract the target driver that is compatible with the target virtualization platform from the preset driver library; Based on the backup dataset and the target driver, construct a target system image file suitable for the target virtualization platform; The system image file is launched in the target virtualization platform, and a recovery operation is performed.

[0008] Secondly, embodiments of the present invention provide a system recovery device applied in a virtualization platform cluster, the virtualization platform cluster including a first virtualization platform and multiple second virtualization platforms, the system recovery device comprising: The acquisition module is used to acquire the backup dataset and first configuration information of the first virtualization platform and the second configuration information of the second virtualization platform in response to the system recovery command. The configuration information includes hardware information, firmware information and virtualization environment information. The determining module is configured to determine a target virtualization platform from a plurality of second virtualization platforms based on the first configuration information and the second configuration information; The extraction module is used to extract the target driver that is compatible with the target virtualization platform from the preset driver library; The build module is used to build a target system image file suitable for the target virtualization platform based on the backup dataset and the target driver; The recovery module is used to start the system image file in the target virtualization platform and perform a recovery operation.

[0009] In some embodiments, the determining module includes a calculation unit and a determining unit; The calculation unit is used to calculate the similarity between the first configuration information and the second configuration information to obtain the similarity value between the first virtualization platform and each of the second virtualization platforms in terms of configuration information; The determining unit is used to determine the target virtualization platform from the second virtualization platform based on the similarity value.

[0010] In some embodiments, the determining unit is specifically configured to: detect platform differences between candidate virtualization platforms when there are multiple candidate virtualization platforms with the same similarity value; and determine a target virtualization platform from the multiple candidate virtualization platforms based on the platform differences.

[0011] In some embodiments, the determining unit is further configured to: classify the multiple candidate virtualization platforms according to the platform differences to obtain candidate virtualization platforms of different levels, wherein the platform performance of a higher-level candidate virtualization platform is greater than that of a lower-level candidate virtualization platform; and determine a target virtualization platform that matches the user level from the multiple candidate virtualization platforms according to the user level of the user who triggered the system recovery command.

[0012] In some embodiments, the determining unit is further configured to: predict the probability value of a target service running stably for a preset duration in each of the candidate virtualization platforms, wherein the target service is the service corresponding to the key service data in the backup dataset; calculate the running score of each candidate virtualization platform when it stably runs the target service based on the platform performance differences of each candidate virtualization platform and the corresponding first weight coefficient, the probability value of each candidate virtualization platform and the corresponding second weight coefficient, wherein the sum of the first weight coefficient and the second weight coefficient is 1; and classify the multiple candidate virtualization platforms according to the running score to obtain candidate virtualization platforms of different levels.

[0013] In some embodiments, the building module includes a building unit and a processing unit; The building unit is used to build an initial system image file based on the backup dataset; The processing unit is used to call a proxy application that matches the target virtualization platform to perform the target driver injection operation during the construction process of the initial system image file, so as to obtain a target system image file suitable for the target virtualization platform.

[0014] In some embodiments, the construction module further includes: an acquisition unit and an identification unit; The acquisition unit is used to acquire related components associated with the target virtualization platform; The identification unit is used to identify the BIOS or UEFI firmware type of the target virtualization platform and obtain the identification result; The processing unit is specifically used to: during the construction process of the initial system image file, call the agent application that matches the target virtualization platform to perform the injection operation of the target driver and the associated components, and repair the corresponding bootloader according to the identification result to obtain a target system image file suitable for the target virtualization platform.

[0015] Thirdly, embodiments of the present invention provide an electronic device, which includes a processor, a memory, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the steps in the system recovery method described above.

[0016] Fourthly, embodiments of the present invention provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the system recovery method described in any of the preceding claims.

[0017] This invention provides a system recovery method, apparatus, electronic device, and storage medium. The method obtains the backup dataset of a first virtualization platform and the configuration information of each platform, then automatically matches the most suitable target virtualization platform for recovery based on the configuration information, and injects the adapted target driver to complete the construction of the target system image. This eliminates the need for users to manually perform driver adaptation and compatibility debugging, and enables the target system image to be directly loaded and the recovery operation to be performed in the target virtualization platform. This achieves system recovery across virtualization platforms with different configurations, solves the problem of poor compatibility in traditional solutions, reduces the technical requirements for users, and reduces the risk of recovery failure due to operational errors. Attached Figure Description

[0018] Figure 1 This is a schematic flowchart of a system recovery method provided in an embodiment of the present invention; Figure 2 This is a flowchart illustrating a component image file provided in an embodiment of the present invention; Figure 3 This is another schematic flowchart of the system recovery method provided in the embodiment of the present invention; Figure 4 This is a schematic diagram of a process for classifying candidate virtualization platforms according to an embodiment of the present invention; Figure 5 This is a schematic diagram of a system recovery device provided in an embodiment of the present invention; Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention; Figure 7 This is another structural schematic diagram of the electronic device provided in the embodiment of the present invention. Detailed Implementation

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

[0020] It should be understood that the steps described in the method embodiments of this disclosure may be performed in different orders and / or in parallel. Furthermore, the method embodiments may include additional steps and / or omit the steps shown. The scope of this disclosure is not limited in this respect.

[0021] The term "comprising" and its variations as used herein are open-ended inclusions, meaning "including but not limited to". The term "based on" means "at least partially based on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". Definitions of other terms will be given in the description below.

[0022] In this embodiment, with the deepening of enterprise informatization, virtualization platforms have become the mainstream infrastructure for supporting core business systems. Existing full-machine backup and recovery solutions typically employ a combination of regular full backups and incremental backups to address the risks of hardware failure or data loss.

[0023] When system recovery is required, existing technologies typically operate within the same virtualization platform, i.e., restoring from a source instance on an ESXi platform to a target instance on an ESXi platform, or from a source instance on a KVM platform to a target instance on a KVM platform. This process usually relies on pre-deploying backup agents and specific drivers in the target environment. By reading the backup dataset, the operating system files are restored to the target disk, and an attempt is made to boot the system using the pre-installed driver environment, thereby completing the data rollback and business takeover.

[0024] However, in existing technologies, it is often difficult to directly achieve automated system recovery when facing the need for recovery in heterogeneous environments across virtualization platforms, or when the target machine is in a completely bare state without any operating system or prerequisite components. Specifically, existing solutions have the following shortcomings: 1. Poor compatibility: It only supports system recovery within the same virtualization platform. When the original system is migrated to a new hardware platform with different configurations, the recovered system often cannot start normally, making it difficult to meet the needs of cross-platform system recovery. 2. High operational difficulty: The system recovery operation requires a high level of technical skills from the user. Ordinary users are prone to recovery failure or data loss due to operational errors.

[0025] Therefore, how to achieve simple and effective system recovery is an urgent problem to be solved.

[0026] To address the technical problems existing in related technologies, this invention provides a system recovery method. This method is applied to a virtualization platform cluster, which includes a first virtualization platform and multiple second virtualization platforms. For details, please refer to... Figure 1 , Figure 1 This is a schematic flowchart of a system recovery method provided in an embodiment of the present invention, such as... Figure 1 As shown, the method includes steps 101 to 105; Step 101: In response to the system recovery command, obtain the backup dataset and first configuration information of the first virtualization platform, and the second configuration information of the second virtualization platform. The configuration information includes hardware information, firmware information and virtualization environment information.

[0027] In this embodiment, the system recovery command is the command that triggers the entire recovery process. It can be initiated manually by the user or automatically generated by the monitoring system when it detects a serious failure in the first virtualization platform, such as a crash or data corruption.

[0028] The first virtualization platform serves as the source of the recovery operation. Its backup dataset contains the full data state of the source system at a certain point in time. This dataset can be generated in real time by capturing disk I / O operations through Continuous Data Protection (CDP) technology, supporting rollback to any second-level time point. It can also be generated through a combination of regular full backups and incremental backups.

[0029] Specifically, the configuration information is used to characterize the current resource status and environmental characteristics of each virtualization platform. It can include hardware information (such as the number of virtual CPU cores, memory capacity, virtual network card model, virtual disk controller type, etc.), firmware information (such as BIOS version, UEFI boot mode identifier, etc.) and virtualization environment information (such as virtualization software version number, Hypervisor type identifier, such as VMware ESXi or KVM).

[0030] It should be noted that the second virtualization platform can be selected as a recovery target, and there can be one or more of them. The configuration information of each virtualization platform can be obtained by calling the management interface (API) of each virtualization platform.

[0031] Step 102: Determine the target virtualization platform from multiple second virtualization platforms based on the first configuration information and the second configuration information.

[0032] In this embodiment, in order to select the target execution environment with the highest compatibility with the source system (i.e., the first virtualization platform) and the highest recovery success rate from multiple second virtualization platforms, this embodiment can select and determine the target execution environment based on the similarity of configuration information. That is, the first configuration information can be compared with the second configuration information of each second virtualization platform item by item to calculate the degree of matching of hardware architecture, firmware type and virtualization kernel.

[0033] Specifically, the matching items provided in this embodiment may include, but are not limited to, CPU instruction set compatibility, driver universality, and firmware boot mode. Thus, by using this embodiment of the invention, platforms with incompatible firmware modes (such as a source system using UEFI while the target system only supports BIOS) or missing critical drivers can be automatically excluded.

[0034] It should be noted that when there are multiple second configuration information with the same similarity to the first configuration information, that is, when there are multiple selectable second virtualization platforms, this embodiment can further filter and determine the target virtualization platform based on the resource idle rate, network bandwidth load, or preset policy weight of the second virtualization platform.

[0035] As an optional embodiment, the driver used by the first virtualization platform can be detected first. When the first virtualization platform is found to be using a specific driver, the second virtualization platform that natively supports or is compatible with the driver type through the driver library can be selected as the target virtualization platform to avoid the problem of startup failure due to missing drivers after recovery.

[0036] Step 103: Extract the target driver that is compatible with the target virtualization platform from the preset driver library.

[0037] In this embodiment, the preset driver library can pre-store various driver packages required for running under different operating systems (such as Linux, Windows, etc.) in different virtualization environments (such as ESXi, KVM, etc.).

[0038] In this context, a target driver can refer to a software module that ensures the operating system can properly recognize and run on the virtual hardware of the target virtualization platform. Specifically, it can include virtual network card drivers, virtual disk controller drivers, graphics card drivers, and motherboard chipset drivers, etc.

[0039] Specifically, the process of extracting the target driver from the driver library can be carried out by indexing and querying the driver library based on the second configuration information of the target virtualization platform, such as hardware information or virtualization environment information, so as to accurately locate and extract the corresponding driver file from the driver library.

[0040] Step 104: Based on the backup dataset and the target driver, construct the target system image file suitable for the target virtualization platform.

[0041] In this embodiment, to generate a target system image file that can be directly booted on the target virtualization platform, please refer to [link to documentation]. Figure 2 , Figure 2 This is a flowchart illustrating a component image file provided in an embodiment of the present invention, such as... Figure 2 As shown, this embodiment can extract the target driver suitable for the target virtualization platform from the driver library and extract the backup dataset of the first virtualization platform from the storage device. Then, the agent application can be called to restore the initial system file structure and partition table based on the backup dataset to form an initial system image. Subsequently, driver injection and boot dynamic repair operations are performed, specifically: the extracted target driver is injected into the key location of the initial system image (such as the driver storage directory or registry of the operating system), and the bootloader is detected and repaired to adapt to the firmware type (BIOS or UEFI) of the target platform, and finally the target system image file is obtained.

[0042] As an optional embodiment, when the backup dataset comes from a Linux system with GPT partitioning and UEFI boot, and the target virtualization platform supports UEFI but requires specific grub configuration, the build process will automatically rewrite the grub.cfg file and inject the necessary EFI drivers, and finally package it to generate a target system image file in ISO format or the target virtualization platform's native format (such as VMDK or qcow2). This image file contains all the necessary running components required by the backup dataset, forming an online OS that perfectly matches the target virtualization platform environment.

[0043] Step 105: Start the system image file in the target virtualization platform and perform the recovery operation.

[0044] In this embodiment, the startup operation provided is to mount the target system image file built in the above embodiment to the virtual machine instance of the target virtualization platform. Since the image file has a pre-installed adapted driver and a repaired bootloader, the operating system can be successfully loaded in the target virtualization platform without the need for manual intervention to install the driver or repair the bootloader.

[0045] Specifically, performing recovery operations can refer to automatically running a preset initialization script or agent application after the system has successfully started, and completing the remaining system configuration work, including but not limited to reconfiguring network IP addresses, updating hostnames, cleaning up temporary files, and automatically starting business services.

[0046] As an optional embodiment, in a disaster recovery scenario, the method provided by the embodiments of the present invention can quickly launch the core database system on a backup heterogeneous virtualization platform after the failure of the main platform, ensuring that critical business operations are not interrupted and significantly improving the resilience of the enterprise's IT architecture and its business continuity assurance capabilities.

[0047] In summary, this invention provides a system recovery method. The method includes, in response to a system recovery command, acquiring a backup dataset and first configuration information of a first virtualization platform, and second configuration information of a second virtualization platform; determining a target virtualization platform from multiple second virtualization platforms based on the first and second configuration information; extracting a target driver compatible with the target virtualization platform from a preset driver library; constructing a target system image file based on the backup dataset and the target driver; starting the system image file on the target virtualization platform; and performing a recovery operation. By employing this invention, manual recovery work that previously required hours or even days can be reduced to minutes, ensuring immediate service availability and enabling cross-platform full-machine recovery in a completely bare state. This provides enterprises with a highly available, low-cost, flexible, and efficient disaster recovery system.

[0048] In some embodiments, to improve the efficiency of building system image files and thus reduce subsequent recovery time, please refer to [link to relevant documentation]. Figure 3 , Figure 3 This is another schematic flowchart of the system recovery method provided in this embodiment of the invention, such as... Figure 3 As shown, the system recovery method provided in this embodiment may further include the following steps: Step 301: Calculate the similarity between the first configuration information and the second configuration information to obtain the similarity value between the first virtualization platform and each second virtualization platform in terms of configuration information.

[0049] In this embodiment, the similarity provided is mainly used as a numerical indicator to characterize the degree of configuration matching between the first virtualization platform (i.e., the source platform) and each of the second virtualization platforms. Specifically, the similarity calculation process can involve structuring the aforementioned multi-dimensional configuration information to convert it into feature vectors, and then using a preset similarity algorithm, such as the cosine similarity algorithm or the Euclidean distance algorithm, to compare the vector of the first configuration information with the vector of each second configuration information, thereby obtaining the similarity between the first configuration information and each second configuration information.

[0050] For example, assuming the configuration feature vector of the first virtualization platform is V1 and the configuration feature vector of a second virtualization platform is V2, when calculating the similarity, a high weight score (such as 0.8) can be assigned to fields that match completely, and a low weight (such as 0.1) or zero score can be assigned to fields that are partially compatible or do not match. Finally, a similarity value S between 0 and 1 is obtained.

[0051] Specifically, if the hardware architecture and firmware type of the two platforms are completely identical, with only some drivers differing, the similarity value S is 0.9; if the hardware architecture, firmware type, and drivers are completely different, the similarity value S is 0. In this way, through this quantitative calculation method, the compatibility between each second virtualization platform and the first virtualization platform can be objectively evaluated, thereby providing accurate data support for the subsequent selection of target virtualization platforms and reducing the risk of system startup failure due to hardware heterogeneity.

[0052] Step 302: Determine the target virtualization platform from the second virtualization platform based on the similarity value.

[0053] In this embodiment, the specific method for determining the target virtualization platform can be to directly select the second virtualization platform with the highest similarity value as the target virtualization platform; or a preset similarity threshold (e.g., 0.85) can be set, and then any platform with a similarity value higher than the threshold can be selected. If the highest similarity value is still lower than the threshold, then the second virtualization platform with the highest similarity value is selected as the target virtualization platform.

[0054] For example, if there are three second virtualization platforms A, B, and C in the cluster, and their similarity values ​​with the first virtualization platform are calculated to be 0.95, 0.70, and 0.88 respectively, then platform A can be selected as the target virtualization platform. This is because its configuration is closest to the source system, meaning that the amount of driver modifications required to restore the system on platform A is minimal, resulting in the highest efficiency in building the system image file. It also indicates the highest success rate of boot repair, minimizing subsequent recovery operation time. Thus, by automatically selecting based on similarity values, it can be ensured that the restored system can run stably in the new virtualization environment with minimal compatibility overhead.

[0055] In other embodiments, there are multiple candidate virtualization platforms with the same similarity value. In order to further improve the efficiency of building system image files and the time of subsequent recovery operations, the step of determining the target virtualization platform from the second virtualization platform based on the similarity value provided in this embodiment may include: when there are multiple candidate virtualization platforms with the same similarity value, detecting the platform differences between the candidate virtualization platforms; and determining the target virtualization platform from the multiple candidate virtualization platforms based on the platform differences.

[0056] In this embodiment, the candidate virtualization platform provided in this embodiment can refer to multiple second virtualization platforms whose second configuration information and the first configuration information of the first virtualization platform have the highest similarity value in the previous round of screening.

[0057] In this embodiment, platform differences refer to indicators that affect system stability and performance, in addition to basic hardware, firmware, and virtualization environment configuration information. For example, these differences may include, but are not limited to, memory bandwidth utilization, disk I / O throughput, network topology latency, CPU instruction set extension support, and the current host machine's load fluctuation rate. Specifically, this embodiment can obtain real-time operating status data of each candidate virtualization platform by calling the monitoring interface or metadata collection module of the virtualization platform cluster, thereby evaluating the differences between the candidate virtualization platforms based on the real-time operating status data.

[0058] In an optional embodiment, when two candidate virtualization platforms are completely identical in terms of CPU core count, memory capacity, and firmware version, resulting in the same similarity value, this embodiment can further detect their memory access latency. If the average memory latency of candidate virtualization platform A is 50ns, while the average memory latency of candidate virtualization platform B is 80ns, then the platform difference in average memory latency between the two can be determined. Thus, through this difference detection method provided in this embodiment, key variables affecting the actual operation of services can be identified even when configuration information is highly similar, thereby facilitating the determination of the most suitable target virtualization platform.

[0059] In practical applications, the differences between candidate virtualization platforms are not limited to the differences in average memory latency mentioned in the above embodiments, but may also include differences in disk I / O throughput capabilities. Therefore, in order to ensure the stable operation of the critical services of the first virtualization platform, this embodiment can set priorities according to the actual hardware resource requirements of the service operation. For example, for I / O-sensitive database services, candidate platforms with higher disk I / O throughput capabilities are selected first; for network latency-sensitive interactive services, candidate platforms with lower network topology latency are selected first. This allows for the selection of a target virtualization platform that better matches the service operation requirements from multiple candidate platforms with similarity, further improving the operational stability and service processing performance of the system after recovery.

[0060] In some embodiments, in order to meet different user needs and ensure the user experience of different users, the step of determining the target virtualization platform from multiple candidate virtualization platforms based on the platform differences provided in this embodiment may include: classifying the multiple candidate virtualization platforms according to the platform differences to obtain candidate virtualization platforms of different levels, wherein the platform performance of a higher-level candidate virtualization platform is greater than that of a lower-level candidate virtualization platform; and determining the target virtualization platform that matches the user level from the multiple candidate virtualization platforms according to the user level of the user who triggered the system recovery command.

[0061] In this embodiment, classifying candidate virtualization platforms can refer to quantifying the calculated platform differences into specific performance levels based on a preset performance evaluation model. Specifically, this embodiment can extract key hardware indicators such as the number of CPU cores, memory capacity, storage I / O throughput, and network bandwidth of each candidate virtualization platform. Then, combined with firmware type (such as BIOS or UEFI) and compatibility with virtualization extended instruction sets, a multi-dimensional performance feature vector is constructed. Subsequently, this feature vector is input into the preset performance evaluation model for evaluation processing to calculate the performance score of each candidate virtualization platform.

[0062] The performance evaluation model provided in this embodiment can be trained from historically collected performance data of various platforms. It can output accurate performance levels based on the input feature vector, such as high, medium and low levels. The high-level candidate virtualization platform can provide more idle resources and lower running latency, making it suitable for supporting core business systems.

[0063] In practical applications, after obtaining the performance level, a target virtualization platform of the corresponding level can be assigned based on the user level initiating the system recovery command. For example, when a VIP user or core business department initiates a recovery request, a high-level candidate virtualization platform can be assigned as the target virtualization platform. When an ordinary user or ordinary department initiates a recovery request, a medium- or low-level candidate virtualization platform that meets the requirements can be assigned as the target virtualization platform. In this way, through the hierarchical allocation method provided in this embodiment, the recovery experience of high-level users and core businesses can be prioritized when cluster resources are limited, while cluster resources are allocated reasonably to avoid resource waste.

[0064] It's important to note that user levels can be correlated with the importance of the business. For example, core database administrators might correspond to Level 1 users, while regular development and testing personnel might correspond to Level 3 users. Specifically, the user's level information can be obtained by parsing the identity identifier carried in the command.

[0065] In some embodiments, the platform differences between candidate virtualization platforms are not limited to the platform performance differences mentioned in the above embodiments, but may also include differences in the downtime probability of each candidate virtualization platform during operation. Therefore, to ensure the stable operation of the critical services of the first virtualization platform, please refer to [link to relevant documentation]. Figure 4 , Figure 4 This is a schematic diagram of a process for classifying candidate virtualization platforms according to an embodiment of the present invention, such as... Figure 4 As shown, steps 401 to 403 are included; Step 401: Predict the probability value of the target service running stably for a preset duration in each of the candidate virtualization platforms.

[0066] In this embodiment, the target business is the business corresponding to the key business data in the backup dataset, specifically the key applications or services that have a core impact on enterprise operations and can be extracted from the backup dataset of the first virtualization platform.

[0067] The probability value of the preset stable operation duration provided in this embodiment can be obtained by analyzing historical operation logs, resource load curves and fault records. This represents the possibility that the target service can run continuously without failure for a preset duration (such as 72 hours or a complete business cycle) under a specific hardware environment and virtualization configuration.

[0068] Optionally, this embodiment can identify the characteristics of key business processes by reading business metadata from the backup dataset, and then call a pre-trained stability prediction model. Combining performance parameters such as CPU architecture compatibility, memory bandwidth bottlenecks, and I / O throughput latency of the candidate virtualization platform, it outputs a probability value between 0 and 1.

[0069] Specifically, the stability prediction model provided in this embodiment can be trained on a large amount of historical business operation data and platform performance data. The trained stability prediction model can accurately capture the stability correlation patterns of different business types under different platform configurations, thereby outputting probability prediction results.

[0070] Thus, by using the probability prediction method provided in this embodiment, platforms with compliant hardware configurations but potential instability risks can be avoided in advance before recovery, thereby ensuring the stable operation of critical businesses.

[0071] Step 402: Calculate the running score of each candidate virtualization platform when it stably runs the target service, based on the platform performance differences of each candidate virtualization platform and the corresponding first weight coefficient, the probability value of each candidate virtualization platform and the corresponding second weight coefficient.

[0072] Wherein, the sum of the first weighting coefficient and the second weighting coefficient is 1. The operational score provided in this embodiment is mainly used to characterize the ability of the candidate virtualization platform to stably run the target service.

[0073] In this embodiment, the platform performance difference is calculated based on the deviation between the hardware information (such as CPU frequency, number of cores, and disk type) obtained above and the baseline value of the target business requirements. The smaller the deviation, the higher the score for this item. The probability value of each candidate virtualization platform is the stable operation probability predicted by step S401 above. The higher the probability value, the higher the score for this item.

[0074] In practical applications, when calculating the operational score, the platform performance score can be multiplied by a preset first weighting coefficient, and then the probability value can be multiplied by a second weighting coefficient to obtain the comprehensive operational score of the candidate virtualization platform. The first and second weighting coefficients can be customized according to the enterprise's emphasis on performance and stability. For example, an enterprise that values ​​stability more can set the second weighting coefficient to 0.7 and the first weighting coefficient to 0.3, and vice versa.

[0075] As an optional embodiment, run the scoring It can be represented as: ,in Due to platform performance differences, This is a probability value for stable operation. For example, in a scenario involving the recovery of a core financial database, a higher second weighting coefficient (e.g., 0.7) can be set to prioritize stability, while the first weighting coefficient is set to 0.3. In this case, even if the platform's hardware performance is excellent ( If the stability prediction probability is low, the final performance score will also drop significantly. Therefore, the weighted calculation method provided in this embodiment allows the score results to reflect the platform's adaptability in actual business scenarios.

[0076] Step 403: Based on the running score, classify the multiple candidate virtualization platforms to obtain candidate virtualization platforms of different levels.

[0077] In this step, candidate virtualization platforms can be sorted from high to low according to their performance scores, and then different performance levels can be divided according to preset score ranges. The higher the performance score, the higher the corresponding level. Subsequently, the target virtualization platform can be determined according to the rules that match the user level.

[0078] In this way, by combining platform performance and probability of stable operation for comprehensive scoring and grading, the rationality of the selection of target virtualization platforms can be further improved. This not only meets the business's requirements for operational performance, but also ensures the continuous and stable operation of the business after recovery to the greatest extent, avoiding frequent failures after recovery that would affect the normal business operations of the enterprise.

[0079] In other embodiments, in order to complete the construction of the target system image file, the step of constructing a target system image file suitable for the target virtualization platform based on the backup dataset and the target driver provided in this embodiment may include: performing an initial system image file construction process based on the backup dataset; during the initial system image file construction process, calling a proxy application matching the target virtualization platform to perform the target driver injection operation to obtain a target system image file suitable for the target virtualization platform.

[0080] In this embodiment, the backup dataset can refer to the complete disk I / O operation logs and data snapshots of the source first virtualization platform captured through Continuous Data Protection (CDP) technology or periodic full backups. It can include the operating system kernel, file system structure, application data, and existing hardware driver configurations. The initial system image file construction process refers to the process of reassembling and packaging the discrete data blocks in the backup dataset according to the disk format supported by the target virtualization platform (such as VMDK, qcow2, or raw format).

[0081] Specifically, the process of building an initial system image file may include parsing the metadata information of the backup data, rebuilding the partition table (MBR or GPT), and writing the data stream into the pre-allocated virtual disk space, thereby forming an initial image with the ability to run a basic operating system.

[0082] In some embodiments, the proxy application provided in this embodiment is mainly used to simulate driver installation behavior in an online environment, thereby enabling the mounting and modification of the file system inside the initial system image file in an offline state.

[0083] In practical applications, the proxy application provided in this embodiment can identify the hardware abstraction layer characteristics of the target virtualization platform in advance, place the matching target driver in the corresponding driver directory of the operating system, and modify the boot configuration items so that the system can automatically load the matching target driver on the first boot, avoiding boot failure due to driver incompatibility. Compared with the traditional recovery process of building a complete image first and then modifying the driver, this method of building and injecting drivers at the same time can reduce subsequent boot repair steps, further shorten the overall image building time, and improve the overall efficiency of system recovery. In addition, the proxy application can also automatically remove the original drivers incompatible with the target platform from the original first virtualization platform during the driver injection process, avoiding conflicts between old and new drivers and further ensuring the availability of the target system image file.

[0084] Specifically, the target driver injection operation provided in this embodiment may refer to the agent application reading driver files (such as network card drivers, storage controller drivers, graphics card drivers, etc.) that are compatible with the hardware abstraction layer of the target virtualization platform from a preset driver library, copying them to a specific system directory of the initial system image file (such as / lib / modules in Linux or System32 / drivers in Windows), and modifying the system registry or configuration files to register these new drivers.

[0085] In this way, by calling the proxy application for injection during the build process, the tedious steps of manually installing drivers after system startup in traditional recovery methods can be avoided, which significantly improves the immediate availability of the system after recovery, greatly shortens the recovery time to operation (RTO), and improves the success rate of cross-platform recovery.

[0086] As an optional embodiment, in order to ensure that the target system image file can be loaded normally on the target virtualization platform, before the step of calling the agent application matching the target virtualization platform to perform the target driver injection operation during the construction process of the initial system image file to obtain the target system image file suitable for the target virtualization platform, the system recovery method provided in this embodiment may further include: obtaining the associated components related to the target virtualization platform; identifying the BIOS or UEFI firmware type of the target virtualization platform, and obtaining the identification result.

[0087] In some embodiments, the associated components provided in this embodiment may refer to non-core driver-type software modules or configuration files necessary to ensure that the operating system can correctly recognize hardware devices and establish basic communication connections on a specific target virtualization platform. For example, these components may include, but are not limited to, management tools for a specific storage controller, configuration scripts for a network virtualization adaptation layer, etc.

[0088] It should be noted that the associated components provided in this embodiment can also be retrieved and extracted from a preset component library.

[0089] As an optional embodiment, when the target virtualization platform uses an older disk interface, the associated component can be a module containing a specific IDE controller emulation to address the issue that the new kernel cannot directly recognize older virtual disk formats. Alternatively, in scenarios requiring special network acceleration, the associated component can also be a configuration script for configuring the network interface. Thus, by acquiring and preparing these associated components, they can complement the subsequently injected target driver, jointly constructing a complete hardware adaptation environment and avoiding problems such as the system being unable to mount disks or connect to the network after startup due to the lack of necessary auxiliary modules.

[0090] In other embodiments, the identification result provided in this embodiment may refer to information that clearly identifies the type of boot firmware architecture currently used by the target virtualization platform, specifically divided into Basic Input / Output System (BIOS) type or Unified Extensible Firmware Interface (UEFI) type.

[0091] It should be noted that the identification results provided in this embodiment can be obtained by reading the metadata information of the target virtualization platform, querying the hardware description file provided by the virtualization management layer, or detecting the boot sector characteristics in the pre-boot environment.

[0092] As an optional embodiment, if the identification result is UEFI type, the .efi boot file in the EFI partition can be repaired; if the identification result is BIOS type, the MBR sector is rewritten. Thus, by accurately identifying the firmware type, errors due to mismatched boot methods can be prevented, ensuring that the recovered system can be correctly loaded by the target virtualization platform firmware.

[0093] Thus, after obtaining the associated components related to the target virtualization platform and the identification result of the target virtualization platform, the step provided in this embodiment of calling a proxy application matching the target virtualization platform to perform the target driver injection operation during the initial system image file construction process to obtain a target system image file suitable for the target virtualization platform can specifically include: during the initial system image file construction process, calling a proxy application matching the target virtualization platform to perform the target driver and the associated components injection operation, and repairing the corresponding bootloader according to the identification result to obtain a target system image file suitable for the target virtualization platform.

[0094] In this embodiment, the injection method for the associated components is the same as that for the target driver; both involve integrating them into the file system directory structure of the initial system image file, making them part of the image. Repairing the corresponding bootloader can refer to reconfiguring or generating boot code and configuration files adapted to the target firmware type based on the obtained identification results.

[0095] In practical applications, after mounting the initial system image, the agent application first copies the target drivers (such as network card drivers, storage controller drivers, etc.) to the system's driver storage directory, and deploys related components to the specified location. Then, the agent application judges the identification result. If it is a BIOS type, it installs the bootloader suitable for MBR and updates the partition table flag; if it is a UEFI type, it creates or repairs the EFI system partition, writes the corresponding .efi executable file, and configures the boot item list.

[0096] Thus, by using the method provided in this embodiment of the invention, and by combining the injection of drivers and components with the dynamic repair of the bootloader, deep adaptation of the software and hardware environment can be achieved, enabling the generated target system image file to have cross-platform boot capability. The entire link adaptation from the underlying hardware driver to the upper-level boot logic can be completed without manual intervention, significantly improving the success rate and automation of system recovery.

[0097] Based on the method described in the above embodiments, this embodiment will be further described from the perspective of a system recovery device. The system recovery device can be implemented as an independent entity or integrated into an electronic device, such as a terminal, which may include a mobile phone, a tablet computer, etc.

[0098] Please see Figure 5 , Figure 5 This is a schematic diagram of a system recovery device provided in an embodiment of the present invention, such as... Figure 5 As shown, the system recovery device 500 provided in this embodiment of the invention is applied in a virtualization platform cluster, the virtualization platform cluster including a first virtualization platform and multiple second virtualization platforms, and the system recovery device 500 includes: The acquisition module 501 is used to acquire the backup dataset and first configuration information of the first virtualization platform and the second configuration information of the second virtualization platform in response to the system recovery command. The configuration information includes hardware information, firmware information and virtualization environment information.

[0099] The determination module 502 is used to determine the target virtualization platform from a plurality of second virtualization platforms based on the first configuration information and the second configuration information.

[0100] The extraction module 503 is used to extract the target driver that is compatible with the target virtualization platform from the preset driver library.

[0101] Module 504 is used to construct a target system image file suitable for the target virtualization platform based on the backup dataset and the target driver.

[0102] Recovery module 505 is used to start the system image file in the target virtualization platform and perform recovery operations.

[0103] In specific implementation, the above modules and / or units can be implemented as independent entities, or they can be arbitrarily combined and implemented as the same or several entities. For the specific implementation of the above modules and / or units, please refer to the previous method embodiments. For the specific beneficial effects that can be achieved, please also refer to the beneficial effects in the previous method embodiments, which will not be repeated here.

[0104] Additionally, please see Figure 6 , Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. The electronic device can be a mobile terminal such as a smartphone, tablet computer, or other similar device. Figure 6 As shown, the electronic device 600 includes a processor 601 and a memory 602. The processor 601 and the memory 602 are electrically connected.

[0105] The processor 601 is the control center of the electronic device 600. It connects various parts of the electronic device through various interfaces and lines. By running or loading the application program stored in the memory 602 and calling the data stored in the memory 602, it performs various functions of the electronic device 600 and processes data, thereby monitoring the electronic device 600 as a whole.

[0106] In this embodiment, the processor 601 in the electronic device 600 loads the instructions corresponding to the processes of one or more applications into the memory 602 according to the following steps, and the processor 601 runs the applications stored in the memory 602, thereby realizing any step in the system recovery method provided in the above embodiment.

[0107] The electronic device 600 can implement the steps of any embodiment of the system recovery method provided in the embodiments of the present invention. Therefore, it can achieve the beneficial effects that any system recovery method provided in the embodiments of the present invention can achieve, as detailed in the preceding embodiments, and will not be repeated here.

[0108] Please see Figure 7 , Figure 7 This is another structural schematic diagram of the electronic device provided in the embodiments of the present invention, such as... Figure 7 As shown, Figure 7 A specific structural block diagram of an electronic device provided in an embodiment of the present invention is shown. This electronic device can be used to implement the system recovery method provided in the above embodiments. The electronic device 700 can be a mobile terminal such as a smartphone or a laptop computer.

[0109] RF circuit 710 is used to receive and transmit electromagnetic waves, converting electromagnetic waves into electrical signals and vice versa, thereby enabling communication with communication networks or other devices. RF circuit 710 may include various existing circuit elements used to perform these functions, such as antennas, radio frequency transceivers, digital signal processors, encryption / decryption chips, subscriber identity modules (SIM cards), memory, etc. RF circuit 710 can communicate with various networks such as the Internet, corporate intranets, and wireless networks, or communicate with other devices via wireless networks. The aforementioned wireless networks may include cellular telephone networks, wireless local area networks (WLANs), or metropolitan area networks (MANs). The aforementioned wireless networks may use various communication standards, protocols, and technologies, including but not limited to Global System for Mobile Communication (GSM), Enhanced Data GSM Environment (EDGE), Wideband Code Division Multiple Access (WCDMA), Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Wireless Fidelity (Wi-Fi) (such as IEEE 802.11a, IEEE 802.11b, IEEE 802.11g, and / or IEEE 802.11n), Voice over Internet Protocol (VoIP), Worldwide Interoperability for Microwave Access (Wi-Max), other protocols for email, instant messaging, and short messages, and any other suitable communication protocols, including those that have not yet been developed.

[0110] The memory 720 can be used to store software programs and modules, such as the program instructions / modules corresponding to the system recovery method in the above embodiment. The processor 780 executes various functional applications and performs system recovery by running the software programs and modules stored in the memory 720.

[0111] Memory 720 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, memory 720 may further include memory remotely located relative to processor 780, which can be connected to electronic device 700 via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0112] The input unit 730 can be used to receive input digital or character information, and to generate keyboard, mouse, joystick, optical, or trackball signal inputs related to user settings and function control. Specifically, the input unit 730 may include a touch-sensitive surface 731 and other input devices 732. The touch-sensitive surface 731, also known as a touch display screen or touchpad, can collect touch operations performed by the user on or near it (such as operations performed by the user using a finger, stylus, or any suitable object or accessory on or near the touch-sensitive surface 731), and drive the corresponding connection device according to a pre-set program. Optionally, the touch-sensitive surface 731 may include two parts: a touch detection device and a touch controller. The touch detection device detects the user's touch position and the signal generated by the touch operation, and transmits the signal to the touch controller; the touch controller receives touch information from the touch detection device, converts it into touch point coordinates, sends it to the processor 780, and can receive and execute commands sent by the processor 780. In addition, the touch-sensitive surface 731 can be implemented using various types such as resistive, capacitive, infrared, and surface acoustic wave. In addition to the touch-sensitive surface 731, the input unit 730 may also include other input devices 732. Specifically, other input devices 732 may include, but are not limited to, one or more of the following: physical keyboard, function keys (such as volume control buttons, power buttons, etc.), trackball, mouse, joystick, etc.

[0113] Display unit 740 can be used to display information input by the user or information provided to the user, as well as various graphical user interfaces of electronic device 700. These graphical user interfaces can be composed of graphics, text, icons, video, and any combination thereof. Display unit 740 may include display panel 741, optionally configured as LCD (Liquid Crystal Display), OLED (Organic Light-Emitting Diode), or other similar forms. Further, touch-sensitive surface 731 may cover display panel 741. When touch-sensitive surface 731 detects a touch operation on or near it, it transmits the information to processor 780 to determine the type of touch event. Subsequently, processor 780 provides corresponding visual output on display panel 741 according to the type of touch event. Although in the figures, touch-sensitive surface 731 and display panel 741 are implemented as two separate components to achieve input and output functions, in some embodiments, touch-sensitive surface 731 and display panel 741 can be integrated to achieve input and output functions.

[0114] The electronic device 700 may also include at least one sensor 750, such as a light sensor, a motion sensor, and other sensors. Specifically, the light sensor may include an ambient light sensor and a proximity sensor, wherein the ambient light sensor can adjust the brightness of the display panel 741 according to the ambient light level, and the proximity sensor can generate an interruption when the flip is closed or shut down. As a type of motion sensor, a gravity acceleration sensor can detect the magnitude of acceleration in various directions (generally three axes), and can detect the magnitude and direction of gravity when stationary. It can be used for applications that recognize the phone's posture (such as landscape / portrait switching, related games, magnetometer posture calibration), vibration recognition related functions (such as pedometer, tapping), etc. Other sensors that may be configured in the electronic device 700, such as gyroscopes, barometers, hygrometers, thermometers, and infrared sensors, will not be described in detail here.

[0115] Audio circuitry 760, speaker 761, and microphone 762 provide an audio interface between the user and electronic device 700. Audio circuitry 760 converts received audio data into electrical signals and transmits them to speaker 761, where speaker 761 converts them into sound signals for output. Conversely, microphone 762 converts collected sound signals into electrical signals, which are then received by audio circuitry 760, converted back into audio data, and processed by processor 780. The audio data is then transmitted via RF circuitry 710 to, for example, another terminal, or output to memory 720 for further processing. Audio circuitry 760 may also include an earphone jack to facilitate communication between peripheral headphones and electronic device 700.

[0116] Electronic device 700, through transmission module 770 (e.g., Wi-Fi module), can help users receive requests, send information, etc., providing users with wireless broadband internet access. Although transmission module 770 is shown in the figure, it is understood that it is not an essential component of electronic device 700 and can be omitted as needed without changing the essence of the invention.

[0117] The processor 780 is the control center of the electronic device 700. It connects to various parts of the phone via various interfaces and lines, and performs various functions and processes data of the electronic device 700 by running or executing software programs and / or modules stored in the memory 720, and by calling data stored in the memory 720, thereby providing overall monitoring of the electronic device. Optionally, the processor 780 may include one or more processing cores; in some embodiments, the processor 780 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, user interface, and applications, and the modem processor mainly handles wireless communication. It is understood that the modem processor may also not be integrated into the processor 780.

[0118] The electronic device 700 also includes a power supply 790 (such as a battery) that supplies power to various components. In some embodiments, the power supply may be logically connected to the processor 780 through a power management system, thereby enabling functions such as managing charging, discharging, and power consumption through the power management system. The power supply 790 may also include one or more DC or AC power supplies, recharging systems, power fault detection circuits, power converters or inverters, power status indicators, and other arbitrary components.

[0119] Although not shown, the electronic device 700 also includes cameras (such as front-facing cameras and rear-facing cameras), Bluetooth modules, etc., which will not be described in detail here. Specifically, in this embodiment, the display unit of the electronic device is a touch screen display, and the mobile terminal also includes a memory and one or more programs, wherein one or more programs are stored in the memory and configured to be executed by one or more processors to implement any step of the system recovery method provided in the above embodiments.

[0120] In practice, the above modules can be implemented as independent entities or combined in any way to be implemented as the same or several entities. For the specific implementation of the above modules, please refer to the previous method implementation examples, which will not be repeated here.

[0121] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by instructions, or by instructions controlling related hardware. These instructions can be stored in a computer-readable storage medium and loaded and executed by a processor. Therefore, embodiments of the present invention provide a storage medium storing multiple instructions that, when executed by a processor, can implement any step in the system recovery method provided in the above embodiments.

[0122] The storage medium may include: read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0123] Since the instructions stored in the storage medium can execute the steps in any embodiment of the system recovery method provided in the embodiments of the present invention, the beneficial effects that any system recovery method provided in the embodiments of the present invention can achieve can be realized. For details, please refer to the previous embodiments, which will not be repeated here.

[0124] The above provides a detailed description of a system recovery method, apparatus, electronic device, and storage medium provided in the embodiments of this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and its core ideas. Furthermore, those skilled in the art will recognize that, based on the ideas of this application, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of this application. Moreover, those skilled in the art can make several improvements and modifications without departing from the principles of this invention, and these improvements and modifications are also considered to be within the scope of protection of this invention.

Claims

1. A system recovery method, characterized in that, Applied to a virtualization platform cluster, wherein the virtualization platform cluster includes a first virtualization platform and multiple second virtualization platforms, the system recovery method includes: In response to a system recovery command, the system acquires the backup dataset and first configuration information of the first virtualization platform, as well as the second configuration information of the second virtualization platform. The configuration information includes hardware information, firmware information, and virtualization environment information. Based on the first configuration information and the second configuration information, a target virtualization platform is determined from a plurality of second virtualization platforms; Extract the target driver that is compatible with the target virtualization platform from the preset driver library; Based on the backup dataset and the target driver, construct a target system image file suitable for the target virtualization platform; The system image file is launched in the target virtualization platform, and a recovery operation is performed.

2. The system recovery method according to claim 1, characterized in that, The step of determining the target virtualization platform from multiple second virtualization platforms based on the first configuration information and the second configuration information includes: Calculate the similarity between the first configuration information and the second configuration information to obtain the similarity value between the first virtualization platform and each of the second virtualization platforms in terms of configuration information; Based on the similarity value, the target virtualization platform is determined from the second virtualization platform.

3. The system recovery method according to claim 2, characterized in that, The step of determining the target virtualization platform from the second virtualization platform based on the similarity value includes: When multiple candidate virtualization platforms with the same similarity value exist, the platform differences between the candidate virtualization platforms are detected. Based on the platform differences, a target virtualization platform is determined from a plurality of candidate virtualization platforms.

4. The system recovery method according to claim 3, characterized in that, The step of determining the target virtualization platform from multiple candidate virtualization platforms based on the platform differences includes: Based on the platform differences, the multiple candidate virtualization platforms are classified into different levels to obtain candidate virtualization platforms of different levels. The platform performance of the higher-level candidate virtualization platforms is greater than that of the lower-level candidate virtualization platforms. Based on the user level of the user who triggered the system recovery command, a target virtualization platform matching the user level is determined from a plurality of candidate virtualization platforms.

5. The system recovery method according to claim 4, characterized in that, The step of classifying multiple candidate virtualization platforms according to the platform differences to obtain candidate virtualization platforms of different levels includes: Predict the probability value of a target service running stably for a preset duration in each of the candidate virtualization platforms, wherein the target service is the service corresponding to the key service data in the backup dataset; Based on the platform performance differences of each candidate virtualization platform and the corresponding first weight coefficient, the probability value of each candidate virtualization platform and the corresponding second weight coefficient, calculate the running score of each candidate virtualization platform when it stably runs the target service, and the sum of the first weight coefficient and the second weight coefficient is 1; Based on the operational scores, the candidate virtualization platforms are classified into different levels to obtain candidate virtualization platforms of different levels.

6. The system recovery method according to claim 1, characterized in that, The step of constructing a target system image file suitable for the target virtualization platform based on the backup dataset and the target driver includes: Based on the backup dataset, the initial system image file is constructed. During the initial system image file construction process, a proxy application matching the target virtualization platform is invoked to perform the target driver injection operation, thereby obtaining a target system image file suitable for the target virtualization platform.

7. The system recovery method according to claim 6, characterized in that, Before the step of calling a proxy application matching the target virtualization platform to perform target driver injection during the initial system image file construction process to obtain a target system image file suitable for the target virtualization platform, the method further includes: Obtain the associated components related to the target virtualization platform; Identify the BIOS or UEFI firmware type of the target virtualization platform and obtain the identification result; The step of calling a proxy application matching the target virtualization platform to perform target driver injection during the initial system image file construction process, to obtain a target system image file suitable for the target virtualization platform, includes: During the initial system image file construction process, a proxy application matching the target virtualization platform is invoked to perform the injection operation of the target driver and the associated components, and the corresponding bootloader is repaired according to the identification result to obtain a target system image file suitable for the target virtualization platform.

8. A system recovery device, characterized in that, Applied in a virtualization platform cluster, the virtualization platform cluster including a first virtualization platform and multiple second virtualization platforms, the system recovery device includes: The acquisition module is used to acquire the backup dataset and first configuration information of the first virtualization platform and the second configuration information of the second virtualization platform in response to the system recovery command. The configuration information includes hardware information, firmware information and virtualization environment information. The determining module is configured to determine a target virtualization platform from a plurality of second virtualization platforms based on the first configuration information and the second configuration information; The extraction module is used to extract the target driver that is compatible with the target virtualization platform from the preset driver library; The build module is used to build a target system image file suitable for the target virtualization platform based on the backup dataset and the target driver; The recovery module is used to start the system image file in the target virtualization platform and perform a recovery operation.

9. An electronic device, characterized in that, The electronic device includes a processor, a memory, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the method as described in any one of claims 1 to 7.

Images