Recovery method and electronic equipment

Abstract

The invention provides a recovery method and electronic equipment. The recovery method comprises the following steps: acquiring UEFI configuration data; based on the UEFI configuration data, determining a recovery point used for recording the UEFI configuration data in a recovery point list; the recovery point list comprises a plurality of recovery points, and each recovery point in the plurality of recovery points comprises a timestamp of each recovery point and UEFI configuration data corresponding to each recovery point; and under the condition that the operation information of the electronic equipment meets a preset condition, restoring the current UEFI configuration data to target UEFI configuration data based on the plurality of recovery points in the recovery point list, the target UEFI configuration data being UEFI configuration data matched with the preset condition.

Description

Technical Field

[0001] This application relates to the field of electronic technology, and more particularly to a recovery method and an electronic device. Background Technology

[0002] In server operation and maintenance management, due to hardware compatibility issues, system crashes, fault diagnosis, changes in server usage, or adjustments to the operating environment, it is often necessary to perform reset or recovery operations on the Unified Extensible Firmware Interface (UEFI) configuration.

[0003] In related technologies, resetting or restoring UEFI configurations relies on manual operation by the administrator. This method is not only inefficient, but also difficult to quickly restore the UEFI configuration to a relatively stable state in the absence of effective backups or configuration records. Therefore, a new UEFI configuration management mechanism is needed to solve the above problems. Summary of the Invention

[0004] In view of this, embodiments of this application provide a recovery method and an electronic device.

[0005] The technical solution of this application embodiment is implemented as follows: In a first aspect, embodiments of this application provide a recovery method, the recovery method comprising: Obtain UEFI configuration data; Based on the UEFI configuration data, a recovery point for recording the UEFI configuration data is determined in the recovery point list. The recovery point list includes multiple recovery points, and each recovery point includes a timestamp of each recovery point and the UEFI configuration data corresponding to each recovery point. When the operating information of the electronic device meets the preset conditions, the current UEFI configuration data is restored to the target UEFI configuration data based on multiple recovery points in the recovery point list. The target UEFI configuration data is the UEFI configuration data that matches the preset conditions.

[0006] Secondly, embodiments of this application provide an electronic device, which includes: an acquisition module, a determination module, and a restoration module.

[0007] The acquisition module is used to acquire UEFI configuration data; The determination module is used to determine the recovery point for recording UEFI configuration data from the recovery point list based on UEFI configuration data. The recovery point list includes multiple recovery points, and each recovery point includes a timestamp of each recovery point and the UEFI configuration data corresponding to each recovery point. The restore module is used to restore the current UEFI configuration data to the target UEFI configuration data based on multiple restore points in the restore point list when the operating information of the electronic device meets the preset conditions. The target UEFI configuration data is the UEFI configuration data that matches the preset conditions.

[0008] This application provides an electronic device, which includes: Memory is used to store executable instructions or computer programs. A processor, when executing computer-executable instructions or computer programs stored in memory, implements the methods provided in the embodiments of this application.

[0009] This application provides a computer-readable storage medium storing a computer program or computer-executable instructions for implementing the recovery method provided in this application when executed by a processor.

[0010] This application provides a computer program product, including a computer program or computer executable instructions. When the computer program or computer executable instructions are executed by a processor, they implement the recovery method provided in this application.

[0011] It should be understood that the above general description and the following detailed description are merely exemplary and explanatory, and are not intended to limit the technical solutions of this application. Attached Figure Description

[0012] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with this application and, together with the specification, serve to explain the technical solutions of this application.

[0013] Figure 1 A schematic diagram of the implementation process of a recovery method provided in this application embodiment. Figure 1 ; Figure 2 A schematic diagram of the implementation process of a recovery method provided in this application embodiment. Figure 2 ; Figure 3 A schematic diagram of the implementation process of a recovery method provided in this application embodiment. Figure 3 ; Figure 4A A flowchart illustrating the recovery point generation stage provided in this application embodiment. Figure 1 ; Figure 4B A flowchart illustrating the recovery phase of a recovery point is provided in this application embodiment. Figure 1 ; Figure 5 A schematic diagram of the recovery phase of a recovery point is provided for an embodiment of this application; Figure 6 A schematic diagram of the implementation process of a recovery method provided in this application embodiment. Figure 5 ; Figure 7 A schematic diagram of the implementation process of a recovery method provided in this application embodiment. Figure 6 ; Figure 8A A flowchart illustrating the recovery point generation stage provided in this application embodiment. Figure 2 ; Figure 8B A flowchart illustrating the recovery phase of a recovery point is provided in this application embodiment. Figure 2 ; Figure 9 A schematic diagram of the implementation process of a recovery method provided in this application embodiment. Figure 7 ; Figure 10 Eight is a schematic diagram illustrating the implementation process of a recovery method provided in this application embodiment; Figure 11 A flowchart illustrating the recovery point generation stage provided in this application embodiment. Figure 3 ; Figure 12 A flowchart illustrating the recovery phase of a recovery point is provided in this application embodiment. Figure 3 ; Figure 13 A schematic diagram of the composition structure of an electronic device provided in an embodiment of this application; Figure 14 This is a schematic diagram of a hardware entity of an electronic device in an embodiment of this application. Detailed Implementation

[0014] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application are further described in detail below with reference to the accompanying drawings and embodiments. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0015] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0016] The terms “first / second / third” are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that “first / second / third” may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0017] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains. The terminology used herein is for descriptive purposes only and is not intended to limit the scope of this application.

[0018] To address the problems in the related technologies, this application provides a recovery method that can be applied to electronic devices. Exemplarily, the electronic devices include, but are not limited to, smartphones, tablets, wearable devices, personal computers (PCs), netbooks, etc. The implementation of this application is not fixed or limited.

[0019] Figure 1 This is a schematic diagram illustrating the implementation process of a recovery method provided in an embodiment of this application, as shown below. Figure 1 As shown, this recovery method can be implemented through steps S101-S103: S101. Obtain UEFI configuration data.

[0020] Here, UEFI configuration data can also be referred to as UEFI setting data or Basic Input / Output System (BIOS) setting data.

[0021] For example, UEFI configuration data may include configuration data of core hardware, such as processor / CPU settings, memory / RAM settings, boot configuration data (e.g., boot order, boot mode, etc.), peripheral device and interface settings (e.g., onboard devices, PCIe / PCI settings, etc.), power management configuration data, security configuration and monitoring data, status information configuration data, network settings, power consumption settings, stability and recovery settings, etc.

[0022] Typically, when UEFI configuration data changes, the UEFI configuration data can be directly obtained and saved.

[0023] In some examples, the process of obtaining UEFI configuration data may also include obtaining UEFI configuration data when a UEFI change is determined.

[0024] UEFI changes can include out-of-band (OOB) changes and in-band changes. Out-of-band changes refer to remote changes achieved through the collaboration between the BMC and the UEFI firmware, without requiring user presence. In-band changes are configuration operations manually performed by the user through the UEFI configuration interface of the electronic device. Out-of-band changes can significantly improve the flexibility and efficiency of electronic device operation and maintenance, and are suitable for remote management scenarios of large-scale server clusters in data centers.

[0025] For example, OOB changes can be used to modify various UEFI core configuration items. For instance, in terms of CPU function configuration, certain CPU features can be enabled or disabled; in terms of memory function configuration, the memory operating frequency can be adjusted, or memory fault tolerance can be enabled; and in terms of security function configuration, Secure Boot can be remotely enabled or disabled.

[0026] S102. Based on the UEFI configuration data, determine the recovery point used to record the UEFI configuration data in the recovery point list.

[0027] The recovery point list includes multiple recovery points, and each recovery point includes its timestamp and corresponding UEFI configuration data.

[0028] After obtaining the UEFI configuration data, recovery points corresponding to the UEFI configuration data can be generated in the recovery point list based on the UEFI configuration data.

[0029] In some examples, the process of determining a recovery point for recording UEFI configuration data in the recovery point list based on UEFI configuration data may include: determining whether the UEFI configuration data is consistent with the previous UEFI configuration data; if the UEFI configuration data is consistent with the previous UEFI configuration data, no new recovery point is generated; if the UEFI configuration data is inconsistent with the previous UEFI configuration data, a recovery point corresponding to the UEFI configuration data is generated, and this recovery point is updated in the recovery point list. This recovery point includes a timestamp of the recovery point and the UEFI configuration data corresponding to the recovery point. It can be understood that the timestamp of the recovery point can be the timestamp corresponding to when the UEFI configuration data changed.

[0030] In some examples, if the UEFI configuration data is inconsistent with the previous UEFI configuration data, generating a recovery point corresponding to the UEFI configuration data in the recovery point list may include: generating a recovery point in the recovery point list, which may include the recovery point's timestamp and the UEFI configuration data. Alternatively, generating a recovery point in the recovery point list, which may include the recovery point's timestamp and difference data. This difference data refers to the difference between the UEFI configuration data and the previous UEFI configuration data. This application does not limit the specific content included in the recovery point.

[0031] S103. When the operating information of the electronic device meets the preset conditions, the current UEFI configuration data is restored to the target UEFI configuration data based on multiple recovery points in the recovery point list.

[0032] The target UEFI configuration data is the UEFI configuration data that matches the preset conditions.

[0033] In some examples, the preset conditions include any of the following: in response to a user's triggering operation on a target recovery point in the recovery point list, the UEFI configuration data corresponding to the target recovery point is the target UEFI configuration data; the stability value of the electronic device is less than or equal to a first threshold; the startup success rate value of the electronic device is less than or equal to a second threshold; the electronic device has an abnormal startup or operation.

[0034] For example, the first threshold and the second threshold can be settings derived by R&D personnel based on experience. An abnormal startup of an electronic device can specifically mean that the electronic device fails to start or that the startup time exceeds the threshold. An abnormal operation can mean that the electronic device experiences a system crash or freezes during operation.

