Fault recovery method, first server, storage medium and product

Abstract

The embodiment of the invention provides a fault recovery method, a first server, a storage medium and a product, and the method comprises the steps: obtaining the fault feature information of the update fault of first firmware in response to the detection of the update fault of the first firmware in the first server; obtaining the fault instance file from the second server, and determining a fault recovery method matched with the fault feature information from the fault instance file; feature information and recovery methods corresponding to different faults are configured in the fault instance file; and based on the fault recovery method, performing fault recovery on the first firmware.

Description

Technical Field

[0001] The present application relates to a fault recovery method, a first server, a storage medium, and a product. Background Art

[0002] New motherboard developments are increasingly embodying modular designs. Currently, there is a module called the Root of Trust (ROT) module. The ROT module is a secure boot environment used to verify and boot the operating system. It is the basis of system security and can ensure that the operating system has not been tampered with or replaced by malware.

[0003] At present, a universal ROT module is usually used to adapt to different motherboards. However, as the remaining motherboard parts are upgraded, the ROT module needs to be adaptively updated, but sometimes failures may occur during the update process. Summary of the invention

[0004] Embodiments of the present application provide a fault recovery method, a first server, a storage medium, and a product.

[0005] The technical solution of this application is implemented as follows:

[0006] In a first aspect, an embodiment of the present application provides a fault recovery method, which is applied to a first server, and the method includes:

[0007] In response to detecting that an update failure occurs in the first firmware in the first server, acquiring failure characteristic information of the update failure occurs in the first firmware;

[0008] Obtaining a fault instance file from the second server, and determining a fault recovery method matching the fault characteristic information from the fault instance file; the fault instance file is configured with characteristic information and recovery methods corresponding to different faults;

[0009] Based on the fault recovery method, the first firmware is recovered.

[0010] In the above fault recovery method, in response to a fault in the first firmware in the first server, before obtaining fault characteristic information of the first firmware update fault, the method further includes:

[0011] In response to detecting that the second firmware in the first server is updated, obtaining an interface update code corresponding to the first firmware from the second server; the second firmware is a firmware different from the first firmware on the first server;

[0012] Based on the interface update code, the interface of the first firmware is updated to obtain an update result;

[0013] If the update result is an update failure, it is determined that an update failure occurs in the first firmware.

[0014] In the above fault recovery method, obtaining the fault instance file from the second server includes:

[0015] Sending a first request carrying identification information of the fault instance file to the second server;

[0016] Receiving the storage address and file information of the fault instance file responded by the second server based on the identification information carried in the first request;

[0017] Based on the file information, download the fault instance file from the storage address.

[0018] In the above fault recovery method, the fault recovery method is at least one of the following methods:

[0019] Power off the first server and then power it back on;

[0020] Re-download or update the target firmware on the first server;

[0021] Reconfigure the first firmware on the first server or the configuration information of the first server.

[0022] In the above fault recovery method, the fault recovery method is to re-download or update the target firmware on the first server, and based on the fault recovery method, the first firmware is recovered, including:

[0023] Obtaining, from the second server, a firmware update code corresponding to the target firmware;

[0024] Based on the firmware update code, a firmware update is performed on the target firmware to achieve failure recovery of the first firmware.

[0025] In the above fault recovery method, the method further includes:

[0026] Obtaining a recovery log of the first firmware during a fault recovery process;

[0027] The recovery log is sent to the second server so that the second server updates the fault instance file based on the recovery log.

[0028] In a second aspect, an embodiment of the present application provides a first server, the first server comprising:

[0029] an acquisition module, configured to acquire, in response to detecting that an update failure occurs in the first firmware in the first server, fault characteristic information of the update failure occurs in the first firmware;

[0030] A determination module is used to obtain a fault instance file from the second server, and determine a fault recovery method matching the fault characteristic information from the fault instance file; the fault instance file is configured with characteristic information and recovery methods corresponding to different faults;

[0031] The recovery module is used to perform fault recovery on the first firmware based on the fault recovery method.

