Virtual machine recovery method and device, computer device, readable storage medium and program product

Abstract

This application relates to a virtual machine recovery method, apparatus, computer device, readable storage medium, and program product, belonging to the field of data protection and recovery technology, and can improve the versatility of instant recovery. The method includes: creating a state machine and entering the system mounting phase of the state machine; in the system mounting phase, mounting a logical file system created based on snapshot data of the failed virtual machine to a local directory on a backup server; in the system sharing phase, sharing the local directory of the backup server with the platform server of the virtualization platform based on a common network file system protocol, so that the platform server mounts the local directory of the backup server; in the virtual machine startup phase, creating a normal virtual machine in the local directory of the backup server to trigger the platform server to run the normal virtual machine based on the snapshot data in the local directory of the backup server; wherein, when a rollback trigger event is detected, the state machine is used to execute the corresponding rollback operation according to the phase in which the state machine is located.

Description

Technical Field

[0001] This application relates to the field of data protection and recovery technology, and in particular to a virtual machine recovery method, apparatus, computer equipment, computer-readable storage medium, and computer program product. Background Technology

[0002] In virtualized data center environments, business continuity is of paramount importance. When production virtual machines crash due to logical errors, virus attacks, or hardware failures, they must be restored to an available state as quickly as possible. Traditional recovery methods involve completely copying the virtual machine's backup data from the backup storage system back to the production storage system. This approach can easily lead to excessively long Recovery Time Objectives (RTOs). To effectively shorten business downtime, Instant Recovery technology has emerged.

[0003] In related instant recovery technologies, the virtual machine backup data in the backup storage system is directly mounted to the cloud virtual machine (CVM) in the virtualization platform as data storage through relevant protocols, thereby starting the virtual machine.

[0004] However, this method heavily relies on the backup storage system supporting and emulating specific protocols compatible with the virtualization platform. If the backup storage system does not support these protocols, it will be unable to properly mount virtual machine backup data for use by the virtualization platform. Therefore, the immediate recovery of related virtual machines suffers from poor versatility and compatibility. Summary of the Invention

[0005] Therefore, it is necessary to provide a virtual machine recovery method, apparatus, computer equipment, computer-readable storage medium, and computer program product to address the aforementioned technical problems.

[0006] Firstly, this application provides a virtual machine recovery method, including:

[0007] In response to a recovery request for a faulty virtual machine, a state machine is created and the system mounting phase of the state machine is entered;

[0008] During the system mounting phase, the logical file system created based on the snapshot data of the faulty virtual machine is mounted to the local directory of the backup server, thus entering the system sharing phase of the state machine.

[0009] During the system sharing phase, the local directory of the backup server is shared with the platform server of the virtualization platform based on the general network file system protocol, so that the platform server mounts the local directory of the backup server and enters the state machine virtual machine startup phase;

[0010] During the virtual machine startup phase, a normal virtual machine is created in the local directory of the backup server to trigger the platform server to run the normal virtual machine based on the snapshot data in the local directory of the backup server.

[0011] When a rollback trigger event is detected, the state machine is used to perform the corresponding rollback operation according to the stage in which the state machine is currently.

[0012] In one embodiment, prior to the logical file system to be created based on the snapshot data of the failed virtual machine, the method further includes:

[0013] Obtain snapshot data of the faulty virtual machine;

[0014] Based on the synthesis result of the snapshot data and the writable space, the logical file system of the faulty virtual machine is obtained; wherein, the writable space is used to record the write operations of the normal virtual machine on the snapshot data.

[0015] In one embodiment, obtaining snapshot data of the faulty virtual machine includes:

[0016] Obtain the snapshot identifier input by the user for the faulty virtual machine; wherein, different snapshot identifiers correspond to snapshot data of the faulty virtual machine at different points in time;

[0017] Based on the snapshot identifier, retrieve the snapshot data corresponding to the snapshot identifier from the virtual machine backup storage pool.

[0018] In one embodiment, after sharing the backup server's local directory with the platform server of the virtualization platform based on the Common Network File System Protocol (CNNP), the method further includes:

[0019] A storage pool addition request is generated based on the directory path corresponding to the local directory of the backup server and the server identifier corresponding to the platform server in the virtualization platform.

[0020] Send the storage pool add request to the interaction interface of the virtualization platform to trigger the virtualization platform to control the platform server to mount the local directory of the backup server according to the directory path based on the server identifier carried in the storage pool add request.

[0021] In one embodiment, after creating a normal virtual machine in the local directory, the process further includes:

[0022] Obtain the export record identifier corresponding to the snapshot data;

[0023] Obtain the directory path corresponding to the local directory of the backup server, the shared record identifier of the local directory of the backup server, and the shared object identifier corresponding to the local directory of the backup server.

[0024] Based on the exported record identifier, the directory path corresponding to the local directory of the backup server, the shared record identifier, and the shared object identifier, the recovery task information of the faulty virtual machine is generated and saved.

[0025] In one embodiment, after creating a normal virtual machine in the local directory of the backup server to trigger the platform server to run the normal virtual machine based on the snapshot data in the local directory of the backup server, the method further includes:

[0026] The state machine enters the recovery end phase.

[0027] During the recovery completion phase, in response to the recovery completion signal for the faulty virtual machine, it is determined that the rollback trigger event has occurred, and the rollback operation is performed sequentially in the reverse order of the steps executed in the system mounting phase, the system sharing phase, and the virtual machine startup phase.

[0028] Secondly, this application also provides a virtual machine recovery device, comprising:

[0029] A creation module is used to create a state machine and enter the system mounting phase of the state machine in response to a recovery request for a faulty virtual machine;

[0030] The mounting module is used to mount the logical file system created based on the snapshot data of the faulty virtual machine to the local directory of the backup server during the system mounting phase, thus entering the system sharing phase of the state machine.

[0031] The sharing module is used to share the local directory of the backup server with the platform server of the virtualization platform based on the general network file system protocol during the system sharing phase, so that the platform server mounts the local directory of the backup server and enters the state machine virtual machine startup phase.

[0032] A startup module is used to create a normal virtual machine in the local directory of the backup server during the virtual machine startup phase, so as to trigger the platform server to run the normal virtual machine according to the snapshot data in the local directory of the backup server;

[0033] When a rollback trigger event is detected, the state machine is used to perform the corresponding rollback operation according to the stage in which the state machine is currently.

[0034] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the method described in any of the preceding claims.

[0035] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method described in any of the preceding claims.

[0036] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the method described in any of the preceding claims.