[0035] By setting specific preset conditions, a clear execution standard is provided for configuration data rollback. Furthermore, as mentioned above, this application supports user-initiated manual triggering of target recovery point restoration, meeting users' needs for proactive configuration management. For example, if a user accidentally modifies the configuration, they can quickly revert to the ideal state. On the other hand, quantitative indicators such as device stability values ​​and startup success rate values, as well as fault scenarios such as startup anomalies and operational anomalies, are also included in the preset conditions, enabling automated triggering of the restoration operation. This allows for timely response when configuration faults occur in electronic devices, repairing problems without user intervention. It covers both proactive operation and reactive fault scenarios, while also considering flexibility and intelligence, further ensuring the stability of electronic device operation and the user experience.

[0036] If the electronic device's operating information meets preset conditions, it indicates that the electronic device's operating status is poor or does not meet expectations when running according to the current UEFI configuration data. Based on this, the current UEFI configuration data is adjusted to ensure the electronic device's operating status meets the requirements. To enable the electronic device to quickly enter a good operating state, the current UEFI configuration data can be adjusted to a target UEFI configuration data where the electronic device's performance was previously more stable, thus not affecting the normal operation of the electronic device.

[0037] In some examples, the process of restoring the current UEFI configuration data to the target UEFI configuration data based on multiple recovery points in the recovery point list may include: determining the target UEFI configuration data corresponding to the target recovery point based on the multiple recovery points in the recovery point list; and restoring according to the target UEFI configuration data to restore the current UEFI configuration data to the target UEFI configuration data. Here, the UEFI configuration data corresponding to the target recovery point is the target UEFI configuration data.

[0038] For example, the target recovery point can be a recovery point selected by the user from the recovery point list, or it can be a recovery point set by the electronic device itself. This application does not limit this.

[0039] In this embodiment, UEFI configuration data is first acquired, and a matching recovery point is located in the recovery point list based on this UEFI configuration data. When the electronic device's operating information meets preset conditions, configuration restoration is automatically performed. Since the recovery point list records both timestamps and corresponding UEFI configuration data, it allows users or electronic devices to quickly locate configuration data at a specific time point, providing data support for accurate restoration. Simultaneously, using "electronic device operating information meeting preset conditions" as the prerequisite for restoration triggering ensures that the restoration operation is only initiated when necessary. This avoids interference with the operation of the electronic device due to invalid restorations and enables the electronic device to promptly restore stability in the event of configuration anomalies.

[0040] Comparative analysis reveals significant shortcomings in the UEFI configuration reset or recovery methods of related technologies. Specifically, restoring factory settings erases all personalized configurations, requiring administrators to reconfigure and failing to retain existing optimized settings. Relying on manual backup import from external storage devices is also limited by the administrator's prior backup; if the backup file is missing or outdated, effective restoration is impossible. In contrast, the embodiments of this application effectively overcome the aforementioned shortcomings of reliance on manual processes and lack of intelligent recovery capabilities, significantly improving the automation and reliability of UEFI configuration management.

[0041] Figure 2 This is a schematic diagram illustrating the implementation process of a recovery method provided in an embodiment of this application, as shown below. Figure 2As shown, step S102, based on the UEFI configuration data, determines the recovery point used to record the UEFI configuration data in the recovery point list, including: S201. Based on the UEFI configuration data and the previous UEFI configuration data corresponding to the previous recovery point, determine the first difference data.

[0042] In some examples, the process of determining the first difference data based on the UEFI configuration data and the previous UEFI configuration data corresponding to the previous recovery point may include: comparing the UEFI configuration data and the previous UEFI configuration data to obtain the first difference data.

[0043] The process of comparing the UEFI configuration data with the previous UEFI configuration data to obtain the first difference data may include: comparing all configuration items of the UEFI configuration data and the previous UEFI configuration data; if there is a difference between the UEFI configuration data and the previous UEFI configuration data, the first difference data can be obtained; if there is no difference between the UEFI configuration data and the previous UEFI configuration data, then there is no first difference data. After obtaining the first difference data, a new recovery point can be generated based on the first difference data.

[0044] For example, in the previous UEFI configuration data, the CPU's P-State flag was set to Enabled, and the Memory Mirror Mode flag was set to Disabled. In the current UEFI configuration data, the CPU's P-State flag is set to Disabled, and the Memory Mirror Mode flag is set to Full Mirror. The first difference obtained through comparison could be that the CPU's P-State flag changes from Enabled to Disabled, and the Memory Mirror Mode flag changes from Disabled to Full Mirror.

[0045] S202. Based on the first difference data, add a recovery point to the recovery point list to record UEFI configuration data.

[0046] Once the first difference data is obtained, a recovery point can be added to the recovery point list.

[0047] In some examples, the recovery point may include UEFI configuration data, or it may only include the first difference data. The electronic system's configuration data can then be restored to the UEFI configuration data based on the first difference data and the previous UEFI configuration data.

[0048] In this embodiment, by recording only the difference data instead of the complete configuration data, the storage resources occupied by the recovery point can be greatly reduced, thus reducing the storage pressure on the device. At the same time, a new recovery point is generated based on the previous recovery point, so that the configuration changes in the recovery point list form a continuous link. Each recovery point corresponds to only one difference, which not only ensures the accuracy of configuration traceability, but also provides a clear path for subsequent restoration operations. This avoids the waste of resources and traceability confusion caused by the repeated storage of the complete configuration, and balances storage efficiency and the orderliness of configuration management.

[0049] In one possible implementation, see Figure 3 The detailed process of this recovery method may include: S11. Initialize the change history database.

[0050] Once the electronic device is powered on, the Power-On Self-Test (POST) process will officially begin.

[0051] During this process, the UEFI firmware in the electronic device simultaneously initiates hardware initialization, detecting and configuring various core hardware components such as the processor, memory, hard drive, motherboard, and interface devices one by one to ensure the normal operation of each hardware component. After the POST process is completed and the hardware initialization verification is passed, the UEFI firmware further guides the boot process, reads and loads the operating system boot files, and finally completes the normal boot, allowing the electronic device to enter a runnable state.

[0052] After the electronic device is powered on, an initialization operation is performed on the change history database. This database includes at least one temporary change list, which is used to collect UEFI configuration changes that occur during a single boot process. The recovery point list may include multiple temporary change lists.

[0053] For example, when the POST process starts, the electronic device first initializes an empty change history node (i.e., change history node). This node is used to collect the change list in this POST process and create a corresponding temporary change list for the current startup session, providing data support for subsequent configuration tracing and recovery.

[0054] By initializing the change history database, we can ensure that each startup's change records are independent and ordered, avoiding confusion with previous records. Once the current POST is complete, this temporary change list is added to the change history database, and the historical change records stored in the change history database are not cleared.

[0055] S12, Detect OOB changes.

[0056] When an external OOB change request is initiated, the Baseboard Management Controller (BMC) of the electronic device receives the request. The BMC includes a preset flag to indicate whether an OOB change has occurred. It then sends a notification message to the UEFI firmware stating that an OOB change request exists. After the UEFI firmware boots, the Universal Configuration Management (UCM) module within the UEFI firmware periodically reads the preset flag in the BMC. If the preset flag indicates an OOB change, the UCM module reads the corresponding UEFI change content from a designated storage area in the BMC. If the preset flag indicates no OOB change exists, the UEFI configuration interface is accessed.

[0057] The UEFI change information includes the name of the changed UEFI configuration item, the target setting value, and the time the change was initiated.

[0058] In addition, OOB and in-band are two interface types for UEFI configuration changes, and both of these interfaces support UEFI change operations.

[0059] S121. Add the changed OOB settings to the change history database.

[0060] Upon detecting an Out-of-Band (OOB) change, the electronic device updates the detected UEFI change to a temporary change list, and then adds the temporary change list to the change history database. This ensures that the UEFI change corresponding to the OOB change is completely recorded, without missing any out-of-band configuration adjustments.

[0061] S122, A restart is required.

[0062] Because some UEFI changes corresponding to OOB changes cannot take effect immediately in the current boot process and must be fully loaded via a reboot, the electronic device determines whether a reboot is required after recording the OOB change. If the result is "yes," the electronic device will trigger a reboot, and the process will return to boot. If the result is "no," it means that the UEFI changes corresponding to the OOB change can take effect in the current boot process, and the process continues.

[0063] S13, Access the settings interface.

[0064] During the startup process, the electronic device also monitors the user's key presses to determine whether to trigger entry into the UEFI configuration interface (also known as the settings interface). If the user presses the corresponding key, it means that the user needs to manually modify the configuration, and the process proceeds to S14; if the key press is not detected, it means that the user does not need to make any manual adjustments, and the process ends directly.

[0065] S14, Set the main loop.

[0066] After the user enters the UEFI configuration interface, the process enters the main configuration loop. In the UEFI configuration interface, the user can browse all configurable UEFI options (such as boot order, hardware parameters, security settings, etc.) and adjust them as needed. This step S14 is a loop step; the user does not need to complete all modifications at once, but can repeatedly browse different configuration menus and modify multiple configuration items until all adjustments are completed.

[0067] S15, Setting change detected.

[0068] The setup module in the UEFI firmware of an electronic device continuously monitors the user's operations in the UEFI configuration interface. When the user modifies the value of any configuration item, the setup module will detect this setting change.

[0069] S16. Record the changed settings to the temporary change list.

[0070] User-modified configuration items are not immediately written to permanent storage; instead, they are temporarily stored in a temporary change list. This prevents accidental changes from taking effect and allows users to confirm all modifications before exiting the UEFI configuration interface, improving both security and flexibility.

[0071] S17, Storage Settings.

[0072] After recording the modified configuration items to the temporary change list, further confirmation is needed to save the settings. When the user exits storage, the electronic device enters the configuration saving process, formally writing all the modified configuration items recorded in the temporary change list to non-volatile memory (NVRAM). NVRAM retains data even after power failure, so the written configuration items become permanent system configurations. Even if the device is powered off and restarted, the modified configuration items will not be lost and will be loaded directly upon the next startup.

[0073] S18. Add the temporary change list to the change history database.

[0074] The change history database is used to store configuration change information for each startup.