[0032] In a third aspect, an embodiment of the present application provides a first server, the first server comprising: a processor, a memory and a communication bus; the communication bus is used to realize a communication connection between the processor and the memory; the processor is used to execute a computer program stored in the memory to implement any one of the fault recovery methods in the above embodiments.

[0033] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, which stores one or more computer programs. The one or more computer programs can be executed by one or more processors to implement the fault recovery method of any one of the above embodiments.

[0034] In a fifth aspect, an embodiment of the present application provides a computer program product, including a computer program or instructions, which are executed by a processor to implement the fault recovery method of any one of the above embodiments.

[0035] An embodiment of the present application provides a fault recovery method and a first server, a storage medium, and a product. The method includes: in response to detecting an update failure in a first firmware in the first server, obtaining fault feature information of the update failure in the first firmware; obtaining a fault instance file from a second server, and determining a fault recovery method matching the fault feature information from the fault instance file; the fault instance file is configured with feature information and recovery methods corresponding to different faults; and based on the fault recovery method, performing fault recovery on the first firmware. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] Figure 1 A flowchart of a fault recovery method provided in an embodiment of the present application;

[0037] Figure 2 An exemplary fault recovery method flow chart provided in an embodiment of the present application;

[0038] Figure 3 An exemplary server communication schematic diagram provided for an embodiment of the present application;

[0039] Figure 4 A schematic diagram of the composition structure of a first server provided in an embodiment of the present application Figure 1 ;

[0040] Figure 5 A schematic diagram of the composition structure of a first server provided in an embodiment of the present application Figure 2 . DETAILED DESCRIPTION

[0041] It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0042] The present application embodiment provides a fault recovery method, which is applied to a first server. Figure 1 A flowchart of a fault recovery method provided in an embodiment of the present application is shown in FIG. Figure 1 As shown, the fault recovery method may include the following steps S101 to S103:

[0043] S101: In response to detecting that an update failure occurs in a first firmware in a first server, acquiring failure feature information of the update failure occurs in the first firmware.

[0044] In the embodiment of the present application, in response to detecting that an update failure occurs in the first firmware in the first server, the first server obtains fault characteristic information of the update failure of the first firmware.

[0045] In the embodiment of the present application, the first server may be a management controller (X Clarity Controller, XCC), a baseboard management controller (Baseboard Management Controller, BMC), etc.; the specific first server may be determined according to actual conditions, and the embodiment of the present application does not make specific limitations here.

[0046] In the embodiment of the present application, the first firmware is a technology and component related to server hardware management and startup on the first server. Exemplarily, the first firmware can be a field programmable gate array (Field Programmable Gate Array, FPGA) or a firmware interface (Unified Extensible Firmware Interface, UEFI); the specific first firmware can be determined based on actual conditions, and the embodiment of the present application does not make any specific limitations here.

[0047] In an embodiment of the present application, the fault characteristic information may be specific descriptive information characterizing the update failure that occurred, or it may be the cause of the failure. For example, if the first firmware is UEFI, the fault characteristic information may be that the UEFI cannot be updated, or that the updated UEFI cannot be started. The specific fault characteristic information may be determined based on actual conditions, and the embodiment of the present application does not make any specific limitations here.

[0048] S102: Obtain a fault instance file from the second server, and determine a fault recovery method matching the fault feature information from the fault instance file; the fault instance file is configured with feature information and recovery methods corresponding to different faults.

[0049] In an embodiment of the present application, after obtaining the fault characteristic information of the update failure of the first firmware, the first server obtains the fault instance file from the second server, and determines the fault recovery method matching the fault characteristic information from the fault instance file; the fault instance file is configured with characteristic information and recovery methods corresponding to different faults.

[0050] In an embodiment of the present application, the fault instance file is stored on a second server, and the second server is a server specifically used to store logs, for example, a Trivial File Transfer Protocol (TFTP) server; since the fault instance file is stored on the second server, a fault occurring on the first server will not affect the fault instance file; the specific second server can be determined based on actual conditions, and the embodiment of the present application does not make any specific limitations here.