[0037] The aforementioned virtual machine recovery method, apparatus, computer equipment, computer-readable storage medium, and computer program product, in response to a recovery request for a faulty virtual machine, can create a state machine and enter the system mounting phase of the state machine. During the system mounting phase, a logical file system created based on the snapshot data of the faulty virtual machine is mounted to the local directory of the backup server, and then the state machine enters the system sharing phase. In the system sharing phase, the local directory of the backup server is shared with the platform server of the virtualization platform based on the Common Network File System Protocol (CNLP), so that the platform server mounts the local directory of the backup server, and the state machine enters the virtual machine startup phase. During the virtual machine startup phase, a normal virtual machine is created in the local directory of the backup server, thereby triggering the platform server to run the normal virtual machine based on the snapshot data in the local directory of the backup server. When a rollback trigger event is detected, the state machine can perform the corresponding rollback operation according to the phase it is in. In this embodiment, by mounting a logical file system created from the snapshot data of the faulty virtual machine to the local directory of the backup server, and then sharing the local directory of the backup server with the platform server of the virtualization platform based on the general network file system protocol, it can use standard and general network system file sharing protocols as a bridge, and is applicable to various mainstream virtualization platforms that support network file system data storage. This avoids the dependence on specific storage protocols during the virtual machine instant recovery process, and significantly improves the universality and compatibility of instant recovery technology. At the same time, by creating a state machine and executing corresponding processes at each stage of the state machine, this embodiment can perform fine-grained management of the entire virtual machine recovery process, and closely track and manage the entire life cycle of the instant recovery task, ensuring that the operation at each stage is traceable and controllable. By executing the corresponding rollback operation according to the stage of the state machine when a rollback trigger event is detected, the reliable creation and thorough cleanup of temporary resources during the recovery of the faulty virtual machine are guaranteed, and the generation of useless residual configuration information is avoided. Attached Figure Description

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

[0039] Figure 1 This is a flowchart illustrating a virtual machine recovery method in one embodiment;

[0040] Figure 2 This is a state diagram of a state machine in an instant recovery task in one embodiment;

[0041] Figure 3 This is a flowchart illustrating a virtual machine recovery method in another embodiment;

[0042] Figure 4 This is a flowchart illustrating yet another virtual machine recovery method in another embodiment;

[0043] Figure 5 This is a structural block diagram of a virtual machine recovery device in one embodiment;

[0044] Figure 6 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0045] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0046] It should be noted that the terms "comprising" and "having," and any variations thereof, as used in this application, are intended to cover non-exclusive inclusion. The term "multiple" as used in this application refers to two or more. The term "and / or" as used in this application refers to one of the solutions, or any combination of multiple solutions.

[0047] In a virtualized data center environment, business continuity is of paramount importance. When production virtual machines crash due to logical errors, virus attacks, or hardware failures, they must be restored to an available state as quickly as possible. Traditional recovery methods involve completely copying the virtual machine's backup data from the backup storage system back to the production storage system. This process is time-consuming, depending on the size of the backup data and network bandwidth, and can actually take several hours or even longer, resulting in excessively long business interruptions. Business interruption time can be understood as the longest time it takes for an information system or business function to recover to an acceptable level after a failure, also known as the recovery time target.

[0048] In order to effectively shorten business interruption time, instant recovery technology has emerged. Its core idea is to allow virtual machines to run directly on the backup storage system without moving backup data. In other words, instant recovery of virtual machines allows virtual machines to start and run directly from the backup storage system without having to copy the data back to the production storage system first.

[0049] In related instant recovery technologies, the main approach is to mount virtual machine backup data from the backup storage system to the virtualization platform. For example, based on the Internet Small Computer System Interface (iSCSI) protocol or other proprietary protocols, the virtual machine backup data in the backup storage system is simulated as a block storage device for the virtualization platform to mount and use. In this approach, the backup server in the backup storage system assumes the function of a storage server and responds to read and write requests from the virtualization platform.

[0050] However, this approach heavily relies on the backup storage system's ability to support and emulate specific protocols compatible with the virtualization platform. It also requires the virtualization platform to support the corresponding block storage device emulation protocols. If the backup storage system lacks this capability, complex methods are needed to achieve the above process, and it may even be impossible to mount virtual machine backup data to the virtualization platform for use. Therefore, related instant recovery technologies suffer from poor versatility and compatibility.

[0051] This application provides a virtual machine recovery method, apparatus, computer device, computer-readable storage medium, and computer program product that can avoid dependence on specific protocols and effectively improve the platform compatibility and versatility of virtual machine instant recovery.

[0052] In one embodiment, such as Figure 1 As shown, a virtual machine recovery method is provided, and its application to a backup server is illustrated. In this embodiment, the method includes the following steps:

[0053] Step S101: In response to the recovery request for the faulty virtual machine, a state machine is created and the system mounting phase of the state machine is entered.

[0054] In this context, a faulty virtual machine can be understood as a virtual computer instance in a virtualization platform that cannot function properly. In some examples, the failure may be caused by one or more reasons such as hardware failure, software error, or network interruption.

[0055] In this context, a state machine can be understood as a model used to control the state transitions of a process. A state machine can contain multiple preset stages and transition rules between stages. It can record the current stage and trigger corresponding operations. In this embodiment, the entire process of virtual machine recovery can be tracked through a state machine.

[0056] In this step, a recovery request for a faulty virtual machine can be received. The recovery request is used to request virtual machine recovery to restore it to a normal operating state. In some embodiments, the recovery request can be generated via API calls, graphical interface operations, or script triggering.

[0057] In some embodiments, recovery requests can be initiated by the user or automatically by the virtualization platform based on monitoring data of the virtual machine. For example, when the virtualization platform detects a failure (such as continuous unresponsiveness or process crash) in a virtual machine (e.g., VM01 running a database service), the system monitoring module of the virtualization platform will automatically generate a recovery request for VM01; alternatively, the user can manually submit a recovery request for VM01 through the management platform.

[0058] In response to a received recovery request, the backup server can create a state machine and enter the system mounting phase of the state machine. The system mounting phase can be the initial working phase of the state machine, and its main task is to complete the creation and mounting preparation of the logical file system for the snapshot data of the failed virtual machine.

[0059] Specifically, after receiving a recovery request, the backup server can create a state machine instance. This state machine includes multiple phases such as the system mounting phase, the system sharing phase, and the virtual machine startup phase, as well as the corresponding rollback logic for each phase. After the state machine is created, its current state can be set to the system mounting phase to initiate subsequent mounting operations.