[0075] After storage settings are completed, the electronic device will perform a change archiving operation. The modified configuration items recorded in the temporary change list during this startup session will be added as a complete data entry to the change history database, providing data support for subsequent configuration audits, change tracing, and troubleshooting.

[0076] S19. End the settings interface.

[0077] This step determines whether the current configuration session should be completely terminated. Once the user has completed all configuration modifications, storage, and record archiving, the electronic device will prompt the user to exit the UEFI configuration interface. If the user chooses not to exit, they can return to the previous step to check the configuration again; if they confirm to exit, all processes will officially end.

[0078] Based on the steps above, by establishing a change history database and a temporary change list, all configuration item modifications are ensured to be traceable. When a user modifies OOB settings, the system first records the change to the temporary list, and then performs different operations based on the user's selection: if the user confirms storage, the temporary change is appended to the history database for archiving. This allows for complete recording and controllable rollback of configuration changes, effectively ensuring the reliability and traceability of system configurations.

[0079] In some examples, S103 restores the current UEFI configuration data to the target UEFI configuration data, including: S1031. If the target UEFI configuration data is the previous UEFI configuration data corresponding to the previous recovery point of the current recovery point, read the target UEFI configuration data from the previous recovery point of the current recovery point and restore the current UEFI configuration data to the target UEFI configuration data.

[0080] The current recovery point includes the current UEFI configuration data corresponding to the current recovery point.

[0081] In some examples, when the operating information of the electronic device meets preset conditions, it is necessary to restore the current UEFI configuration data to the target UEFI configuration data. This target UEFI configuration data can be the UEFI configuration data corresponding to the previous recovery point, or it can be the UEFI configuration data corresponding to the N previous recovery points.

[0082] For example, when the target UEFI configuration data is the previous UEFI configuration data corresponding to the previous recovery point of the current recovery point, the process of restoring the current UEFI configuration data to the target UEFI configuration data may include: searching for the previous recovery point of the current recovery point in the recovery point list; reading the target UEFI configuration data from the previous recovery point of the current recovery point; and replacing the current UEFI configuration data with the target UEFI configuration data.

[0083] For example, the default value of Setting X in the UEFI configuration data is 1. The user changes the setting value of Setting X to 2 at restore point A, to 3 at restore point B, and to 4 at restore point C. When the electronic device's operating information meets preset conditions, and the user chooses to roll back the setting value of Setting X to restore point B, the electronic device searches the restore point list for the previous restore point (i.e., restore point B) of the current restore point (i.e., restore point C), reads the setting value of Setting X (3) from restore point B, and replaces the setting value of Setting X (4) in the current restore point with the setting value of Setting X (3) from restore point B, thus restoring the setting value of Setting X to 3.

[0084] In this embodiment of the application, when the target UEFI configuration data is the previous UEFI configuration data corresponding to the previous recovery point of the current recovery point, the complex version comparison process is avoided by directly reading the previous UEFI configuration data and performing an overwrite restoration, while improving the restoration efficiency.

[0085] In some examples, S103 restores the current UEFI configuration data to the target UEFI configuration data, including: S1032. If the target UEFI configuration data is not the previous UEFI configuration data corresponding to the previous recovery point of the current recovery point, repeat the steps of reading the previous UEFI configuration data corresponding to the previous recovery point from the previous recovery point of the current recovery point and restoring the current UEFI configuration data to the previous UEFI configuration data; until the previous UEFI configuration data corresponding to the previous recovery point is the target UEFI configuration data, then restore the previous UEFI configuration data to the target UEFI configuration data.

[0086] The current recovery point includes the current UEFI configuration data corresponding to the current recovery point.

[0087] When the operating information of the electronic device meets the preset conditions, the current UEFI configuration data will be restored to the target UEFI configuration data.

[0088] In some examples, if the target UEFI configuration data is the UEFI configuration data corresponding to the previous N recovery points, the process of restoring the current UEFI configuration data to the target UEFI configuration data may include: if the target UEFI configuration data is not the previous UEFI configuration data corresponding to the previous recovery point of the current recovery point, repeatedly executing the step of reading the previous UEFI configuration data corresponding to the previous recovery point from the previous recovery point of the current recovery point and restoring the current UEFI configuration data to the previous UEFI configuration data; until the previous UEFI configuration data corresponding to the previous recovery point is the target UEFI configuration data, then restoring the previous UEFI configuration data to the target UEFI configuration data.

[0089] For example, the default value of Setting X in the UEFI configuration data is 1. The user changes the setting value of Setting X to 2 at restore point A, to 3 at restore point B, and to 4 at restore point C. When the electronic device's operating information meets preset conditions, and the user chooses to roll back the setting value of Setting X to restore point A, the electronic device searches the restore point list for the previous restore point (i.e., restore point B) of the current restore point (i.e., restore point C), reads the setting value of Setting X (3) from restore point B, and replaces the setting value of Setting X (4) in the current restore point with the setting value of Setting X (3) from restore point B, thus restoring the setting value of Setting X to 3. Since restore point B is not the restore point corresponding to the target UEFI configuration data, the process continues to search the restore point list for the previous restore point (i.e., restore point A) of the current restore point (i.e., restore point B). The setting value 2 of Setting X is read from restore point A, and the setting value 2 of Setting X in restore point A is used to replace the setting value 3 of Setting B in the current restore point, thus restoring the setting value of Setting X to 2. Since restore point A is the restore point corresponding to the target UEFI configuration data, the restore process ends.

[0090] In this embodiment, by repeatedly reading the configuration of the previous recovery point and restoring it step by step, any historical recovery point can be accurately located, breaking through the limitation that it can only roll back to the previous recovery point. At the same time, each step in the backtracking process is based on the existing data in the recovery point list, without the need for additional calculations. This ensures the stability and accuracy of the restoration process, and avoids data conflicts or anomalies in the configuration restoration process through orderly steps, thus ensuring the reliability of UEFI configuration restoration in complex scenarios.

[0091] The recovery method provided in this application embodiment will be described in detail below with reference to specific application scenarios. The recovery method includes two stages: the first stage is the recovery point generation stage, and the second stage is the recovery stage.

[0092] like Figure 4A As shown, the first stage (recovery point generation stage) includes the following steps: S21. Has a UEFI configuration change been detected?

[0093] Once the electronic device is powered on and completes initialization, the recovery point generation process officially begins.

[0094] The electronic device enters the UEFI configuration change monitoring state to detect whether any UEFI configuration changes have occurred. If a UEFI configuration change is detected, the process proceeds to step S22; if no UEFI configuration change is detected, the monitoring state is maintained until a UEFI configuration change is detected.

[0095] S22. Generate the difference data between the UEFI configuration data and the previous UEFI configuration data.

[0096] After confirming the detection of a UEFI configuration change, the electronic device obtains the UEFI configuration data corresponding to the change. It then compares this UEFI configuration data item by item with the previous UEFI configuration data before the change, calculating and generating difference data between the two. This difference data only includes the actually modified configuration items and their values ​​before and after the change; it does not record unchanged UEFI configuration content.

[0097] S23. Add the first recovery point to the recovery point list.

[0098] The first recovery point includes the difference data between the UEFI configuration data and the previous UEFI configuration data.

[0099] The electronic device creates a first recovery point based on the difference between the UEFI configuration data generated in step S22 and the previous UEFI configuration data. Subsequently, the created first recovery point is added to the recovery point list in chronological order for easy tracing and restoration later.

[0100] like Figure 4B As shown, the second phase (recovery phase) includes the following steps: S31, Restore the latest differences in the current configuration.

[0101] When the operating information of an electronic device meets preset conditions, the electronic device enters the recovery phase.

[0102] After the electronic device enters the recovery phase, first determine the target recovery point that needs to be recovered, then read the recovery point list, and execute the recovery operation.

[0103] For example, the electronic device extracts the previous UEFI configuration data corresponding to the previous recovery point from the recovery point list and rolls back the UEFI configuration data to the previous UEFI configuration data.

[0104] S32. Delete the differences that have been restored.

[0105] After the UEFI configuration data is rolled back to the previous UEFI configuration data, in order to avoid repeated restoration and an overly redundant recovery point list, the electronic device will delete the successfully restored recovery points from the recovery point list, so that the recovery point list always retains only the unrestored difference records.

[0106] S33. Has the target recovery point been reached?

[0107] After completing one restoration, the electronic device will continue to determine whether the restored UEFI configuration data is the target UEFI configuration data corresponding to the target recovery point. If the target recovery point has been reached, the restoration process ends; if not, it returns to step S31 and continues to extract the previous UEFI configuration data corresponding to the previous recovery point and perform the restoration operation until the previous recovery point is the target recovery point.

[0108] Based on the above steps, when a UEFI configuration change occurs, the electronic device generates recovery points containing only the difference data and stores them in a recovery point list in chronological order. When recovery is needed, starting from the most recent recovery point, the configuration is rolled back to the previous recovery point, and the restored recovery points are deleted. Finally, it is determined whether the target recovery point has been reached. If not, the rollback continues backward. Through this gradual recovery method, the system ultimately and accurately recovers to the target recovery point. This ensures recovery accuracy while reducing storage pressure by storing only the difference data.

[0109] Figure 5 This is a schematic diagram illustrating the implementation process of a recovery method provided in an embodiment of this application, as shown below. Figure 5 As shown, step S102, based on the UEFI configuration data, determines the recovery point used to record the UEFI configuration data in the recovery point list, including: S501. Based on the UEFI configuration data and the UEFI initial configuration data, determine the second difference data.

[0110] In some examples, the process of determining the second difference data based on UEFI configuration data and UEFI initial configuration data may include: comparing all configuration items in the UEFI configuration data and UEFI initial configuration data to obtain the second difference data.

[0111] The process of comparing all configuration items in the UEFI configuration data and the initial UEFI configuration data to obtain the second difference data may include: comparing all configuration items in the UEFI configuration data and the initial UEFI configuration data; if there are differences between all configuration items in the UEFI configuration data and the initial UEFI configuration data, then the second difference data can be obtained. If there are no differences between the UEFI configuration data and the initial UEFI configuration data, then no second difference data exists. After obtaining the second difference data, a new recovery point can be generated based on the second difference data.