[0051] In an embodiment of the present application, the fault instance file is a JSON file. The JSON file can be configured according to the characteristic information of different faults that may occur in the first firmware on the first server and the corresponding recovery methods, and the JSON file can be stored on the second server. Based on this, when a fault occurs in the first firmware, the first server can search for the corresponding recovery method from the JSON file on the second server.

[0052] S103: Perform fault recovery on the first firmware based on the fault recovery method.

[0053] In the embodiment of the present application, after the first server determines the fault recovery method matching the fault characteristic information from the fault instance file, it performs fault recovery on the first firmware based on the fault recovery method.

[0054] In an embodiment of the present application, the fault recovery method may be to power off the first server and then power it back on, or to re-download or update the target firmware on the first server, or to reconfigure the first firmware on the first server or the configuration information of the first server; the specific fault recovery method may be determined based on actual conditions, and the embodiment of the present application does not make any specific limitation here.

[0055] Based on the above embodiment, in response to a failure of the first firmware in the first server, before the first server obtains the fault characteristic information of the update failure of the first firmware, the following steps are further included:

[0056] S201. In response to detecting that a second firmware in a first server is updated, obtaining an interface update code corresponding to the first firmware from the second server; the second firmware is a firmware on the first server that is different from the first firmware.

[0057] In an embodiment of the present application, in response to detecting that the second firmware in the first server is updated, the first server obtains the interface update code corresponding to the first firmware from the second server; the second firmware is a firmware on the first server that is different from the first firmware.

[0058] In the embodiment of the present application, the second firmware is the firmware on the first server. If the second firmware is updated and upgraded, then, correspondingly, the first firmware also needs to be updated and upgraded when it needs to communicate with the second firmware.

[0059] In an embodiment of the present application, the second server not only stores the fault recovery method, but also stores the update code when different firmware needs to be updated and upgraded. Therefore, after the second firmware is updated and upgraded, the first server needs to perform a corresponding upgrade on the first firmware. At this time, the first server needs to obtain the pre-stored interface update code required for the first firmware update from the second server, and update and upgrade the first firmware based on the interface update code.

[0060] S202: Based on the interface update code, update the interface of the first firmware to obtain an update result.

[0061] In the embodiment of the present application, after obtaining the interface update code corresponding to the first firmware from the second server, the first server performs an interface update on the first firmware based on the interface update code to obtain an update result.

[0062] In an embodiment of the present application, after obtaining the interface update code for updating the first firmware from the second server, the first server performs an interface update on the first firmware based on the interface update code to obtain an update result of this interface update.

[0063] In the embodiment of the present application, the update result may include a successful update or a failed update; the specific update result can be determined based on actual conditions, and the embodiment of the present application does not make any specific limitations here.

[0064] S203: If the update result is an update failure, determine that an update failure occurs in the first firmware.

[0065] In the embodiment of the present application, after the first server performs an interface update on the first firmware and obtains an update result, if the update result is an update failure, it is determined that an update failure occurs in the first firmware.

[0066] In the embodiment of the present application, if the update result of this interface update is an update failure, then it can be determined that an update failure occurs in the first firmware, and thus, the first firmware can be recovered according to the determined fault recovery method.

[0067] Exemplarily, referring to Table 1, taking different versions of Field-Programmable GateArra (FPGA) as an example, exemplary update failures are given:

[0068] Table 1 Update fault diagram

[0069]

[0070] Based on the above embodiment, the first server obtains the fault instance file from the second server, including the following steps:

[0071] S301: Send a first request carrying identification information of a fault instance file to a second server.

[0072] In an embodiment of the present application, the first server sends a first request carrying identification information of the fault instance file to the second server.

[0073] In an embodiment of the present application, the first request may be a Dynamic Host Configuration Protocol (DHCP) request. The first server first sends a DHCP request to the second server. At the same time, the DHCP request carries identification information of the fault instance file to be obtained. The specific first request may be determined based on actual conditions, and the embodiment of the present application does not make any specific limitation here.