[0060] In step S102, during the system mounting phase, the logical file system created based on the snapshot data of the faulty virtual machine is mounted to the local directory of the backup server, thus entering the system sharing phase of the state machine.

[0061] Snapshot data can be understood as a logical read-only copy of a specified dataset at a specific point in time. In some examples, snapshot data may include data obtained by making a consistent backup of one or more information such as the virtual machine's disk status, memory data, and configuration information before the virtual machine fails. Snapshot data can be stored in the form of files.

[0062] The logical file system (LFS) is a network file system (NFS) built upon snapshot data. The LFS can map the content and / or storage structure of snapshot data, allowing other devices to read and write the snapshot data as if it were a local file. The network file system, based on a distributed file system protocol, allows computers on a network to share files and directories over the network, just like accessing local storage.

[0063] The local directory of the backup server can be a local path on the backup server used to mount logical file systems, also known as the local mount point of the backup server.

[0064] In practical applications, during the system mounting phase, the backup server can obtain the snapshot data of the faulty virtual machine from the module storing snapshot data and create a logical file system based on the snapshot data. In some embodiments, a corresponding logical file system can be created for the snapshot data using file system tools.

[0065] After acquiring the logical file system, the backup server can mount this newly created logical file system to its local directory. For example, a temporary mount point (mount_point_) can be set on the backup server, and the logical file system can be mounted to that temporary mount point. After mounting is complete, the state machine can switch from the system mount phase to the system share phase.

[0066] In some optional embodiments, if the snapshot data is in an incremental backup format (such as differential snapshots based on a baseline backup), the logical file system creation process can also merge the baseline backup and incremental snapshot data to generate a complete virtual disk image.

[0067] In step S103, during the system sharing phase, the local directory of the backup server is shared with the platform server of the virtualization platform based on the general network file system protocol, so that the platform server mounts the local directory of the backup server and enters the state machine virtual machine startup phase.

[0068] The Common Network File System (CFS) protocol can be understood as a standardized protocol that allows different devices to share file resources over a network. For example, the Common Network File System protocol may include one or more of the following: Network File System (NFS), Common Internet File System (CIFS), Server Message Block (SMB).

[0069] In this context, the platform server can be understood as the physical server in the virtualization platform that is responsible for managing the lifecycle of virtual machines. In some examples, this physical server can perform operations such as creating, starting, and stopping virtual machines.

[0070] In practice, after entering the system sharing phase, the backup server can share the local mounted directory with the platform server of the virtualization platform via the network. In some examples, this platform server can also be called the target virtual machine monitor (Hypervisor). It is a host under the Cloud Virtualization Kernel (CVK) architecture and is the physical server that will run the restored virtual machine.

[0071] Subsequently, the virtualization platform can instruct the platform server to mount the shared local directory of the backup server. Upon receiving the instruction, the platform server can mount the remote local directory of the backup server. After confirming that the platform server has successfully mounted the local directory of the backup server, the state machine can switch from the system sharing phase to the virtual machine startup phase.

[0072] In this step, the previously created logical file system can be exported as a network share using the common network file system protocol as a bridge. Since the network file system is a mature protocol supported by almost all mainstream virtualization platforms, this greatly improves the universality and compatibility of the virtual machine recovery method of this application and decouples the backup storage from the underlying technology of the virtualization platform.

[0073] Step S104: During the virtual machine startup phase, a normal virtual machine is created in the local directory of the backup server to trigger the platform server to run the normal virtual machine based on the snapshot data in the local directory of the backup server.

[0074] When a rollback trigger event is detected, the state machine is used to execute the corresponding rollback operation according to the stage the state machine is in.

[0075] In practice, after entering the virtual machine startup phase, the backup server can create a normal virtual machine in its local directory. A normal virtual machine can be understood as a new, operational virtual machine instance created based on snapshot data of the failed virtual machine. In some examples, the configuration information (such as hardware configuration and / or software environment) of the normal virtual machine can be similar to or the same as that of the failed virtual machine.

[0076] In some embodiments, during the virtual machine startup phase, the backup server can obtain the virtual machine configuration information of the failed virtual machine through snapshot data. For example, it can obtain one or more configuration information such as the number of CPU cores and memory size of the virtual machine to be created. Then, based on the obtained configuration information, the backup server can create a new virtual machine in the local directory of the backup server.

[0077] In one embodiment, a normal virtual machine can be created by creating a virtual disk file (such as a file of type .vmdk, .qcow2, etc.) in the local directory of the backup server. Alternatively, the virtual disk file of the normal virtual machine can also be pointed to a logical file system in the local directory of the backup server.

[0078] Because the backend data stored in this logical file system originates from snapshot data of the faulty virtual machine, once a normal virtual machine on the platform server starts, it can access the original data of the faulty virtual machine based on the snapshot data in the local directory of the backup server. This allows the normal virtual machine to continue running based on the snapshot data, thus achieving fault recovery.

[0079] Furthermore, in this embodiment, during the execution of the above steps, the execution results of each stage of the operation can be monitored. When a rollback trigger event is detected, the state machine can execute the corresponding rollback operation according to the current stage. Here, a rollback trigger event refers to a specific event that triggers the rollback operation. In some examples, it can be triggered by the recovery completion signal of the faulty virtual machine; that is, when the system receives this signal, it determines that a rollback trigger event has occurred. Alternatively, it can be determined that a rollback trigger event has occurred when a fault is detected during the virtual machine recovery process.

[0080] Specifically, a normally restored virtual machine is in a temporary state, and the new data generated during its operation needs to be properly managed. However, related technologies often struggle to provide efficient and accurate lifecycle management for virtual machines restored instantly. After the recovery task of a normally restored virtual machine is completed, there is a lack of a unified and automated management mechanism for cleanly and efficiently removing all temporary configurations (such as iSCSI mounts and data storage) and processing incremental data.

[0081] In this embodiment, upon receiving a recovery request for a faulty virtual machine, a state machine can be created, and multiple steps in the fault recovery process can be executed based on the state machine. Reliable process control driven by the state machine allows the entire immediate recovery process of the faulty virtual machine to be driven by a precisely defined state machine. This ensures that each step in the immediate recovery process is executed in a predetermined order. Furthermore, when a rollback trigger event is detected requiring the cleanup of data generated during the immediate recovery process, a reverse rollback operation can be precisely executed based on the current stage (or state) of the state machine, guaranteeing system robustness and data consistency. In some embodiments, the executed rollback operation may include one or more of the following: a rollback operation during the system mounting phase, a rollback operation during the system sharing phase, or a rollback operation during the virtual machine startup phase.