[0112] S502. Based on the second difference data, add a recovery point to the recovery point list to record UEFI configuration data.

[0113] After obtaining the second difference data, you can add a recovery point to the recovery point list.

[0114] In some examples, the recovery point may include UEFI configuration data, or it may only include the second difference data. The electronic system's configuration data can then be restored to the UEFI configuration data based on the second difference data and the UEFI configuration data.

[0115] In this embodiment, the initial UEFI configuration data is used as the base data. Each recovery point records the difference between the UEFI configuration data and the initial UEFI configuration data. This allows the configuration at any recovery point to be quickly reconstructed using the initial UEFI configuration data and the difference data, simplifying the storage and management of UEFI configuration data. Furthermore, the initial UEFI configuration data represents the standard configuration of the electronic device at the factory. Recovery points generated based on this initial UEFI configuration data can more clearly reflect the degree to which the latest UEFI configuration data deviates from the standard configuration, facilitating users or electronic devices to determine the rationality of configuration changes and providing more intuitive data support for subsequent configuration auditing and troubleshooting.

[0116] In one possible implementation, see Figure 6 The detailed process of this recovery method may include: S41. Initialize the change history database.

[0117] Once the electronic device is powered on, the Power-On Self-Test (POST) process will officially begin.

[0118] During this process, the UEFI firmware in the electronic device simultaneously initiates hardware initialization, detecting and configuring various core hardware components such as the processor, memory, hard drive, motherboard, and interface devices one by one to ensure the normal operation of each hardware component. After the POST process is completed and the hardware initialization verification is passed, the UEFI firmware further guides the boot process, reads and loads the operating system boot files, and finally completes the normal boot, allowing the electronic device to enter a runnable state.

[0119] After the electronic device is powered on, an initialization operation is performed on the change history database. This change history database includes at least one temporary change list, which is used to collect configuration changes that occur during a single startup.

[0120] For example, when the POST process starts, the electronic device first initializes an empty change history node (i.e., change history node). This node is used to collect the change list in this POST process and create a corresponding temporary change list for the current startup session, providing data support for subsequent configuration tracing and recovery.

[0121] By initializing the change history database, we can ensure that each startup's change records are independent and ordered, avoiding confusion with previous records. Once the current POST is complete, this temporary change list is added to the change history database, and the historical change records stored in the change history database are not cleared.

[0122] S42, Detect OOB changes.

[0123] When an external OOB change request is initiated, the Baseboard Management Controller (BMC) of the electronic device receives the request. The BMC includes a preset flag to indicate whether an OOB change has occurred. It then sends a notification message to the UEFI firmware stating that an OOB change request exists. After the UEFI firmware boots, the Universal Configuration Management (UCM) module within the UEFI firmware periodically reads the preset flag in the BMC. If the preset flag indicates an OOB change, the UCM module reads the corresponding UEFI change content from a designated storage area in the BMC. If the preset flag indicates no OOB change exists, the UEFI configuration interface is accessed.

[0124] The UEFI change information includes the name of the changed UEFI configuration item, the target setting value, and the time the change was initiated.

[0125] In addition, OOB and in-band are two interface types for UEFI configuration changes, and both of these interfaces support UEFI change operations.

[0126] S421. Add the changed OOB settings to the change history database.

[0127] Upon detecting an Out-of-Band (OOB) change, the electronic device updates the detected UEFI change to a temporary change list, and then adds the temporary change list to the change history database. This ensures that the UEFI change corresponding to the OOB change is completely recorded, without missing any out-of-band configuration adjustments.

[0128] S422, requires a restart.

[0129] Because some UEFI changes corresponding to OOB changes cannot take effect immediately in the current boot process and must be fully loaded via a reboot, the electronic device determines whether a reboot is required after recording the OOB change. If the result is "yes," the electronic device will trigger a reboot, and the process will return to boot. If the result is "no," it means that the UEFI changes corresponding to the OOB change can take effect in the current boot process, and the process continues.

[0130] S43, Access the settings interface.

[0131] During the startup process, the electronic device also monitors the user's key presses to determine whether to trigger entry into the UEFI configuration interface (also known as the settings interface). If the user presses the corresponding key, it means that the user needs to manually modify the configuration, and the process proceeds to S14; if the key press is not detected, it means that the user does not need to make any manual adjustments, and the process ends directly.

[0132] S44, Set the main loop.

[0133] After the user enters the UEFI configuration interface, the process enters the main configuration loop. In the UEFI configuration interface, the user can browse all configurable UEFI options (such as boot order, hardware parameters, security settings, etc.) and adjust them as needed. This step S14 is a loop step; the user does not need to complete all modifications at once, but can repeatedly browse different configuration menus and modify multiple configuration items until all adjustments are completed.

[0134] S45, Exit Settings.

[0135] The electronic device will detect whether the user clicks the exit option in the UEFI configuration interface. If the user does not click the exit option, the process returns to S44 to continue executing the main setting loop; if the user confirms the exit, it means that the configuration modification has been completed, and the process continues to execute S46.

[0136] S46, Keep settings.

[0137] The electronic device writes all changes made by the user during the current session (i.e., configuration items temporarily stored in the temporary change list) to non-volatile RAM. NVRAM retains data even after the device is powered off, ensuring that modified configuration items become permanent system configurations and do not need to be reconfigured on the next startup.

[0138] S47. Compare the current UEFI configuration data with the initial UEFI configuration data.

[0139] After obtaining the current UEFI configuration data, the electronic device can compare the current UEFI configuration data with the default configuration preset by the factory (i.e., the initial UEFI configuration data) item by item, thereby filtering out the modified configuration items, clarifying the differences between the current UEFI configuration data and the initial UEFI configuration data, and providing a basis for determining whether to record changes in the future.

[0140] S48, Detection differences.

[0141] If the comparison reveals a difference between the current UEFI configuration data and the initial UEFI configuration data, it indicates that the electronic device is in a non-default configuration state and further processing of related changes is required. The process will continue to step S49. If no difference is found after comparison, it indicates that the current UEFI configuration data is completely consistent with the default configuration, and no configuration change needs to be recorded. The process ends.

[0142] S49. Record the changed settings to the temporary change list.

[0143] If the current UEFI configuration data differs from the initial UEFI configuration data, a change recording operation is performed. The electronic device records all modified configuration items selected by S47 in a temporary change list created for this session. This allows for centralized storage of all modified configuration items, preventing any omissions, and lays a data foundation for archiving modified configuration items to the change history database later, enabling configuration traceability.

[0144] Based on the above steps, after the electronic device starts up, it first initializes the change history database to prepare for recording configuration changes. When an OOB change is detected, the electronic device adds the modified configuration item to the change history database. Users can modify configuration items through the UEFI configuration interface. After the modified configuration item is saved, the electronic device compares the current UEFI configuration data with the initial UEFI configuration data and records any discrepancies in the current UEFI configuration data to a temporary change list, ensuring that all modified configuration items are accurately recorded.

[0145] Figure 7 This is a schematic diagram illustrating the implementation process of a recovery method provided in an embodiment of this application, as shown below. Figure 7 As shown, in S103, restoring the current UEFI configuration data to the target UEFI configuration data includes: S701, Load UEFI initial configuration data.

[0146] In some examples, the initial UEFI configuration data is the default UEFI configuration data of the electronic device.

[0147] When the operating information of the electronic device meets the preset conditions, the current UEFI configuration data can be restored to the target UEFI configuration data based on multiple recovery points in the recovery point list and the initial UEFI configuration data.

[0148] S702: Read the target UEFI configuration data from the target recovery point and restore the initial UEFI configuration data to the target UEFI configuration data.

[0149] In some examples, the target recovery point includes the target UEFI configuration data corresponding to the target recovery point.

[0150] The process of restoring the current UEFI configuration data to the target UEFI configuration data may include: determining the target recovery point in the recovery point list, reading the target UEFI configuration data from the target recovery point; and restoring the UEFI initial configuration data to the target UEFI configuration data after the electronic device has loaded the initial UEFI configuration data (at this time, the current UEFI configuration data of the electronic device is the initial UEFI configuration data).

[0151] In other examples, the target recovery point includes target difference data. This target difference data is the difference between the target UEFI configuration data corresponding to the target recovery point and the initial UEFI configuration data.

[0152] The process of restoring the current UEFI configuration data to the target UEFI configuration data may include: determining the target recovery point in the recovery point list and reading the target difference data from the target recovery point; after the electronic device has loaded the initial UEFI configuration data (at this time, the current UEFI configuration data of the electronic device is the initial UEFI configuration data), obtaining the target UEFI configuration data based on the initial UEFI configuration data and the target difference data; and restoring the initial UEFI configuration data to the target UEFI configuration data.

[0153] It is understandable that when the target UEFI configuration data is the previous UEFI configuration data corresponding to the previous recovery point of the current recovery point, or when the target UEFI configuration data is not the previous UEFI configuration data corresponding to the previous recovery point of the current recovery point, the process of restoring the current UEFI configuration data to the target UEFI configuration data is similar to the above process, and will not be repeated here.

[0154] For example, the default value of Setting X in the UEFI configuration data is 1 (i.e., the value of Setting X in the initial UEFI configuration data is 1). The user changes the setting value of Setting X to 2 at restore point A, to 3 at restore point B, and to 4 at restore point C. When the electronic device's operating information meets preset conditions, and the user chooses to roll back the setting value of Setting X in the current UEFI configuration data to restore point A, the electronic device directly loads the initial UEFI configuration data, then determines the target restore point (i.e., restore point A) in the restore point list, reads the setting value of Setting X (2) from restore point A, and replaces the setting value of Setting X (1) in the initial UEFI configuration data with the setting value of Setting X (2) from restore point A, thus restoring the setting value of Setting X to 2.