[0074] S302: Receive the storage address and file information of the fault instance file responded by the second server based on the identification information carried in the first request.

[0075] In an embodiment of the present application, after sending a first request to a second server, the first server receives a storage address and file information of a fault instance file in response from the second server based on identification information carried in the first request.

[0076] In an embodiment of the present application, after receiving the first request sent by the first server, the second server determines the storage address of the fault instance file and the file information of the fault instance file based on the identification information of the fault instance file carried in the first request, and then sends the determined storage address and file information to the first server.

[0077] S303: Download the fault instance file from the storage address based on the file information.

[0078] In an embodiment of the present application, after receiving the storage address and file information of the fault instance file responded by the second server, the first server downloads the fault instance file from the storage address based on the file information.

[0079] In an embodiment of the present application, after receiving the determined storage address and file information sent by the second server, the first server downloads the required fault instance file from the storage address based on the file information. Thus, the first server can perform fault recovery on the first firmware that has an update failure based on the fault recovery method in the fault instance file.

[0080] Based on the above embodiment, the fault recovery method is to re-download or update the target firmware on the first server. The first server performs fault recovery on the first firmware based on the fault recovery method, including the following steps:

[0081] S401: Obtain a firmware update code corresponding to a target firmware from a second server.

[0082] In an embodiment of the present application, if the first server determines from the fault instance file that the fault recovery method to be used this time is to re-download or update the target firmware on the first server, the first server needs to obtain the firmware update code corresponding to the target firmware from the second server.

[0083] In the embodiment of the present application, the target firmware can be the first firmware, or it can be a firmware on the first server that is different from the first firmware but will affect the use of the first firmware; the specific target firmware can be determined based on actual conditions, and the embodiment of the present application does not make any specific limitations here.

[0084] S402: Perform firmware update on the target firmware based on the firmware update code to achieve fault recovery of the first firmware.

[0085] In the embodiment of the present application, after the first server obtains the firmware update code corresponding to the target firmware from the second server, the first server performs a firmware update on the target firmware based on the firmware update code to achieve fault recovery of the first firmware.

[0086] In an embodiment of the present application, exemplarily, an update failure of the first firmware may be caused by the target firmware version on the first server being too low to adapt to the updated first firmware, thereby causing an update failure of the first firmware. At this time, the target firmware can be updated based on the firmware update code first, and then the interface update process of the first firmware can be re-executed to achieve fault recovery of the first firmware.

[0087] Based on the above embodiment, the first server also needs to perform the following steps:

[0088] S501: Obtain a recovery log of a first firmware during a failure recovery process.

[0089] In an embodiment of the present application, the recovery log may include the time point when the update failure of the first firmware is determined, and the time point after the first firmware update is recovered. It may also include the specific update failure of the first firmware and the fault recovery method adopted; the specific recovery log can be determined based on actual conditions, and the embodiment of the present application does not make specific limitations here.

[0090] S502: Send the recovery log to the second server, so that the second server updates the fault instance file based on the recovery log.

[0091] In an embodiment of the present application, during the continuous fault recovery process, the fault instance file can be continuously updated using each recovery log, so that when some firmware on the first server subsequently generates an update failure again, the first server can accurately determine the corresponding fault recovery method based on the fault instance file, thereby achieving fault recovery of the firmware.

[0092] An embodiment of the present application provides a fault recovery method, the method comprising: in response to detecting an update failure in a first firmware in a first server, obtaining fault feature information of the update failure in the first firmware; obtaining a fault instance file from a second server, and determining a fault recovery method matching the fault feature information from the fault instance file; the fault instance file is configured with feature information and recovery methods corresponding to different faults; based on the fault recovery method, performing fault recovery on the first firmware; using the above implementation scheme, when a firmware update failure occurs, the server directly searches for the corresponding fault recovery method from other servers, so that the fault can be recovered as soon as possible, thereby improving the efficiency of fault handling and response.