[0082] In the above virtual machine recovery method, in response to a recovery request for a faulty virtual machine, a state machine can be created and enter the system mounting phase of the state machine. During the system mounting phase, a logical file system created based on the snapshot data of the faulty virtual machine is mounted to the local directory of the backup server, and then the state machine enters the system sharing phase. In the system sharing phase, the local directory of the backup server is shared with the platform server of the virtualization platform based on the general network file system protocol, so that the platform server mounts the local directory of the backup server, and the state machine enters the virtual machine startup phase. During the virtual machine startup phase, a normal virtual machine is created in the local directory of the backup server, thereby triggering the platform server to run the normal virtual machine based on the snapshot data in the local directory of the backup server. When a rollback trigger event is detected, the state machine can perform the corresponding rollback operation according to the phase it is in. In this embodiment, by mounting a logical file system created from the snapshot data of the faulty virtual machine to the local directory of the backup server, and then sharing the local directory of the backup server with the platform server of the virtualization platform based on the general network file system protocol, it can use standard and general network system file sharing protocols as a bridge, and is applicable to various mainstream virtualization platforms that support network file system data storage. This avoids the dependence on specific storage protocols during the virtual machine instant recovery process, and significantly improves the universality and compatibility of instant recovery technology. At the same time, by creating a state machine and executing corresponding processes at each stage of the state machine, this embodiment can perform fine-grained management of the entire virtual machine recovery process, and closely track and manage the entire life cycle of the instant recovery task, ensuring that the operation at each stage is traceable and controllable. By executing the corresponding rollback operation according to the stage of the state machine when a rollback trigger event is detected, the reliable creation and thorough cleanup of temporary resources during the recovery of the faulty virtual machine are guaranteed, and the generation of useless residual configuration information is avoided.

[0083] On the other hand, related instant recovery technologies also suffer from the problem of incompatible data formats. Backup data is typically stored in a specific format within the backup storage file system. Exporting backup data as block devices (such as iSCSI LUNs) often requires format conversion or complex logical mapping, increasing system complexity and potential performance bottlenecks. In this embodiment, by using a common network file system protocol to share the backup server's local directory with the virtualization platform's platform server, there is no need to export backup data as data blocks, effectively reducing the complexity of instant recovery processing and the consumption of system resources. Through the method provided in this embodiment, virtual machines can start in a very short time without waiting for the transmission of terabyte (TB) level data, significantly reducing service interruption time.

[0084] In one embodiment, step S102 may further include the following steps before creating the logical file system based on the snapshot data of the failed virtual machine:

[0085] Obtain snapshot data of the faulty virtual machine; based on the synthesis result of the snapshot data and the writable space, obtain the logical file system of the faulty virtual machine; wherein, the writable space is used to record the write operations of the normal virtual machine to the snapshot data.

[0086] In this context, writable space can be understood as the storage space used by the normal virtual machine corresponding to the faulty virtual machine during its operation to perform write operations (such as modifying data, adding data, deleting data, or any one or more) on content derived from snapshot data. This space can be specifically used to record the specific content and location information of these write operations. Writable space can be a specially allocated storage space that is independent of the original snapshot data. It is used to record various write operations performed by the normal virtual machine on the snapshot data at the target time point during its operation, which can avoid directly modifying the original snapshot data and ensure the integrity and reusability of the snapshot data.

[0087] In practical implementation, one approach is to acquire snapshot data of the failed virtual machine. In one example, the snapshot data can be snapshot data at a target time point, such as a pre-set regular backup time point, or a time point calculated based on the time of the failure that reflects the critical state before the failure. Another approach is to prepare corresponding writable space in advance.

[0088] Furthermore, the snapshot data and writable space can be synthesized to obtain the logical file system of the faulty virtual machine. By synthesizing the two into a logical file system, it is ensured that the logical file system contains the basic state of the virtual machine at the target time point and can also record subsequent modification operations.

[0089] In one embodiment, before creating a logical file system, the backup server can first obtain snapshot data of the failed virtual machine and allocate a writable space of size X for the failed virtual machine. This writable space is initially empty and will be used to record all write operations during the subsequent operation of a normal virtual machine. Then, the backup server can use a file system synthesis tool to synthesize the snapshot data and the writable space. For example, the snapshot data can be used as the base image and the writable space as the incremental image through relevant synthesis instructions. When a normal virtual machine performs write operations on the file system, the modified data will be recorded in the writable space, while the original snapshot data remains unchanged.

[0090] In another embodiment, snapshot data can be stored in a remote storage array. The backup server can mount the storage array via the iSCSI protocol and then copy the snapshot data to a local temporary directory. The writable space can be partitioned using logical volume management, meaning a separate logical volume can be created as the writable space. Subsequently, the backup server can use file system merging software to combine the snapshot data and the logical volume into a logical file system. This software can track data changes in the writable space in real time and automatically merge the snapshot data and data in the writable space when accessing the logical file system.

[0091] In this embodiment, by acquiring snapshot data and combining it with writable space to form a logical file system, the integrity of the snapshot data is utilized, and subsequent modifications can be recorded through writable space, thus avoiding damage to the original snapshot data and improving data security and reusability.

[0092] In one embodiment, obtaining snapshot data of a faulty virtual machine may include the following steps:

[0093] Obtain the snapshot identifier input by the user for the faulty virtual machine; wherein, different snapshot identifiers correspond to snapshot data of the faulty virtual machine at different points in time; and obtain the snapshot data corresponding to the snapshot identifier from the virtual machine backup storage pool according to the snapshot identifier.

[0094] The snapshot identifier (snapshot_id), also known as the backup point, is information used to uniquely identify the snapshot data generated by the faulty virtual machine at a specific point in time. For example, the snapshot identifier can be a string of characters, numbers, codes, or a combination thereof.

[0095] A virtual machine backup storage pool can be understood as a storage space specifically used to store various snapshot data of virtual machines. It can be a logical storage pool composed of one or more storage devices and has functions such as data backup and disaster recovery.

[0096] In practical applications, after a virtual machine fails, users can select the required snapshot data from multiple historical snapshots of the failed virtual machine. For example, the snapshot data may include one or more of the following: virtual machine disk image file, memory snapshot file, virtual machine configuration file, etc.