[0155] If the target UEFI configuration data is not the same as the previous UEFI configuration data corresponding to the previous recovery point, the target recovery point can be directly determined from the recovery point list using the method described above. Based on the target difference data and the initial UEFI configuration data in the target recovery point, the target UEFI configuration data is obtained. Then, the initial UEFI configuration data is restored to the target UEFI configuration data. This eliminates the need to roll back from the current recovery point to the target recovery point one by one, improving rollback efficiency.

[0156] In this embodiment, the restoration process is based on the initial UEFI configuration data, avoiding the cumulative errors that may occur from multiple recovery point backtracking and ensuring the accuracy of the restoration. Furthermore, only the initial UEFI configuration data needs to be loaded; the restoration can then be completed based on the initial UEFI configuration data and the target difference data, eliminating the need to read complete data from multiple recovery points, thus simplifying the restoration process and improving execution efficiency. For scenarios where the difference between the target UEFI configuration data and the initial UEFI configuration data is small, this approach ensures restoration quality while reducing operational complexity.

[0157] The recovery method provided in this application embodiment will be described in detail below with reference to specific application scenarios. The recovery method includes two stages: the first stage is the recovery point generation stage, and the second stage is the recovery stage.

[0158] like Figure 8A As shown, the first stage (recovery point generation stage) includes the following steps: S51. Has a UEFI configuration change been detected?

[0159] Once the electronic device is powered on and completes initialization, the recovery point generation process officially begins.

[0160] The electronic device enters the UEFI configuration change monitoring state to detect whether any UEFI configuration changes have occurred. If a UEFI configuration change is detected, the process proceeds to step S52; if no UEFI configuration change is detected, the monitoring state is maintained until a UEFI configuration change is detected.

[0161] S52. Generate the difference data between the UEFI configuration data and the UEFI initial configuration data.

[0162] After confirming the detection of a UEFI configuration change, the electronic device obtains the UEFI configuration data corresponding to the change. It then compares this UEFI configuration data with the initial UEFI configuration data item by item, calculating and generating difference data between the two. This difference data only includes the actually modified configuration items and their values ​​before and after the change; it does not record unchanged UEFI configuration content.

[0163] S53. Add the second recovery point to the recovery point list.

[0164] The second recovery point includes the difference data between the UEFI configuration data and the initial UEFI configuration data.

[0165] The electronic device creates a second recovery point based on the difference between the UEFI configuration data generated in step S52 and the initial UEFI configuration data. Subsequently, the created second recovery point is added to the recovery point list in chronological order for easy tracing and restoration later.

[0166] like Figure 8B As shown, the second phase (recovery phase) includes the following steps: S61, Load UEFI initial configuration data.

[0167] When the operating information of an electronic device meets preset conditions, the electronic device enters the recovery phase.

[0168] After the electronic device enters the recovery phase, the target recovery point to be restored is first determined. Then, the electronic device reads and loads the UEFI initial configuration data from the non-volatile storage area, using it as the baseline template for configuration restoration. At this point, the electronic device rolls back to its initial factory configuration.

[0169] S62. Restore the target difference data corresponding to the target recovery point on the UEFI initial configuration data.

[0170] The electronic device extracts the target difference data corresponding to the target recovery point from the recovery point list, overlays the target difference data corresponding to the target recovery point onto the loaded UEFI initial configuration data to obtain the target UEFI configuration data, and restores the UEFI initial configuration data to the target UEFI configuration data.

[0171] Based on the above steps, upon detecting a configuration change, the electronic device generates target difference data between the current UEFI configuration data and the initial UEFI configuration data, storing this as a target recovery point in the recovery point list. During recovery, the initial UEFI configuration data is first loaded as a baseline. Then, the target difference data is extracted from the recovery point list and applied to the initial UEFI configuration data, thereby quickly reconstructing the target UEFI configuration data and rolling back the current UEFI configuration data to the target UEFI configuration data. In this way, through the efficient storage and application of difference data, the complexity of step-by-step rollback is avoided, allowing direct restoration from a baseline state to any historical configuration, ensuring recovery accuracy while improving operational efficiency.

[0172] Figure 9 This is a schematic diagram illustrating the implementation process of a recovery method provided in an embodiment of this application, as shown below. Figure 9 As shown, before S101 obtains the UEFI configuration data, the method also includes: S901. In response to a setting command, the setting value corresponding to the setting command is stored in the editing buffer.

[0173] The setting command is a command generated in response to the user's setting operation in the UEFI configuration interface; or, the setting command is a command generated in response to the outgoing baseline OOB setting.

[0174] The edit buffer is used to temporarily store all changes made by the user during the current UEFI setup session, ensuring that these changes do not directly affect the actual operating configuration of the electronic device before the user confirms them.

[0175] A storage buffer is used to store the current configuration values ​​of an electronic device, or the configuration values ​​saved since the last modification.

[0176] At the beginning of a UEFI setup session, the initial values ​​of the edit buffer and the storage buffer are exactly the same. When UEFI configuration data in the UEFI configuration interface is modified, the configuration items in the edit buffer are updated, but the data in the storage buffer is not updated. For example, a user sets UEFI configuration data in the UEFI configuration interface using the keyboard or mouse (e.g., switching the "Secure Boot" function from "Off" to "On"), at which point the electronic device receives a setting command. In response to the setting command, the electronic device obtains the setting value (i.e., the configuration item) corresponding to the setting command and stores the setting value in the edit buffer.

[0177] S902. If the setting value of the edit buffer and the initial value of the storage buffer are inconsistent, obtain UEFI configuration data.

[0178] In some examples, when the setting value in the edit buffer is updated, the electronic device compares the setting value in the edit buffer with the initial value in the storage buffer. If the setting value in the edit buffer and the initial value in the storage buffer are the same, the output result is true. If the setting value in the edit buffer and the initial value in the storage buffer are different, the output result is false, indicating that the setting of the UEFI configuration data has changed relative to the initial value, so it is necessary to obtain the UEFI configuration data after the change.

[0179] In one possible implementation, see Figure 10 The detailed process of this recovery method may include: S71, User modifies configuration items.

[0180] Electronic devices can detect whether a user has modified a configuration item in the UEFI configuration interface.

[0181] S72, Update the settings of the edit buffer.

[0182] When the electronic device detects that a user has modified a configuration item in the UEFI configuration interface, it first updates the modified configuration item to the edit buffer.

[0183] S73. Is the setting value of the edit buffer equal to the setting value of the storage buffer?

[0184] The electronic device compares the temporary settings in the edit buffer with the initial values ​​saved in the storage buffer. If the comparison result is "equal," meaning the settings in the edit buffer and the initial values ​​in the storage buffer are exactly the same, the modification is considered invalid. This could be because the user changed the parameter back to its original value or entered a new value identical to the original. In this case, the electronic device will return "False" and terminate the process directly. This return value "False" indicates that the user's operation did not result in a substantial configuration change, therefore no subsequent processing is required, such as generating a new configuration restore point or performing a configuration write-to-memory operation.

[0185] If the comparison result is "not equal," meaning the setting value in the edit buffer is different from the initial value in the storage buffer, the modification is considered valid. In this case, the electronic device will return "True." This "True" return value indicates that the user operation has resulted in a substantial configuration change, which may require triggering subsequent processing, such as generating a new configuration restore point or performing configuration write-to-memory operations. This effectively filters redundant operations, avoids unnecessary system overhead and storage waste caused by invalid modifications, and improves system execution efficiency and resource utilization.

[0186] Based on the above steps, by first storing the setting values ​​corresponding to the setting commands in the editing buffer and then performing a consistency check with the initial values ​​in the storage buffer, the configuration operations that have actually changed can be accurately identified. This avoids redundant generation of recovery points due to invalid operations and ensures that subsequent processes are triggered only when the configuration actually changes, thus improving the effectiveness and conciseness of the recovery point list. At the same time, the setting commands explicitly include both manual operations by the user in the UEFI configuration interface and automatic operations in OOB settings, covering all scenarios and ensuring comprehensive capture of configuration changes, providing a data foundation for subsequent processing.

[0187] like Figure 11 As shown below, a flowchart illustrating the recovery point generation stage is provided in conjunction with a specific application scenario.

[0188] S81. Collect all HII handles from the HII configuration database.