[0093] The above introduces the fault recovery method provided in the embodiment of the present application. To facilitate understanding of the embodiment of the present application, the following introduces possible implementation schemes of the fault recovery method applicable to the embodiment of the present application in actual application scenarios.

[0094] refer to Figure 2 , taking the first server as an XCC server, the first firmware as UEFI on the ROT module, and the second server as a TFTP server as an example, the embodiment of the present application is described:

[0095] S601: After other firmware on a first server are updated, update the first firmware.

[0096] Specifically, after other firmware on the XCC server is updated, the UEFI on the ROT module is updated.

[0097] S602: Determine that an update failure occurs during the update of the first firmware.

[0098] Specifically, it is determined that an update failure occurs during the process of updating the UEFI on the ROT module.

[0099] S603: The first server obtains fault feature information of an update failure of the first firmware, and obtains a fault instance file from the second server.

[0100] Specifically, the XCC server obtains a fault image (fault characteristic information in the above embodiment) of an update fault in the UEFI on the ROT module, and obtains a JSON file (fault instance file in the above embodiment) from the TFTP server.

[0101] S604: The first server determines a fault recovery method corresponding to the fault feature information from the fault instance file.

[0102] Specifically, the XCC server searches the JSON file for a recovery descriptor (fault recovery method) that matches the fault image.

[0103] S605: The first server performs automatic recovery based on the fault recovery method.

[0104] Specifically, the XCC server determines the corresponding fault recovery step according to the recovery descriptor matched with the fault image, thereby performing automatic recovery based on the fault recovery step.

[0105] S606: The first server reports the recovery log.

[0106] Specifically, after executing automatic recovery, the XCC server can store the time point when the UEFI update failure occurs on the ROT module and the time point after the UEFI update on the ROT module is recovered, and can also store the fault image when the UEFI update failure occurs and the recovery image after the UEFI fault is recovered in a JSON file in the TFTP server.

[0107] It should be noted that the reference Figure 3 , a communication connection is established between the first server and the second server through a local area network (LAN), and the JSON file required by the first server when a failure occurs is stored on the second server. Therefore, the failure of the first server will not affect the JSON file, and it is easier to maintain and update the JSON file.

[0108] Based on the above embodiment, in another embodiment of the present application, a first server is provided. Figure 4 A schematic diagram of the composition structure of a first server provided in this application Figure 1 ,like Figure 4 As shown, the first server 1 includes:

[0109] An acquisition module 10 is configured to acquire, in response to detecting that an update failure occurs in the first firmware in the first server, fault characteristic information of the update failure of the first firmware;

[0110] The determination module 11 is used to obtain a fault instance file from the second server, and determine a fault recovery method matching the fault characteristic information from the fault instance file; the fault instance file is configured with characteristic information and recovery methods corresponding to different faults;

[0111] The recovery module 12 is used to perform fault recovery on the first firmware based on the fault recovery method.

[0112] Optionally, the first server 1 further includes: an update module;

[0113] The acquisition module 10 is further configured to, in response to detecting that the second firmware in the first server is updated, acquire the interface update code corresponding to the first firmware from the second server; the second firmware is a firmware on the first server that is different from the first firmware;

[0114] The update module is used to perform an interface update on the first firmware based on the interface update code to obtain an update result;

[0115] The determining module 11 is further configured to determine that an update failure occurs in the first firmware if the update result is an update failure.

[0116] Optionally, the first server 1 further includes: a sending module, a receiving module and a downloading module;

[0117] The sending module is used to send a first request carrying identification information of the fault instance file to the second server;

[0118] The receiving module is used to receive the storage address and file information of the fault instance file responded by the second server based on the identification information carried in the first request;

[0119] The download module is used to download the fault instance file from the storage address based on the file information.

[0120] Optionally, the first server 1 further includes: a control module and a configuration module;

[0121] The control module is used to power off and then power on the first server;

[0122] The update module is further used to re-download or update the target firmware on the first server;