[0097] In an exemplary embodiment, when virtual machine A fails to start due to hardware failure, if the user needs to restore it, the backup server can be triggered to display relevant information of all historical snapshots of virtual machine A to the user, including the snapshot identifier corresponding to each snapshot. Then, the user can enter the snapshot identifier selected by the user in the input interface (such as command line interface, graphical operation interface, etc.) according to the time point to be restored, so that the server can obtain the snapshot identifier.

[0098] Since different snapshot identifiers correspond to snapshot data generated by the faulty virtual machine at different points in time, after obtaining the snapshot identifier input by the user, the backup server can search in the virtual machine backup storage pool according to the snapshot identifier, and then obtain the snapshot data corresponding to the identifier.

[0099] In an optional embodiment, the backup server can look up snapshot data using the hash value corresponding to the snapshot identifier. Specifically, each snapshot identifier corresponds to a unique hash value. After obtaining the snapshot identifier input by the user, the snapshot identifier can be converted into its corresponding hash value, and then the corresponding snapshot data can be quickly located in the virtual machine backup storage pool based on this hash value. Since snapshot identifiers may be long strings or complex identifiers, looking up snapshot data based on the hash value corresponding to the snapshot identifier can effectively improve lookup efficiency, especially when the amount of snapshot data in the virtual machine backup storage pool is large.

[0100] In this embodiment, when a virtual machine fails, the user can input the corresponding snapshot identifier according to actual needs. The backup server can then accurately and quickly obtain the snapshot data corresponding to the identifier from the virtual machine backup storage pool. This allows for efficient and accurate acquisition of the required historical snapshot data when a virtual machine fails, enabling the recovery of the failed virtual machine and the analysis of the cause of the failure to proceed smoothly, thereby improving the reliability and availability of the system.

[0101] In some other embodiments, snapshot data can be obtained by retrieving it from the virtual machine's backup storage system. For example, if the faulty virtual machine belongs to a cloud computing platform, the platform can periodically perform snapshot backups of the virtual machine and store them in a distributed storage system. In this case, the corresponding snapshot data can be retrieved by accessing the distributed storage system based on the unique identifier of the faulty virtual machine and the target time point.

[0102] In one embodiment, after sharing the backup server's local directory with the platform server of the virtualization platform based on the Common Network File System Protocol (CNNP) in step S103, the following steps may also be included:

[0103] A storage pool add request is generated based on the directory path corresponding to the local directory of the backup server and the server identifier corresponding to the platform server in the virtualization platform. The storage pool add request is sent to the interaction interface of the virtualization platform to trigger the virtualization platform to control the platform server to mount the local directory of the backup server according to the directory path based on the server identifier carried in the storage pool add request.

[0104] The directory path can be a string that identifies the location of the local directory of the backup server in the backup server's file system, such as " / backup / data_store".

[0105] A server identifier can be a unique identifier assigned by the virtualization platform to each platform server, used to distinguish different platform servers within the virtualization platform. For example, a server identifier can be any of the following: the server's hostname, Internet Protocol (IP) address, or platform internal number.

[0106] A storage pool add request is a message used to request the virtualization platform to add a specified storage resource (such as a local directory on a backup server) as a storage pool. This message may contain key information required to add the storage pool, such as the directory path and server identifier.

[0107] The interaction interface of a virtualization platform may include interfaces provided by the virtualization platform for receiving external commands and data, such as API interfaces or interfaces based on the Hypertext Transfer Protocol (HTTP).

[0108] Specifically, some virtual machine instant recovery technologies still suffer from complex configuration and management issues. For example, during virtual machine failure recovery, users may need to manually or through complex application programming interfaces (APIs) on the hypervisor to configure the iSCSI initiator, discover targets, log in, and format them to a dedicated data storage format. The entire process involves multiple steps, is difficult to automate, and is prone to errors.

[0109] In this embodiment, after the backup server completes the sharing of its local directory based on the NFS protocol, it can prepare the information required to generate a storage pool add request. Specifically, the backup server sets its local directory to be shared using the Common Network File System protocol, allowing access from platform servers in the virtualization platform. At this point, the directory path corresponding to the shared backup server local directory can be determined, as well as the server identifier of the platform server that needs to mount the directory. A storage pool add request is then generated based on the directory path and the server identifier. In some examples, this request may also include other parameters, such as: the storage pool type is NFS, the target Hypervisor host ID (i.e., the server identifier), the NFS server IP (i.e., the backup server IP nfs_addr_), and the NFS shared path (mount_point_) of the backup server's local directory.

[0110] Then, the backup server can connect to the virtualization platform via a RESTful API (an architecture for designing network interfaces based on the HTTP protocol) and send a storage pool addition request to the interactive interface after connecting. In other embodiments, the connection between the backup server and the virtualization platform can also be implemented using other RPC frameworks, such as gRPC, Simple Object Access Protocol (SOAP), etc., depending on the API type of the virtualization platform.

[0111] After receiving a storage pool addition request, the virtualization platform can control the corresponding platform server to mount the backup server's local directory according to the directory path based on the server identifier carried in the request. This allows the platform server to register the backup server's local directory as a new available data storage, i.e., a new available storage pool. The name and path of this storage pool can be guaranteed to be unique using the unique identifier nfs_record_uuid_ corresponding to the NFS sharing record obtained when the backup server's local directory is shared. Controlling the platform server to mount the backup server's local directory according to the directory path can be understood as associating the backup server's shared directory with a directory (i.e., the mount point) in the platform server's local file system, allowing the platform server to access the shared directory as if it were a local directory.

[0112] In this embodiment, after sharing a directory based on the Common Network File System (CLS) protocol, a storage pool addition request containing the directory path and server identifier is automatically generated. The mount operation is then triggered through the virtualization platform's interactive interface. On one hand, this allows backup server storage resources to be automatically integrated into the virtualization platform. This simplifies the storage pool configuration process, eliminating the need for administrators to manually perform mount operations on each platform server, improving configuration efficiency, and achieving automated platform integration and lifecycle management. The entire process is automated, maintenance is simple, and no manual intervention is required, significantly reducing operational complexity and error rates. On the other hand, through interactive interface calls, NFS storage registration on the target virtualization platform is completed automatically without manual intervention. Furthermore, standardized request formats and interface interactions ensure compatibility of storage resource access under different protocols and virtualization platforms. Finally, mounting the storage pool based on the server identifier and directory path information ensures the accuracy of the mount operation and avoids mount failures caused by manual input errors.