[0189] When an electronic device receives a UEFI configuration command (e.g., triggered manually by the user or when the electronic device's operating information meets preset conditions), the processing module in the electronic device used to perform HII configuration data processing is activated. Generally, the processing module will first complete initialization.

[0190] The initialization of the processing module includes loading the required UEFI driver, calling HII-related interfaces, and establishing a communication link with the BMC, laying the foundation for subsequent reading of the HII configuration database and operation of configuration data.

[0191] In UEFI configuration, Human Interface Infrastructure (HII) configuration data is used to define the displayed content in the UEFI configuration interface. HII configuration data includes text, forms, fonts, etc., and essentially serves as the presentation layer for configuration data.

[0192] HII configuration data does not store actual configuration values. Instead, it associates with variables in NVRAM through string IDs, problem IDs, etc. When the user modifies the settings, the configuration value corresponding to the HII configuration data is written to NVRAM through the variable service, thus achieving separation between display and data.

[0193] Here, the HII configuration database is the database in the UEFI firmware that stores HII configuration data. The HII handle is an identifier used to uniquely identify each piece of HII configuration data in the HII configuration database. HII configuration data can be quickly located through the HII handle.

[0194] Electronic devices can traverse the HII configuration database through UEFI firmware. During the traversal, the electronic device can filter and extract all valid HII handles, excluding invalid, damaged, or obsolete HII handles. The collected HII handles can be stored in a temporary array in a certain order, and the HII configuration data corresponding to each HII handle can be processed one by one to ensure that no set of HII configuration data is missed.

[0195] S82. Create a form set linked list node for each HII form package in each HII handle.

[0196] The HII form package is the configuration unit corresponding to the HII handle, and one HII handle is usually associated with one HII form package. The form set linked list node is a storage unit designed with a linked list structure. The form set linked list node is used to store the basic information of a single HII form package (such as the name, version, and associated handle of the HII form package).

[0197] For each HII handle collected in step S81, the electronic device extracts the HII form package corresponding to each HII handle and creates a form set linked list node corresponding to each HII form package, so that the configuration data of each HII form package has a dedicated storage area, thereby providing a structural basis for the storage of subsequent data.

[0198] S83. For each HII variable in the HII form package, create a variable storage linked list node under the form set linked list node and store it.

[0199] The HII variables are used to record the values ​​of various parameters configured by the user. The variable storage linked list nodes are child nodes of the form set linked list nodes, and each variable storage linked list node stores one HII variable.

[0200] The electronic device traverses all HII variables under the HII form package, and creates a corresponding variable storage linked list node under the corresponding form set linked list node for each HII variable, so that the HII variable is associated with the HII form, thereby ensuring efficient management of HII variables.

[0201] S84. For each HII issue in the HII form package, create an issue linked list node under the form set linked list node.

[0202] HII questions are the configuration items displayed to the user in the HII form. HII questions include actual hardware or system configuration options (e.g., CPU frequency settings, boot order selection, etc.). Question list nodes are another type of child node in the form set list nodes; these nodes store each HII question.

[0203] For each HII question in the current HII form package, the electronic device creates an independent question linked list node under the corresponding form set linked list node, storing HII questions and HII variables separately, thus improving the organization of data management.

[0204] S85. Obtain each HII variable and store it in the variable storage linked list node.

[0205] Electronic devices extract configuration data (such as memory frequency values, security start switch status, etc.) stored in each HII variable through the associated index of HII variables, and write this data into the corresponding variable storage linked list node created by S83 to realize the storage of HII variables and provide a data source for subsequent HII problem acquisition.

[0206] S86. Based on the variable storage attributes of each HII question, obtain its value and store it in the question linked list node.

[0207] The variable storage attributes are used to associate HII questions with HII variables. Variable storage attributes include variable storage ID, offset, and width.

[0208] The variable storage ID is used to locate the corresponding variable storage area, the offset is used to determine the starting position of the HII variable in the storage area, and the width is used to determine the byte length of the HII variable.

[0209] The electronic device extracts the configuration value corresponding to each HII problem from the corresponding variable storage linked list node according to the variable storage attribute of each HII problem, and writes it into the problem linked list node created by S84, so that each HII problem corresponds one-to-one with its configuration value, forming a complete problem-configuration value mapping relationship.

[0210] S87. Whether to use Redfish JSON.

[0211] Redfish JSON is a data exchange format based on the Redfish protocol, a standardized protocol for server hardware management. JSON is lightweight and easy to parse, primarily used for cross-platform data exchange. XML is another commonly used data storage format, mainly used for storing complex configuration data.

[0212] Electronic devices determine whether to use Redfish JSON to decide the format for subsequent data processing and recovery point storage, thereby adapting to different system management needs and hardware support scenarios.

[0213] S8711. Prepare the naming for the Redfish JSON.

[0214] If you confirm that you will be using Redfish JSON, first prepare the name of the Redfish JSON.

[0215] The electronic device prepares names for the subsequently generated Redfish JSON files according to preset naming rules (e.g., including timestamps, device identifiers, configuration versions, etc.). This ensures that the file names are unique and easily identifiable, facilitating subsequent searching, management, and traceability.

[0216] S8712, Read the first BIOS JSON from the BMC.

[0217] As mentioned above, the BMC is an embedded controller on the server, independent of the main CPU, used for hardware monitoring and remote management. The first BIOS JSON is a JSON format file stored in the BMC that records the current UEFI configuration data.

[0218] The electronic device communicates with the BMC to obtain the first BIOSJSON corresponding to the current UEFI configuration stored in the BMC. This first BIOS JSON is used as the baseline data for subsequent comparison with locally collected HII variables.

[0219] S8713. Traverse each node in the problem list, read the value from the first BIOS JSON and compare it with the value in the node, and record the problems with discrepancies.

[0220] The electronic device traverses all problem list nodes, extracting the value corresponding to the HII problem stored in each problem list node; simultaneously, it retrieves the value corresponding to the HII problem from the first BIOS JSON read from S8712, and compares the values ​​corresponding to the two HII problems. If they are inconsistent, the electronic device marks and records the HII problem, providing a basis for subsequent changes when generating recovery points.

[0221] S8714. Dump all issues where values ​​have changed to a BIOS JSON file and store that file as a recovery point BIOS JSON file in the BMC.

[0222] The recovery point BIOS JSON is used to record the JSON file corresponding to the current UEFI configuration changes.

[0223] The electronic device merges all HII issues and their corresponding values ​​recorded by the S8713 into a new JSON file, which is the recovery point BIOS JSON. This recovery point BIOS JSON is then uploaded and stored in the BMC, completing the backup of the configuration changes and providing data support for subsequent configuration recovery.

[0224] S8715, Convert the form set linked list to a Redfish BIOS property registry and a second BIOS JSON.

[0225] The Redfish BIOS Property Registry is a specification file that defines Redfish BIOS configuration properties, including the type and range of configuration items. The second BIOS JSON is a file that stores the specific values ​​of these configuration properties.

[0226] The electronic device constructs a linked list of forms, which is then broken down into two parts according to the Redfish protocol specification: one part is a Redfish BIOS property registry for defining configuration attributes, and the other part is a second BIOS JSON that stores the attribute values. This allows the HII configuration data to be adapted to the Redfish protocol's management standard, facilitating subsequent remote configuration management via the Redfish protocol.

[0227] S8716, Store the file in the BMC.

[0228] The electronic device uploads and stores the Redfish BIOS attribute registry and the second BIOS JSON obtained from the S8715 to the BMC, and archives them together with the recovery point BIOS JSON to form a complete set of Redfish format configuration files, further improving the configuration backup system.

[0229] S8721. Prepare the naming of the XML.

[0230] If you are sure you are not using Redfish JSON, first prepare the naming of the XML.

[0231] Electronic devices prepare names for subsequently generated XML files according to preset unified naming rules (such as including device model, configuration time, file type, etc.), ensuring that the files are easy to identify, classify and trace, and comply with the management specifications of configuration files.

[0232] S8722, Read the first XML from BMC.

[0233] The first XML is an XML format file stored in the BMC that records the current BIOS configuration data; it is the baseline configuration file in XML format.

[0234] The electronic device establishes communication with the BMC and reads the first XML corresponding to the current UEFI configuration stored in the BMC. This first XML will be used as benchmark data for comparison with local HII variables.

[0235] S8723. Traverse each node of the problem list, read the value from the first XML and compare it with the value in the node, and record the problems that have differences.

[0236] The electronic device iterates through all nodes in the problem list, extracts the values ​​corresponding to the HII problems from each node, and simultaneously retrieves the corresponding values ​​for the HII problems from the first XML read from S8722. It then compares the values ​​corresponding to the two HII problems. If they are inconsistent, the electronic device marks and records the HII problem, providing a basis for subsequent changes when generating recovery points.

[0237] S8724. Dump all issues where values ​​have changed to an XML file and store that file as a recovery point XML in the BMC.

[0238] Among them, the recovery point XML is used to record the XML format file corresponding to the current UEFI configuration change.

[0239] The electronic device merges all HII issues and their corresponding values ​​recorded by the S8723 into a new XML file, which is the recovery point XML. The recovery point XML is then uploaded and stored in the BMC to complete the backup of the configuration change, providing data support for subsequent configuration recovery.

[0240] S8725. Convert the form set linked list into an XML node tree.

[0241] The XML node tree is a structured representation of an XML file. It consists of multiple nodes, each corresponding to a configuration item. Each node also includes the configuration item's definition information (such as name and type) and numerical information. The electronic device converts the HII configuration data (including form packages, variables, questions, etc.) in the form set linked list into an XML node tree according to the XML syntax rules. Each node in the XML node tree includes the definition and value of the HII configuration, so that the HII configuration data is adapted to the XML storage specification.

[0242] S8726. Convert the XML node tree into XML text.

[0243] The electronic device converts the XML node tree constructed by S8725 into XML text conforming to XML syntax standards. This XML text fully preserves the definitions and values ​​of the HII configuration, providing directly operable file content for subsequent storage and use of XML files. The electronic device uploads and stores the XML text file generated by S8726 to the BMC, forming a complete XML format configuration file backup together with the recovery point XML, ensuring the integrity and traceability of configuration data in the XML scenario.

[0244] like Figure 12 As shown below, a flowchart illustrating the recovery phase of a recovery point is provided in conjunction with a specific application scenario.

[0245] S91. Collect all HII handles from the HII configuration database.

[0246] When an electronic device receives a UEFI configuration command (e.g., triggered manually by the user or when the electronic device's operating information meets preset conditions), the processing module in the electronic device used to perform HII configuration data processing is activated. Generally, the processing module will first complete initialization.

[0247] The initialization of the processing module includes loading the required UEFI driver, calling HII-related interfaces, and establishing a communication link with the BMC, laying the foundation for subsequent reading of the HII configuration database and operation of configuration data.

[0248] In UEFI configuration, Human Interface Infrastructure (HII) configuration data is used to define the displayed content in the UEFI configuration interface. HII configuration data includes text, forms, fonts, etc., and essentially serves as the presentation layer for configuration data.

[0249] HII configuration data does not store actual configuration values. Instead, it associates with variables in NVRAM through string IDs, problem IDs, etc. When the user modifies the settings, the configuration value corresponding to the HII configuration data is written to NVRAM through the variable service, thus achieving separation between display and data.

[0250] Here, the HII configuration database is the database in the UEFI firmware that stores HII configuration data. The HII handle is an identifier used to uniquely identify each piece of HII configuration data in the HII configuration database. HII configuration data can be quickly located through the HII handle.

[0251] Electronic devices can traverse the HII configuration database through UEFI firmware. During the traversal, the electronic device can filter and extract all valid HII handles, excluding invalid, damaged, or obsolete HII handles. The collected HII handles can be stored in a temporary array in a certain order, and the HII configuration data corresponding to each HII handle can be processed one by one to ensure that no set of HII configuration data is missed.

[0252] S92. Create a form set linked list node for each HII form package in each HII handle.

[0253] The HII form package is the configuration unit corresponding to the HII handle, and one HII handle is usually associated with one HII form package. The form set linked list node is a storage unit designed with a linked list structure. The form set linked list node is used to store the basic information of a single HII form package (such as the name, version, and associated handle of the HII form package).

[0254] For each HII handle collected in step S91, the electronic device extracts the HII form package corresponding to each HII handle and creates a form set linked list node corresponding to each HII form package, so that the configuration data of each HII form package has a dedicated storage area, thereby providing a structural basis for the storage of subsequent data.

[0255] S93. For each HII variable in the HII form package, create a variable storage linked list node under the form set linked list node and store it.

[0256] The HII variables are used to record the values ​​of various parameters configured by the user. The variable storage linked list nodes are child nodes of the form set linked list nodes, and each variable storage linked list node stores one HII variable.

[0257] The electronic device traverses all HII variables under the HII form package, and creates a corresponding variable storage linked list node under the corresponding form set linked list node for each HII variable, so that the HII variable is associated with the HII form, thereby ensuring efficient management of HII variables.

[0258] S94. For each HII issue in the HII form package, create an issue linked list node under the form set linked list node.

[0259] HII questions are the configuration items displayed to the user in the HII form. HII questions include actual hardware or system configuration options (e.g., CPU frequency settings, boot order selection, etc.). Question list nodes are another type of child node in the form set list nodes; these nodes store each HII question.

[0260] For each HII question in the current HII form package, the electronic device creates an independent question linked list node under the corresponding form set linked list node, storing HII questions and HII variables separately, thus improving the organization of data management.

[0261] S95. Obtain each HII variable and store it in the variable storage linked list node.

[0262] Electronic devices extract configuration data (such as memory frequency values, security start switch status, etc.) stored in each HII variable through the associated index of HII variables, and write this data into the corresponding variable storage linked list node created by S93 to realize the storage of HII variables and provide a data source for subsequent HII problem acquisition.

[0263] S96. Based on the variable storage attributes of each HII question, obtain its value and store it in the question linked list node.

[0264] The variable storage attributes are used to associate HII questions with HII variables. Variable storage attributes include variable storage ID, offset, and width.

[0265] The variable storage ID is used to locate the corresponding variable storage area, the offset is used to determine the starting position of the HII variable in the storage area, and the width is used to determine the byte length of the HII variable.

[0266] The electronic device extracts the configuration value corresponding to each HII problem from the corresponding variable storage linked list node according to the variable storage attribute of each HII problem, and writes it into the problem linked list node created by S94, so that each HII problem corresponds one-to-one with its configuration value, forming a complete problem-configuration value mapping relationship.

[0267] S97. Whether to use Redfish JSON.

[0268] Redfish JSON is a data exchange format based on the Redfish protocol, a standardized protocol for server hardware management. JSON is lightweight and easy to parse, primarily used for cross-platform data exchange. XML is another commonly used data storage format, mainly used for storing complex configuration data.

[0269] Electronic devices determine whether to use Redfish JSON to decide the format for subsequent data processing and recovery point storage, thereby adapting to different system management needs and hardware support scenarios.

[0270] S9711. Prepare the naming for the Redfish JSON.

[0271] If you confirm that you will be using Redfish JSON, first prepare the name of the Redfish JSON.

[0272] The electronic device prepares a name for the subsequently generated Redfish JSON file according to a preset naming rule (e.g., including timestamp, device identifier, configuration version, etc.). This ensures that the file name is unique and easily identifiable, facilitating subsequent searching, management, and traceability.

[0273] S9712, Read the specified recovery point BIOS JSON from the BMC.

[0274] The recovery point BIOS JSON is a backup file stored in the BMC, used to record the target UEFI configuration data corresponding to the target recovery point.

[0275] Electronic devices communicate with the BMC via the Redfish API or IPMI protocol. Based on the filename of the S9711, they read the corresponding recovery point BIOS JSON from the designated area of ​​the BMC, and save the recovery point BIOS JSON after integrity verification.

[0276] S9713. Traverse each node in the problem list, read the value from the recovery point BIOS JSON and compare it with the value in the node, and record the problems with discrepancies.

[0277] The electronic device traverses all problem list nodes, extracting the value corresponding to the HII problem stored in each problem list node; simultaneously, it searches for the corresponding value of the HII problem in the recovery point BIOS JSON based on the HII problem ID, and compares the two sets of values ​​corresponding to the HII problems. If they do not match, the electronic device records the HII problem in the temporary change list.

[0278] S9714. Update the value recorded in EMC to the variable storage area, and update the variable storage area using the HII update value method.

[0279] EMC is a temporary storage unit used to record HII issues and recovery points in the BIOS JSON format, along with the corresponding values ​​for the HII issues in the BIOSJSON. The variable storage area is the physical area (e.g., NVRAM) that stores HII configuration data. The HII update value method is a configuration update interface provided by UEFI. The HII update value method includes setting variables and RouteConfig. Setting variables is used to directly update variable values, while RouteConfig is used to update variable values ​​via HII routing.

[0280] The electronic device reads the value corresponding to the recovery point recorded in the temporary change list, writes the value corresponding to the recovery point to the variable storage area, and then calls the HII update value method to ensure that the update of the variable storage area takes effect, thereby realizing the restoration of the configuration.

[0281] Once the electronic device has completed updating all discrepancies, the configuration value of the verification variable storage area is consistent with the recovery point baseline value. The communication link with the BMC is then closed, temporary storage resources are released, and the recovery process officially terminates.

[0282] S9721. Prepare the naming for the XML.

[0283] If you are sure you are not using Redfish JSON, first prepare the naming of the XML.

[0284] Electronic devices prepare names for subsequently generated XML files according to preset unified naming rules (such as including device model, configuration time, file type, etc.), ensuring that the files are easy to identify, classify and trace, and comply with the management specifications of configuration files.

[0285] S9722, Read recovery point XML from BMC.

[0286] Among them, the recovery point XML is a backup file stored in the BMC, used to record the target UEFI configuration data corresponding to the target recovery point.

[0287] The electronic device establishes communication with the BMC via IPMI or HTTP protocol, reads the corresponding recovery point XML from the designated area of ​​the BMC according to the file name of S9811, and saves the recovery point XML after verification.

[0288] S9723. Traverse each node in the problem list, read the value from the recovery point XML and compare it with the value in the node, and record the problems with discrepancies.

[0289] The electronic device iterates through all nodes in the problem list, extracts the values ​​corresponding to the HII problems from each node, and simultaneously retrieves the corresponding values ​​for the HII problems from the recovery point XML based on the problem ID. It then compares the two sets of values ​​for the HII problems. If they do not match, the electronic device records the HII problem in the temporary change list.

[0290] Here, EMC is a temporary storage unit used to record the HII problem in XML format and the corresponding value of the HII problem in the recovery point XML.

[0291] The electronic device reads the value corresponding to the recovery point recorded in the temporary change list, writes the value corresponding to the recovery point to the variable storage area, and then calls the HII update value method to ensure that the update of the variable storage area takes effect, thereby realizing the restoration of the configuration.

[0292] Once the electronic device has completed updating all discrepancies, the configuration value of the verification variable storage area is consistent with the recovery point baseline value. The communication link with the BMC is then closed, temporary storage resources are released, and the recovery process officially terminates.

[0293] The difference between the recovery point generation phase and the recovery point restoration phase lies in their focus. The recovery point generation phase is a "backup record," collecting configuration data from the local HII (Hybrid Information Infrastructure), comparing it with the BMC (Browser Management Center) baseline file, generating recovery point files for changes, archiving them to the BMC, and outputting standardized configuration files. The recovery point restoration phase, on the other hand, is a "restore and take effect" phase. It reads the specified recovery point file from the BMC, compares the differences with the current local configuration, and writes the recovery point values ​​to the local variable storage area using the HII method, thus restoring the configuration to the target state. The data flow of the two methods is completely opposite: the recovery point generation method focuses on backing up recovery point changes, while the recovery point restoration method focuses on fault repair and state rollback.

[0294] Figure 13 This is a schematic diagram of the composition structure of an electronic device provided in an embodiment of this application, such as... Figure 13 As shown, the electronic device 1300 includes an acquisition module 1301, a determination module 1302, and a restoration module 1303; wherein, The acquisition module 1301 is used to acquire UEFI configuration data.

[0295] The determination module 1302 is used to determine the recovery point for recording UEFI configuration data in the recovery point list based on UEFI configuration data; the recovery point list includes multiple recovery points, and each recovery point includes a timestamp of each recovery point and the UEFI configuration data corresponding to each recovery point.

[0296] The restore module 1303 is used to restore the current UEFI configuration data to the target UEFI configuration data based on multiple restore points in the restore point list when the operating information of the electronic device meets the preset conditions. The target UEFI configuration data is the UEFI configuration data that matches the preset conditions.

[0297] In some embodiments, the preset conditions include any one of the following: in response to a user's triggering operation on a target recovery point in the recovery point list, the UEFI configuration data corresponding to the target recovery point is the target UEFI configuration data; the stability value of the electronic device is less than or equal to a first threshold; the startup success rate value of the electronic device is less than or equal to a second threshold; the electronic device has an abnormal startup or operation.

[0298] In some embodiments, the determining module 1302 is further configured to determine first difference data based on UEFI configuration data and the previous UEFI configuration data corresponding to the previous recovery point; and based on the first difference data, add a recovery point for recording UEFI configuration data to the recovery point list.

[0299] In some embodiments, the restore module 1303 is further configured to read the target UEFI configuration data from the previous recovery point of the current recovery point and restore the current UEFI configuration data to the target UEFI configuration data when the target UEFI configuration data is the previous UEFI configuration data corresponding to the previous recovery point of the current recovery point. The current recovery point includes the current UEFI configuration data corresponding to the current recovery point.

[0300] In some embodiments, the restore module 1303 is further configured to, when the target UEFI configuration data is not the previous UEFI configuration data corresponding to the previous recovery point of the current recovery point, repeatedly execute the step of reading the previous UEFI configuration data corresponding to the previous recovery point from the previous recovery point of the current recovery point and restoring the current UEFI configuration data to the previous UEFI configuration data; until the previous UEFI configuration data corresponding to the previous recovery point is the target UEFI configuration data, then restore the previous UEFI configuration data to the target UEFI configuration data; the current recovery point includes the current UEFI configuration data corresponding to the current recovery point.

[0301] In some embodiments, the determining module 1302 is further configured to determine second difference data based on UEFI configuration data and UEFI initial configuration data; and to add a recovery point for recording UEFI configuration data to the recovery point list based on the second difference data.

[0302] In some embodiments, the restore module 1303 is further configured to load UEFI initial configuration data; read target UEFI configuration data from the target recovery point; restore the UEFI initial configuration data to the target UEFI configuration data; and the target recovery point includes the target UEFI configuration data corresponding to the target recovery point.

[0303] In some embodiments, the electronic device further includes a setting module, which is configured to store the setting value corresponding to the setting instruction into an editing buffer in response to the setting instruction.

[0304] The acquisition module is also used to acquire UEFI configuration data when it is determined that the setting value of the edit buffer and the initial value of the storage buffer are inconsistent; wherein the setting instruction is an instruction generated in response to the user's setting operation in the UEFI configuration interface; or, the setting instruction is an instruction generated in response to the out-of-baseline OOB setting.

[0305] The descriptions of the apparatus embodiments above are similar to those of the method embodiments above, and have similar beneficial effects. In some embodiments, the functions or modules included in the apparatus provided in this application can be used to perform the methods described in the method embodiments above. For technical details not disclosed in the apparatus embodiments of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0306] It should be noted that, in the embodiments of this application, if the above-described recovery method is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiments of this application, or the part that contributes to the related technology, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, mobile hard drives, read-only memory (ROM), magnetic disks, or optical disks. Thus, the embodiments of this application are not limited to any specific hardware, software, or firmware, or any combination of hardware, software, and firmware.

[0307] This application provides a computer device including a memory and a processor. The memory stores a computer program that can run on the processor. When the processor executes the program, it implements some or all of the steps in the above-described method.

[0308] This application provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements some or all of the steps in the above-described method. The computer-readable storage medium can be transient or non-transient.

[0309] This application provides a computer program including computer-readable code. When the computer-readable code is run in a computer device, the processor in the computer device performs some or all of the steps in the above-described method.

[0310] This application provides a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program. When the computer program is read and executed by a computer, it implements some or all of the steps in the above-described method. This computer program product can be implemented specifically through hardware, software, or a combination thereof. In some embodiments, the computer program product is specifically embodied as a computer storage medium; in other embodiments, the computer program product is specifically embodied as a software product, such as a software development kit (SDK), etc.

[0311] It should be noted that the descriptions of the various embodiments above tend to emphasize the differences between them, while their similarities or commonalities can be referred to interchangeably. The descriptions of the above embodiments of the device, storage medium, computer program, and computer program product are similar to the descriptions of the above method embodiments and have similar beneficial effects. For technical details not disclosed in the embodiments of the device, storage medium, computer program, and computer program product of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0312] Figure 14 This is a schematic diagram of a hardware entity of an electronic device in an embodiment of this application, such as... Figure 14 As shown, the hardware entity of the electronic device 1400 includes: a processor 1401, a communication interface 1402, and a memory 1403. Wherein: The processor 1401 typically controls the overall operation of the electronic device 1400, which may be to implement the recovery method provided in the embodiments of this application.