[0123] The configuration module is used to reconfigure the first firmware on the first server or the configuration information of the first server.

[0124] Optionally, the acquisition module 10 is further used to acquire a firmware update code corresponding to the target firmware from the second server;

[0125] The update module is further used to perform firmware update on the target firmware based on the firmware update code to achieve fault recovery of the first firmware.

[0126] Optionally, the acquisition module 10 is further used to acquire a recovery log of the first firmware during a fault recovery process;

[0127] The sending module is further used to send the recovery log to the second server, so that the second server updates the fault instance file based on the recovery log.

[0128] An embodiment of the present application provides a first server, which includes: an acquisition module, used to obtain fault characteristic information of the first firmware update failure in response to detecting an update failure in the first firmware in the first server; a determination module, used to obtain a fault instance file from a second server, and determine a fault recovery method matching the fault characteristic information from the fault instance file; the fault instance file is configured with characteristic information and recovery methods corresponding to different faults; a recovery module, used to perform fault recovery on the first firmware based on the fault recovery method; using the above implementation scheme, when a firmware update failure occurs, the server directly searches for the corresponding fault recovery method from other servers, so that the fault can be recovered as soon as possible, thereby improving the efficiency of fault processing and response.

[0129] Figure 5 A schematic diagram of the composition structure of a first server provided in an embodiment of the present application Figure 2 In practical applications, based on the same disclosure concept of the above embodiments, Figure 5 As shown, the first server 1 of this embodiment further includes: a processor 20 , a memory 21 and a communication bus 22 .

[0130] In the process of a specific embodiment, the acquisition module 10, the determination module 11, the recovery module 12, the update module, the sending module, the receiving module, the download module, the control module and the configuration module can be implemented by a processor 20 located on the first server, and the processor 20 can be at least one of an application-specific integrated circuit (ASIC), a digital signal processor (DSP), a digital signal processing device (DSPD), a programmable logic device (PLD), a field programmable gate array (FPGA), a CPU, a controller, a microcontroller, and a microprocessor. It can be understood that for different first servers, the electronic device used to implement the above-mentioned processor function can also be other, and this embodiment does not specifically limit it.

[0131] In the embodiment of the present application, the communication bus 22 is used to realize the connection and communication between the processor 20 and the memory 21; when the processor 20 executes the running program stored in the memory 21, the following fault recovery method is implemented:

[0132] In response to detecting that an update failure occurs in the first firmware in the first server, acquiring failure characteristic information of the update failure occurs in the first firmware;

[0133] Obtaining a fault instance file from the second server, and determining a fault recovery method matching the fault characteristic information from the fault instance file; the fault instance file is configured with characteristic information and recovery methods corresponding to different faults;

[0134] Based on the fault recovery method, the first firmware is recovered from the fault.

[0135] Optionally, the processor 20 is also used to obtain an interface update code corresponding to the first firmware from the second server in response to detecting that the second firmware in the first server is updated or upgraded; the second firmware is a firmware on the first server that is different from the first firmware; based on the interface update code, the interface of the first firmware is updated to obtain an update result; if the update result is an update failure, it is determined that an update failure has occurred in the first firmware.

[0136] Optionally, the processor 20 is also used to send a first request carrying identification information of the fault instance file to a second server; receive the storage address and file information of the fault instance file in response from the second server based on the identification information carried in the first request; and download the fault instance file from the storage address based on the file information.

[0137] Optionally, the processor 20 is further used to power off and then power on the first server; re-download or update the target firmware on the first server; and reconfigure the first firmware on the first server or the configuration information of the first server.

[0138] Optionally, the processor 20 is further used to obtain a firmware update code corresponding to the target firmware from the second server; and based on the firmware update code, perform a firmware update on the target firmware to achieve fault recovery of the first firmware.

[0139] Optionally, the processor 20 is further configured to obtain a recovery log of the first firmware during a fault recovery process; and send the recovery log to the second server so that the second server updates the fault instance file based on the recovery log.