[0113] Furthermore, this embodiment implements a two-layer mounting system: the logical file system is mounted to a mount point on the backup server, and then the mount point is mounted to the platform server. This two-layer mounting structure achieves separation of responsibilities. The dedicated backup server handles the complex storage logic of synthesizing the file system based on snapshots. Subsequently, the platform server only needs to mount this ready-made storage via the standard NFS protocol, without needing to concern itself with its backend implementation, thus achieving architectural decoupling and versatility. The method provided in this embodiment effectively decouples the strong relationship between production storage and backup storage, allowing virtual machines to run directly on low-cost backup storage, providing a cost-effective sandbox environment for development testing, patch verification, data analysis, and other scenarios.

[0114] In one embodiment, after creating a normal virtual machine in the local directory of the backup server during the virtual machine startup phase, the following steps may also be included:

[0115] Obtain the export record identifier corresponding to the snapshot data; obtain the directory path, the shared record identifier, and the shared object identifier corresponding to the local directory of the backup server; generate and save the recovery task information for the faulty virtual machine based on the export record identifier, the directory path, the shared record identifier, and the shared object identifier.

[0116] The export record identifier can be an identifier used to uniquely identify the process of exporting the snapshot data from the original storage location to the backup server. It can be a string of numbers, letters, or a combination of both, such as "EXP-202X0X16-12345". Through this identifier, detailed information related to the export of the snapshot data can be quickly retrieved, such as the export time, export source location, and export status.

[0117] Specifically, in this step, the export record identifier corresponding to the snapshot data currently used to create a normal virtual machine can be obtained from the storage system or related log records of the backup server. In an exemplary embodiment, the backup server may have a corresponding database that stores detailed records of each snapshot data export, and each record may contain a corresponding export record identifier and a unique identifier for the snapshot data (such as a snapshot ID). In other embodiments, the export record identifier may also be included in the metadata information of the snapshot data. In this case, the backup server can directly read the metadata of the snapshot data and extract the export record identifier from it.

[0118] In addition, it is also possible to obtain the directory path corresponding to the local directory of the backup server, the shared record identifier of the local directory of the backup server, and the shared object identifier corresponding to the local directory of the backup server.

[0119] The shared record identifier is an identifier used to uniquely identify the operation record in which a local directory on the backup server is set as a shared directory. It can be in the form of numbers, letters, etc., and can be used to query one or more pieces of information such as the setting time of the directory sharing and sharing permissions. The shared object identifier is an identifier used to uniquely identify the local directory on the backup server that is being shared.

[0120] Furthermore, recovery task information for the failed virtual machine can be generated based on the export record identifier, the directory path corresponding to the local directory of the backup server, the shared record identifier, and the shared object identifier. This information is then stored in a designated location for quick retrieval when a failed virtual machine needs to be recovered. By integrating the above key information, various metadata of the entire instant recovery task (such as snapshot ID, NFS share information, target VM information, etc.) can be recorded in a unified Copy Data Management (CDM) directory, achieving automated management of the entire lifecycle from creation and operation to cleanup.

[0121] In this embodiment, after a normal virtual machine is created, by generating and saving faulty virtual machine recovery task information containing export record identifiers, directory paths, share record identifiers, and share object identifiers, it is possible to quickly locate the source of the required snapshot data, the storage location of the normal virtual machine, and related share access information when a faulty virtual machine needs to be recovered. Simultaneously, the integration and saving of this information makes the recovery process traceable, facilitating subsequent backtracking and analysis of recovery operations. Furthermore, generating faulty virtual machine recovery task information helps to rigorously track and manage the entire lifecycle of immediate recovery tasks, preventing the generation of zombie configurations.

[0122] In one embodiment, after creating a normal virtual machine in the local directory of the backup server to trigger the platform server to run the normal virtual machine based on the snapshot data in the local directory of the backup server, the following steps may also be included:

[0123] The state machine enters the recovery end phase; in the recovery end phase, in response to the recovery end signal for the faulty virtual machine, it is determined that a rollback trigger event has been detected, and the rollback operation is performed in reverse order of the steps executed in the system mount phase, system sharing phase and virtual machine startup phase.

[0124] The recovery end phase of the state machine can be a state phase in the state machine that indicates the virtual machine fault recovery process has been completed. In this phase, the system can receive and process subsequent instructions related to recovery.

[0125] The recovery completion signal for a faulty virtual machine is a signal used to inform the backup server that the recovery process for the faulty virtual machine has been completed. This signal can be generated manually or detected after data migration is completed.

[0126] A rollback operation can be understood as the operation of restoring a virtual machine fault recovery task to a previous state. In this embodiment, during the recovery end phase, the rollback operation is executed in the reverse order of the system mounting phase, the system sharing phase, and the virtual machine startup phase.

[0127] In practical applications, during the recovery completion phase, the backup server can detect whether the recovery has ended and then trigger a rollback operation. Specifically, after creating a normal virtual machine in the backup server's local directory and triggering the platform server to run the normal virtual machine, the recovery process of the faulty virtual machine is determined to be complete, and the state machine switches from the recovery in progress phase to the recovery completion phase. During the recovery completion phase, the backup server can wait for the recovery completion signal.

[0128] When a recovery completion signal is detected, it is determined that a rollback trigger event has occurred, and preparations are made to execute the rollback operation. Specifically, all creation operations can be executed in reverse order based on the state (state_) at the end of the virtual machine failure recovery task.

[0129] In this embodiment, the automatic triggering of the rollback operation during the recovery end phase reduces manual intervention and improves the efficiency of the system in adjusting its state after fault recovery. At the same time, the rollback operation is performed in reverse order, which ensures the orderly release of system resources and avoids resource residues or conflicts caused by disordered operation order. This ensures the reliable creation and thorough cleanup of temporary resources during virtual machine recovery and prevents residual configurations from affecting subsequent system operation.

[0130] To enable those skilled in the art to better understand the above steps, the following is combined with... Figures 2 to 4 The present application is illustrated by way of example through embodiments, but it should be understood that the present application is not limited thereto.

[0131] In this embodiment, the above method can be applied to a virtual machine management system, which includes a backup server, a backup storage pool, a virtualization platform, and a target hypervisor. The backup server executes the method provided in this embodiment and manages the backup storage pool. The backup storage pool stores virtual machine backup data and snapshots. The virtualization platform, also known as a virtualization management platform, is the control center for managing the target hypervisor cluster. The target hypervisor is the physical server on which the restored virtual machines will run.