[0313] The communication interface 1402 enables the electronic device 1400 to communicate with other terminals or servers via a network.

[0314] The memory 1403 is configured to store instructions and applications executable by the processor 1401, and can also cache data to be processed or already processed (e.g., image data, audio data, voice communication data, and video communication data) in the processor 1401 and various modules in the electronic device 1400. It can be implemented using flash memory or random access memory (RAM). Data transfer between the processor 1401, the communication interface 1402, and the memory 1403 can be performed via bus 1404.

[0315] This application provides a computer storage medium that stores one or more programs, which can be executed by one or more processors to implement the steps of the recovery method as described in any of the above embodiments.

[0316] It should be noted that the descriptions of the storage medium and device embodiments above are similar to the descriptions of the method embodiments above, and have similar beneficial effects. For technical details not disclosed in the storage medium and device embodiments of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0317] The aforementioned processor can be at least one of the following: Application Specific Integrated Circuit (ASIC), Digital Signal Processor (DSP), Digital Signal Processing Device (DSPD), Programmable Logic Device (PLD), Field Programmable Gate Array (FPGA), Central Processing Unit (CPU), Controller, Microcontroller, and Microprocessor. It is understood that other electronic devices can also implement the functions of the aforementioned processor, and this application does not specifically limit the specific implementation.