[0140] An embodiment of the present application provides a storage medium having a computer program stored thereon. The computer-readable storage medium stores one or more programs. The one or more programs can be executed by one or more processors and are applied to a first server. The computer program implements the fault recovery method as described above.

[0141] It should be noted that, in this article, the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, an element defined by the sentence "comprises a ..." does not exclude the existence of other identical elements in the process, method, article or device including the element.

[0142] Through the description of the above implementation methods, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be implemented by means of software plus a necessary general hardware platform, and of course can also be implemented by hardware, but in many cases the former is a better implementation method. Based on such an understanding, the technical solution of the present disclosure, or the part that contributes to the relevant technology, can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, a disk, or an optical disk), and includes a number of instructions for enabling a first server (which can be a mobile phone, a computer, a server, an air conditioner, or a network device, etc.) to execute the fault recovery method of each embodiment of the present disclosure.

[0143] The above description is only a preferred embodiment of the present application and is not intended to limit the protection scope of the present application.

Claims

1. A fault recovery method, applied to a first server, comprising: In response to detecting that an update failure occurs in the first firmware in the first server, acquiring failure characteristic information of the update failure occurs in the first firmware; Acquire a fault instance file from the second server, and determine a fault recovery method matching the fault feature information from the fault instance file; The fault instance file is configured with characteristic information and recovery methods corresponding to different faults; Based on the fault recovery method, the first firmware is recovered from the fault.

2. The method according to claim 1, before obtaining the fault characteristic information of the update failure of the first firmware in response to the first firmware in the first server failing, the method further comprises: In response to detecting that the second firmware in the first server is updated, obtaining an interface update code corresponding to the first firmware from the second server; The second firmware is firmware different from the first firmware on the first server; Based on the interface update code, the first firmware is updated with an interface to obtain an update result; If the update result is an update failure, it is determined that an update failure occurs in the first firmware.

3. According to the method of claim 1, the step of obtaining the fault instance file from the second server comprises: Sending a first request carrying identification information of the fault instance file to the second server; receiving the storage address and file information of the fault instance file responded by the second server based on the identification information carried in the first request; Based on the file information, the fault instance file is downloaded from the storage address.

4. According to the method of claim 1, the fault recovery method is at least one of the following methods: Powering off the first server and then powering it back on; Re-download or update the target firmware on the first server; Reconfigure the first firmware on the first server or the configuration information of the first server.

5. The method according to claim 4, wherein the fault recovery method is to re-download or update the target firmware on the first server, and the first firmware is recovered based on the fault recovery method, comprising: Obtaining, from the second server, a firmware update code corresponding to the target firmware; Based on the firmware update code, a firmware update is performed on the target firmware to achieve failure recovery of the first firmware.

6. The method according to any one of claims 1 to 5, further comprising: Obtaining a recovery log of the first firmware during a fault recovery process; The recovery log is sent to the second server, so that the second server updates the failure instance file based on the recovery log.

7. A first server, comprising: an acquisition module, configured to acquire, in response to detecting that an update failure occurs in the first firmware in the first server, fault characteristic information of the update failure occurs in the first firmware; A determination module, configured to obtain a fault instance file from the second server, and determine a fault recovery method matching the fault characteristic information from the fault instance file; The fault instance file is configured with characteristic information and recovery methods corresponding to different faults; A recovery module is used to perform fault recovery on the first firmware based on the fault recovery method.

8. A first server, comprising: processor, memory, and communication bus; The communication bus is used to realize the communication connection between the processor and the memory; The processor is used to execute the computer program stored in the memory to implement the fault recovery method according to any one of claims 1 to 6.

9. A computer-readable storage medium storing one or more computer programs, wherein the one or more computer programs can be executed by one or more processors to implement the fault recovery method according to any one of claims 1 to 6.

10. A computer program product, comprising a computer program or instructions, wherein the computer program or instructions are executed by a processor to implement the fault recovery method according to any one of claims 1 to 6.

Images