[0132] In this embodiment, an Instant_Recovery class is used for coordination, and its core process is driven by an internal state machine to ensure the sequentiality and rollbackability of operations. In one embodiment, the various states of this state machine during operation can be as follows: Figure 2 As shown, it includes multiple nodes, and one or more of these nodes can belong to the system mounting phase, system sharing phase, virtual machine startup phase, and recovery completion phase, respectively.

[0133] like Figure 3 As shown, this embodiment may include the following steps:

[0134] S301, during the system mount phase, creates and mounts the logical file system.

[0135] During this phase, the state machine switches between the INIT, FS_CREATED, and FS_MOUNTED nodes in sequence.

[0136] Specifically, such as Figure 4As shown, the user can first select a virtual machine backup point (identified by snapshot_id) to trigger an instant recovery task. Then, an Instant_Recovery object is created with a state of INIT.

[0137] Then, the `create_and_mount_fs` method is called. The backup server connects to the backup storage pool (`pool_client_`) and dynamically creates a new, unique, read-write logical file system (`fs_name_`) based on the specified `snapshot_id`. This file system is synthesized; it shares the read-only data of the snapshot with other devices on the network and redirects all write operations to the new storage space. After this operation is completed, the state machine changes to `FS_CREATED`. Next, the backup server mounts this newly created logical file system to a temporary mount point (`mount_point_`) on the backup server's local machine, and the state machine changes to `FS_MOUNTED`. The dynamic generation of the logical file system based on the snapshot occurs at the backup storage end, rather than directly exposing the backup image. That is, based on the selected virtual machine backup snapshot, a new, read-write logical file system is created immediately. This file system logically contains all the data from the snapshot and can independently record new written data.

[0138] In some optional embodiments, a "replica sharing" operation can then be recorded via the replica data management module (cdm_op_) to generate a unique export task ID (cdm_exportation_uuid_).

[0139] S302, during the system sharing phase, exports NFS shares and adds NFS storage to the virtualization platform.

[0140] During this phase, the state machine switches between the FS_MOUNTED, NFS_EXPORTED, and CVK_NFS_ADDED nodes in sequence.

[0141] This step is triggered to continue execution after step S301 is successfully executed.

[0142] like Figure 4 As shown, during execution, the export_nfs method is called. The backup server uses the NFS operator (nfs_op_) to export the local mount point (mount_point_) from the previous step as an NFS share, thereby allowing other host devices in the network to access it. This NFS share record obtains a unique ID (nfs_record_uuid_), and at this time the state machine state changes to NFS_EXPORTED.

[0143] Next, NFS storage is added to the virtualization platform. Specifically, the `add_cvk_nfs_pool` method is called first. The backup server connects to the virtualization management platform via a RESTful API, then calls the API to add a storage pool and sends a storage pool addition request. The parameters in this request include: type NFS, target Hypervisor host ID, NFS server IP (i.e., the backup server IP `nfs_addr_`), and NFS share path (`mount_point_`). Then, based on the received request, CVM instructs the target Hypervisor to mount this NFS share and register it as a new available data store. The name and path of this storage pool both use `nfs_record_uuid_` to ensure uniqueness. At this point, the state machine's state changes to `CVK_NFS_ADDED`.

[0144] S303 creates and starts the virtual machine during the virtual machine startup phase.

[0145] Specifically, such as Figure 4 As shown, this step involves creating a new virtual machine and starting it on the NFS data store added in the previous step. At this point, the virtual machine runs on the target hypervisor, but all its disk I / O is forwarded to the backup server via the NFS protocol and handled by the synthetic file system on the backup server.

[0146] The virtual disk files (.vmdk, .qcow2, etc.) of the virtual machine are pointed to or created on this NFS storage. Since the backend data of this NFS storage comes from backup snapshots, the virtual machine can access its original data after it starts up.

[0147] In addition, the state and save directory can be updated, at which point the state machine's state changes from CVK_NFS_ADDED to VM_CREATED. This operation can be achieved by calling the `set_vm_created` method, which notifies the system via the Copy Data Management (CDM) module that the export task has been successfully mounted and used, and the virtual machine's state changes to VM_CREATED. Then, the `save_cdm_catalog` method is called to package all key metadata (including various UUIDs, names, paths, etc.) of this instant recovery task into a JSON object and save it to the central catalog database for subsequent metadata management and tracking. Of course, in other examples, the Copy Data Management (CDM) catalog can be used to track metadata, or other databases or key-value stores (such as etcd, Redis) can be used instead to ensure transactionality and consistency.

[0148] S304, during the recovery completion phase, performs cleanup and uninstallation.

[0149] This process can be triggered when the immediate recovery task ends (e.g., when manually stopped by the user or after data migration is complete). In this step, the `cleanup` method is called, which performs all creation operations in reverse order based on the task's end state (`state_`). Specifically, starting from the `VM_CREATED` state, the following operations can be executed sequentially: notify CDM to unload, delete the NFS storage pool registered on CVM, cancel NFS share export, unload the local file system, and delete the synthetic file system created based on the snapshot. This state machine-based rollback ensures that all temporary resources are cleanly and reliably released regardless of at which step the task is interrupted.

[0150] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.

[0151] Based on the same inventive concept, this application also provides a virtual machine recovery apparatus for implementing the virtual machine recovery method described above. The solution provided by this apparatus is similar to the implementation described in the above method; therefore, the specific limitations in one or more virtual machine recovery apparatus embodiments provided below can be found in the limitations of the virtual machine recovery method described above, and will not be repeated here.

[0152] In one exemplary embodiment, such as Figure 5 As shown, a virtual machine recovery device is provided, comprising:

[0153] Module 501 is created to create a state machine and enter the system mounting phase of the state machine in response to a recovery request for a faulty virtual machine.

[0154] Mounting module 502 is used to mount the logical file system created based on the snapshot data of the faulty virtual machine to the local directory of the backup server during the system mounting phase, and enter the system sharing phase of the state machine.

[0155] The sharing module 503 is used to share the local directory of the backup server with the platform server of the virtualization platform based on the general network file system protocol during the system sharing phase, so that the platform server mounts the local directory of the backup server and enters the state machine virtual machine startup phase.

[0156] The startup module 504 is used to create a normal virtual machine in the local directory of the backup server during the virtual machine startup phase, so as to trigger the platform server to run the normal virtual machine according to the snapshot data in the local directory of the backup server.

[0157] When a rollback trigger event is detected, the state machine is used to perform the corresponding rollback operation according to the stage in which the state machine is currently.

[0158] In one embodiment, the mounting module 502 is used for:

[0159] Obtain snapshot data of the faulty virtual machine;

[0160] Based on the synthesis result of the snapshot data and the writable space, the logical file system of the faulty virtual machine is obtained; wherein, the writable space is used to record the write operations of the normal virtual machine on the snapshot data.

[0161] In one embodiment, the mounting module 502 is used for:

[0162] Obtain the snapshot identifier input by the user for the faulty virtual machine; wherein, different snapshot identifiers correspond to snapshot data of the faulty virtual machine at different points in time;

[0163] Based on the snapshot identifier, retrieve the snapshot data corresponding to the snapshot identifier from the virtual machine backup storage pool.

[0164] In one embodiment, the shared module 503 is further configured to:

[0165] A storage pool addition request is generated based on the directory path corresponding to the local directory of the backup server and the server identifier corresponding to the platform server in the virtualization platform.

[0166] Send the storage pool add request to the interaction interface of the virtualization platform to trigger the virtualization platform to control the platform server to mount the local directory of the backup server according to the directory path based on the server identifier carried in the storage pool add request.

[0167] In one embodiment, the shared module 503 is further configured to:

[0168] Obtain the export record identifier corresponding to the snapshot data;

[0169] Obtain the directory path corresponding to the local directory of the backup server, the shared record identifier of the local directory of the backup server, and the shared object identifier corresponding to the local directory of the backup server.

[0170] Based on the exported record identifier, the directory path corresponding to the local directory of the backup server, the shared record identifier, and the shared object identifier, the recovery task information of the faulty virtual machine is generated and saved.

[0171] In one embodiment, the apparatus further includes a cleaning module, the cleaning module being used for:

[0172] The state machine enters the recovery end phase.

[0173] During the recovery completion phase, in response to the recovery completion signal for the faulty virtual machine, it is determined that the rollback trigger event has occurred, and the rollback operation is performed sequentially in the reverse order of the steps executed in the system mounting phase, the system sharing phase, and the virtual machine startup phase.

[0174] Each module in the aforementioned virtual machine recovery device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of a computer device in hardware form or independent of it, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0175] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 6As shown, this computer device includes a processor, memory, input / output (I / O) interfaces, and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operating system and computer programs stored in the non-volatile storage media. The database stores virtual machine backup data. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When the computer program is executed by the processor, it implements a virtual machine recovery method.

[0176] Those skilled in the art will understand that Figure 6 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.

[0177] In one embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above-described method embodiments.

[0178] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps in the above method embodiments.

[0179] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0180] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0181] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0182] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0183] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A virtual machine recovery method, characterized in that, The method includes: In response to a recovery request for a faulty virtual machine, a state machine is created and the system mounting phase of the state machine is entered; During the system mounting phase, the logical file system created based on the snapshot data of the faulty virtual machine is mounted to the local directory of the backup server, thus entering the system sharing phase of the state machine. During the system sharing phase, the local directory of the backup server is shared with the platform server of the virtualization platform based on the general network file system protocol, so that the platform server mounts the local directory of the backup server and enters the state machine virtual machine startup phase; During the virtual machine startup phase, a normal virtual machine is created in the local directory of the backup server to trigger the platform server to run the normal virtual machine based on the snapshot data in the local directory of the backup server. When a rollback trigger event is detected, the state machine is used to perform the corresponding rollback operation according to the stage in which the state machine is currently.

2. The method according to claim 1, characterized in that, Prior to the logical file system to be created based on the snapshot data of the failed virtual machine, the following is also included: Obtain snapshot data of the faulty virtual machine; Based on the synthesis result of the snapshot data and the writable space, the logical file system of the faulty virtual machine is obtained; wherein, the writable space is used to record the write operations of the normal virtual machine on the snapshot data.

3. The method according to claim 2, characterized in that, The step of obtaining snapshot data of the faulty virtual machine includes: Obtain the snapshot identifier input by the user for the faulty virtual machine; wherein, different snapshot identifiers correspond to snapshot data of the faulty virtual machine at different points in time; Based on the snapshot identifier, retrieve the snapshot data corresponding to the snapshot identifier from the virtual machine backup storage pool.

4. The method according to claim 1, characterized in that, After sharing the backup server's local directory with the platform server of the virtualization platform based on the Common Network File System Protocol, the method further includes: A storage pool addition request is generated based on the directory path corresponding to the local directory of the backup server and the server identifier corresponding to the platform server in the virtualization platform. Send the storage pool add request to the interaction interface of the virtualization platform to trigger the virtualization platform to control the platform server to mount the local directory of the backup server according to the directory path based on the server identifier carried in the storage pool add request.

5. The method according to claim 1, characterized in that, After creating a normal virtual machine in the local directory, the following steps are also included: Obtain the export record identifier corresponding to the snapshot data; Obtain the directory path corresponding to the local directory of the backup server, the shared record identifier of the local directory of the backup server, and the shared object identifier corresponding to the local directory of the backup server. Based on the exported record identifier, the directory path corresponding to the local directory of the backup server, the shared record identifier, and the shared object identifier, the recovery task information of the faulty virtual machine is generated and saved.

6. The method according to any one of claims 1 to 5, characterized in that, After creating a normal virtual machine in the local directory of the backup server to trigger the platform server to run the normal virtual machine based on the snapshot data in the local directory of the backup server, the process further includes: The state machine enters the recovery end phase. During the recovery completion phase, in response to the recovery completion signal for the faulty virtual machine, it is determined that the rollback trigger event has occurred, and the rollback operation is performed sequentially in the reverse order of the steps executed in the system mounting phase, the system sharing phase, and the virtual machine startup phase.

7. A virtual machine recovery device, characterized in that, The device includes: A creation module is used to create a state machine and enter the system mounting phase of the state machine in response to a recovery request for a faulty virtual machine; The mounting module is used to mount the logical file system created based on the snapshot data of the faulty virtual machine to the local directory of the backup server during the system mounting phase, thus entering the system sharing phase of the state machine. The sharing module is used to share the local directory of the backup server with the platform server of the virtualization platform based on the general network file system protocol during the system sharing phase, so that the platform server mounts the local directory of the backup server and enters the state machine virtual machine startup phase. A startup module is used to create a normal virtual machine in the local directory of the backup server during the virtual machine startup phase, so as to trigger the platform server to run the normal virtual machine according to the snapshot data in the local directory of the backup server; When a rollback trigger event is detected, the state machine is used to perform the corresponding rollback operation according to the stage in which the state machine is currently.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

Images