[0318] The aforementioned computer storage media / memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic random access memory (FRAM), flash memory, magnetic surface memory, optical disc, or compact disc read-only memory (CD-ROM), etc.; or it can be various terminals that include one or any combination of the above-mentioned memories, such as mobile phones, computers, tablet devices, personal digital assistants, etc.

[0319] It should be understood that the phrase "one embodiment" or "an embodiment" throughout the specification means that a specific feature, structure, or characteristic related to the embodiment is included in at least one embodiment of this application. Therefore, "in one embodiment" or "in an embodiment" appearing throughout the specification does not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. It should be understood that in the various embodiments of this application, the sequence numbers of the above steps / processes do not imply a sequential order of execution; the execution order of each step / process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application. The sequence numbers of the above embodiments of this application are merely descriptive and do not represent the superiority or inferiority of the embodiments.

[0320] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0321] The above are merely embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. A recovery method, the method comprising: Obtain UEFI configuration data; Based on the UEFI configuration data, determine the recovery point used to record the UEFI configuration data in the recovery point list; The recovery point list includes multiple recovery points, and each recovery point includes a timestamp of the recovery point and UEFI configuration data corresponding to the recovery point; When the operating information of the electronic device meets the preset conditions, the current UEFI configuration data is restored to the target UEFI configuration data based on the multiple recovery points in the recovery point list. The target UEFI configuration data is the UEFI configuration data that matches the preset conditions.

2. The method according to claim 1, wherein the preset condition includes any one of the following: In response to a user's triggering operation on a target recovery point in the recovery point list, the UEFI configuration data corresponding to the target recovery point is the target UEFI configuration data; The stability value of the electronic device is less than or equal to the first threshold. The startup success rate of the electronic device is less than or equal to the second threshold. The electronic device is experiencing startup or operational malfunction.

3. The method according to claim 1, wherein determining the recovery point for recording the UEFI configuration data in the recovery point list based on the UEFI configuration data includes: Based on the UEFI configuration data and the previous UEFI configuration data corresponding to the previous recovery point, the first difference data is determined; Based on the first difference data, a new recovery point is added to the recovery point list to record the UEFI configuration data.

4. The method according to any one of claims 1-3, wherein restoring the current UEFI configuration data to the target UEFI configuration data comprises: When the target UEFI configuration data is the previous UEFI configuration data corresponding to the previous recovery point of the current recovery point, the target UEFI configuration data is read from the previous recovery point of the current recovery point, and the current UEFI configuration data is restored to the target UEFI configuration data. The current recovery point includes the current UEFI configuration data corresponding to the current recovery point.

5. The method according to any one of claims 1-3, wherein restoring the current UEFI configuration data to the target UEFI configuration data comprises: If the target UEFI configuration data is not the previous UEFI configuration data corresponding to the previous recovery point of the current recovery point, the step of reading the previous UEFI configuration data corresponding to the previous recovery point from the previous recovery point of the current recovery point and restoring the current UEFI configuration data to the previous UEFI configuration data is repeated. Until the previous UEFI configuration data corresponding to the previous recovery point is the target UEFI configuration data, the previous UEFI configuration data will be restored to the target UEFI configuration data; the current recovery point includes the current UEFI configuration data corresponding to the current recovery point.

6. The method according to claim 1, wherein determining the recovery point for recording the UEFI configuration data in the recovery point list based on the UEFI configuration data includes: Based on the UEFI configuration data and the UEFI initial configuration data, the second difference data is determined; Based on the second difference data, a new recovery point is added to the recovery point list to record the UEFI configuration data.

7. The method according to claim 6, wherein restoring the current UEFI configuration data to the target UEFI configuration data comprises: Load the initial UEFI configuration data; The target UEFI configuration data is read from the target recovery point, and the initial UEFI configuration data is restored to the target UEFI configuration data. The target recovery point includes the target UEFI configuration data corresponding to the target recovery point.

8. The method according to any one of claims 1-7, wherein before obtaining the UEFI configuration data, the method further comprises: In response to a setting command, the setting value corresponding to the setting command is stored in the editing buffer; If the setting value of the edit buffer and the initial value of the storage buffer are inconsistent, the UEFI configuration data is obtained; The setting command is a command generated in response to a user's setting operation in the UEFI configuration interface; or, The setting command is a command generated in response to the out-of-baseline OOB setting.

9. A recovery device, the recovery device comprising an acquisition module, a determination module, and a restoration module, wherein: The acquisition module is used to acquire UEFI configuration data; The determining module is used to determine, based on the UEFI configuration data, a recovery point for recording the UEFI configuration data in the recovery point list; the recovery point list includes multiple recovery points, and each recovery point includes a timestamp of the recovery point and the UEFI configuration data corresponding to the recovery point. The restoration module is used to restore the current UEFI configuration data to target UEFI configuration data based on the multiple restoration points in the restoration point list when the operating information of the electronic device meets the preset conditions. The target UEFI configuration data is UEFI configuration data that matches the preset conditions.

10. An electronic device, the electronic device comprising: Memory is used to store executable instructions or computer programs. A processor, when executing computer-executable instructions or computer programs stored in the memory, implements the method according to any one of claims 1 to 8.

Images