Server configuration backup and restore method and computing device

Abstract

This application relates to a server configuration backup and recovery method and computing device. The method includes: acquiring server configuration data; backing up the configuration data to multiple storage media; wherein each storage media stores one copy of the configuration data and records backup time information; responding to a configuration recovery command, reading the backup data from the multiple storage media respectively, and determining primary backup data and at least one secondary backup data based on the time information; restoring the server configuration based on the primary backup data, and restoring the server configuration based on the secondary backup data if the recovery fails. This achieves redundant storage of configuration data, avoiding the risk of configuration loss due to single storage media failure or manual archiving omissions; during the recovery process, the primary and secondary backups are automatically determined based on the backup time information, and the system automatically switches to the secondary backup for recovery if the primary backup recovery fails, significantly improving the efficiency of configuration recovery.

Description

Technical Field

[0001] This application relates to the field of server technology, and in particular to server configuration backup and recovery methods and computing devices. Background Technology

[0002] During server maintenance, device configuration information (such as baseboard management controller (BMC) parameters, basic input / output system (BIOS) settings, electronic tags, and white-label documents) is critical data for ensuring normal server operation. Currently, these configurations are typically stored in the flash memory on the BMC card. When the server motherboard is shipped as a spare part, it often needs to be replaced along with the BMC card, resulting in the loss of all original server configuration information. This forces maintenance personnel or customers to undergo tedious manual configuration recovery work.

[0003] In existing technologies, to address configuration loss issues caused by motherboard replacement, the common practice is to archive customer-customized configurations on the company's technical support website. After replacing the motherboard, maintenance personnel then restore each configuration item by reviewing the archived Excel documents, manually executing IPMI (Intelligent Platform Management Interface) commands, importing XML (Extensible Markup Language) configuration files, or using specialized tools to write electronic tags. This manual recovery process is complex and results in low efficiency. Summary of the Invention

[0004] This application provides a server configuration backup and recovery method and computing device, which can improve the efficiency of configuration recovery, reduce manual operation and maintenance costs, and enhance the traceability of server configuration management.

[0005] According to a first aspect of the embodiments of this application, a server configuration backup and recovery method is provided, the method comprising:

[0006] Retrieve server configuration data; The configuration data is backed up to multiple storage media, which are non-volatile memory chips located on different components of the server; each storage media stores one copy of the configuration data and records the backup time information. In response to a configuration recovery command, backup data is read from multiple storage media respectively, and the primary backup data and at least one secondary backup data are determined based on time information; The system recovers data based on the configuration of the primary backup data server, and in the event of a recovery failure, it recovers data based on the configuration of the secondary backup data server.

[0007] This application embodiment achieves redundant storage of configuration data by backing up the complete server configuration data to multiple storage media, avoiding the risk of configuration loss due to single storage media failure or manual archiving omissions. During the recovery process, the primary and secondary backups are automatically determined based on the backup time information, and the system automatically switches to the secondary backup for recovery if the primary backup recovery fails, significantly improving the efficiency of configuration recovery. At the same time, multiple backup sources and the time information based on the storage media backups provide users with flexible point-in-time recovery options, reducing manual maintenance costs and improving the traceability of server configuration management.

[0008] In one possible implementation, the configuration data is backed up to multiple storage media, including: The configuration data is backed up to the preset fixed storage media in sequence according to the preset priority. When all preset fixed storage media are unavailable, search for available storage media from other components of the server and perform backups using the available storage media.

[0009] This embodiment prioritizes backups using storage media located on fixed components, leveraging the characteristics of these components being difficult to replace and offering high data security. When all fixed media become unavailable, a dynamic lookup mechanism searches for available storage space from other server components to complete the backup, avoiding backup failures due to fixed media failure or loss. This mitigates the risk of configuration loss in scenarios where a single backup source or a fixed backup source fails, providing multiple layers of protection for persistent server configuration storage.

[0010] In one possible implementation, the preset priority is positively correlated with the degree of physical fixation of the component where the storage medium is located; wherein, the storage medium located on the power supply backplane has a higher priority than the storage medium located on the fan plate, and the storage medium located on the fan plate has a higher priority than the storage medium located on the mounting ears.

[0011] This embodiment prioritizes writing configuration data to the components with the highest degree of physical fixation, making full use of the characteristics of these components that are not easy to disassemble or replace, thereby reducing the risk of configuration data loss due to component plugging or replacement.

[0012] In one possible implementation, locating available storage media includes: Traverse the storage media in the server and read the component description record field encoding of each storage media through the inter-integrated circuit bus; The read component description record field codes are matched with a pre-configured mapping table that contains component description record field codes that support backup. The matching storage media are identified as usable storage media.

[0013] This embodiment achieves automatic discovery and dynamic selection of available backup media by traversing all storage media in the server and matching them with a pre-configured mapping table based on CDR field codes. This method of identifying chip identity through CDR field codes avoids mistakenly using storage media that do not support backup functionality for backup operations, thus ensuring the security of data storage.

[0014] In one possible implementation, before obtaining the server's configuration data, the method further includes: The extended area of ​​the storage medium is divided into a header field and a data field. The header field is used to store backup flags, backup time information and checksums, while the data field is used to store configuration data.

[0015] This embodiment achieves separate storage and centralized management of backup metadata and configuration data by pre-dividing the header field and data field in the extended area of ​​the storage medium. The backup flag set in the header field enables the BMC to quickly scan and identify all valid backup media during recovery, without having to traverse the entire storage space, significantly improving search efficiency.

[0016] In one possible implementation, the configuration data is backed up to multiple storage media, including: The required storage blocks are determined based on the size of the configuration data. A storage block is a storage unit divided within the data domain. The configuration data is written sequentially to the corresponding storage blocks of multiple storage media.

[0017] This embodiment achieves reliable storage of configuration data by determining the required storage blocks based on the size of the configuration data and sequentially writing the configuration data into the corresponding storage blocks on multiple storage media. By calculating the required number of blocks, the BMC can manage storage space usage and avoid write failures due to insufficient data volume estimation.

[0018] In one possible implementation, backup data is read from multiple storage media respectively, and primary backup data and at least one secondary backup data are determined based on time information, including: The backup flag in each storage medium is read by hardware address to identify the storage medium storing backup data. Read the backup time information from the identified storage medium; Based on the read backup time information, all storage media containing backup data are sorted, and the most recent backup data is determined as the primary backup data, while the remaining backup data is determined as the secondary backup data.

[0019] This embodiment uses backup flags to quickly filter valid media, avoiding the traversal and reading of invalid storage space and significantly improving the startup efficiency of the recovery process. Furthermore, timestamp-based sorting ensures that the default recovery source always contains the latest configuration data, restoring the server to its state before replacement to the greatest extent possible. By distinguishing between primary and secondary backups, this embodiment provides a priority basis for subsequent anomaly handling.

[0020] In one possible implementation, the number of secondary backup data may include multiple; before restoring the server configuration based on the secondary backup data, the method further includes: In response to a backup selection command, the target backup data is determined from multiple backup data sets, and the server configuration is restored based on the target backup data.

[0021] This embodiment introduces backup selection commands and a user manual selection mechanism, providing users with flexible historical recovery point selection capabilities in scenarios with multiple backup data.

[0022] In one possible implementation, in the event of a recovery failure, the configuration of the recovery server based on the secondary backup data includes: When recovery based on primary backup data fails, a status code is recorded to identify hardware access errors or data integrity errors. Restore based on backup data and record recovery logs.

[0023] This embodiment introduces failure status codes, enabling the BMC to identify and record the reasons for failures. This provides a basis for subsequent recovery decisions and fault diagnosis, avoiding the efficiency loss caused by blind retries. Furthermore, when the primary backup data recovery fails, switching to the secondary backup ensures that configuration recovery is completed as much as possible, significantly improving the success rate of the recovery process.

[0024] In one possible implementation, the storage medium is configured to have a contiguous logical address space and support cross-chip data writing for compatible access to storage media of different capacities when writing configuration data.

[0025] The embodiments of this application can realize a unified access interface for storage media with different capacities. The BMC does not need to know the specific capacity of each chip, but only needs to perform read and write operations according to consecutive logical addresses; when the configuration data size exceeds the capacity of a single chip, the cross-chip write mechanism automatically handles address switching to ensure that the data can be stored completely.

[0026] According to a second aspect of the embodiments of this application, a server configuration backup and recovery apparatus is provided, the apparatus comprising: The configuration data acquisition module is used to acquire the server's configuration data; The data backup module is used to back up the configuration data to multiple storage media, which are non-volatile memory chips that are independently accessible and located on different components of the server; wherein each storage medium stores one copy of the configuration data and records the backup time information. The backup data reading module is used to read backup data from the plurality of storage media respectively in response to the configuration recovery command, and determine the primary backup data and at least one secondary backup data based on the time information; Configure the recovery module to recover the configuration of the primary backup data server and, in the event of recovery failure, recover the configuration of the secondary backup data server.

[0027] According to a third aspect of the embodiments of this application, a computing device is provided. The computing device includes a memory and a BMC, the memory storing a computer program, and the BMC executing the program to implement the method as described above.

[0028] According to a fourth aspect of the embodiments of this application, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a BMC, implements the methods described in the embodiments of this application.

[0029] According to a fifth aspect of the embodiments of this application, a computer program product is provided, including a computer program that, when executed by a BMC, implements the methods described above in the embodiments of this application. Attached Figure Description

[0030] More details, features, and advantages of embodiments of the present application are disclosed in the following description of exemplary embodiments in conjunction with the accompanying drawings, in which: Figure 1 A schematic diagram of the architecture of a server configuration backup and recovery system provided for an exemplary embodiment of this application; Figure 2 A flowchart illustrating a server configuration backup and recovery method provided in an exemplary embodiment of this application; Figure 3 for Figure 2 Flowchart of step S220; Figure 4 A schematic diagram of the storage structure of the storage medium provided in an exemplary embodiment of this application; Figure 5 for Figure 2 Another flowchart for step S220; Figure 6 for Figure 2Flowchart of step S230; Figure 7 for Figure 2 Flowchart of step S240; Figure 8 A schematic block diagram of the functional modules of a server configuration backup and recovery device provided in an exemplary embodiment of this application; Figure 9 A structural block diagram of a computing device provided for an exemplary embodiment of this application. Detailed Implementation

[0031] Embodiments of this application will now be described in more detail with reference to the accompanying drawings. While some embodiments of this application are shown in the drawings, it should be understood that embodiments of this application can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of the embodiments of this application. It should be understood that the accompanying drawings and embodiments of this application are for illustrative purposes only and are not intended to limit the scope of protection of this application.

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

[0033] The term "comprising" and its variations as used herein are open-ended, meaning "including but not limited to". The term "based on" means "at least partially based on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". Definitions of other terms will be given in the following description. It should be noted that the concepts of "first", "second", etc., mentioned in the embodiments of this application are only used to distinguish different devices, modules, or units, and are not used to limit the order of functions performed by these devices, modules, or units or their interdependencies.

[0034] It should be noted that the terms "one" and "more" mentioned in the embodiments of this application are illustrative rather than restrictive. Those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".

[0035] The names of the messages or information exchanged between multiple devices in the embodiments of this application are for illustrative purposes only and are not intended to limit the scope of these messages or information.

[0036] Figure 1 This is a schematic diagram of the server configuration backup and recovery system provided in the embodiments of this application. For example... Figure 1 As shown, the system is applied in server 10, including BCM11 and multiple storage media associated with different components of the server.

[0037] BCM11 is a management and control unit in server 10 that is independent of the main system. It is used to perform server configuration data acquisition, backup, and recovery operations. BCM11 is connected to multiple storage media on various components via I2C (inter-integrated circuit) to enable data read and write access.

[0038] Specifically, the plurality of storage media may include: The ear-mounted EEPROM (electrically erasable programmable read-only memory) 12 associated with the ear-mounted mounting bracket: The ear-mounted mounting bracket is a fixed component on the server chassis, and its mounted ear-mounted EEPROM 12 can be used to store server configuration data, such as a complete set of server configuration data.

[0039] Fan board EEPROM 13 associated with the fan board: The fan board is a fixed functional module inside the server 10. Its fan board EEPROM 13 can also be used to store server configuration data, such as a complete set of server configuration data.

[0040] EEPROM14 associated with the power board: The power board is the power supply module for server 10, and its power board EEPROM14 can also be used to store server configuration data, a complete set of server configuration data.

[0041] Other available EEPROM15: refers to other possible storage media in server 10 that can be used for backup, such as EEPROM on expansion cards, which are used to perform backups through a dynamic lookup mechanism when fixed storage media are unavailable.

[0042] The aforementioned mounting brackets, fan boards, and power supply boards are all components in server 10 with relatively fixed physical locations and are not frequently plugged in or removed. Therefore, the mounting bracket EEPROM 12, fan board EEPROM 13, and power supply board EEPROM 14 can be preferentially configured as fixed backup storage media. When these fixed storage media are unavailable, BCM 11 selects a suitable storage media from other available EEPROMs 15 for backup through a dynamic lookup mechanism.

[0043] During the backup process, BCM11 can obtain the complete configuration data of server 10 and write this complete configuration data to each of the multiple storage media, so that each storage media can independently store a complete copy of the server configuration data, and record the backup time information in each storage media. During the recovery process, BCM11 can read the backup data from the multiple storage media, determine the primary backup and secondary backup based on the backup time information, and attempt to restore the server configuration in sequence.

[0044] It should be noted that, in this embodiment, the BMC11 can establish communication connections with the storage media (such as the aforementioned EEPROMs) on various components of the server via I2C. Specifically, as the master control device, the BMC11 can connect multiple slave devices via the I2C bus, namely EEPROM chips on components such as mounting brackets, fan boards, and power supply boards, as well as other EEPROM chips available for backup.

[0045] Different motherboard designs may have different I2C link topologies. Therefore, this application embodiment uses a configuration file (such as an XML file) to adapt to different models: the configuration file can predefine the EEPROM chip objects connected to the I2C link of each model's motherboard, including information such as the chip's address, type, capacity, and affiliated component. During startup or initialization, the BMC11 reads this configuration file and dynamically adapts the list of accessible EEPROM chip objects according to the hardware topology of the current model.

[0046] During configuration backup, the BMC11, according to a preset backup strategy, initiates a write operation to the selected EEPROM chip via the I2C bus, writing the complete server configuration data to the designated storage area of ​​that chip. During configuration recovery, the BMC11 reads the previously backed-up configuration data from the selected EEPROM chip via the I2C bus and loads it into the corresponding module in server 10. Through this method, the BMC11 utilizes multiple I2C links to achieve flexible access to multiple EEPROM chips, completing the write and read-back operations of server configuration data.

[0047] Based on the above embodiments, this application also provides a server configuration backup and recovery method, which can be applied to the aforementioned BMC, such as... Figure 2 As shown, the method may include the following steps: In step S210, the server configuration data is obtained.

[0048] Specifically, the BMC responds to backup trigger conditions (such as timed triggers, configuration change triggers, or user-manual triggers) to obtain the server's current complete configuration data. This configuration data includes, but is not limited to: BMC configuration parameters, BIOS (basic input / output system) configuration information, version number information, motherboard electronic tag information, and white-label files, as well as other critical configuration information necessary for server operation.

[0049] In step S220, the configuration data is backed up to multiple storage media, which are non-volatile memory chips located on different components of the server. Each storage media stores one copy of the configuration data and records the backup time information.

[0050] Specifically, the BMC can write the acquired complete configuration data to multiple storage media (such as EEPROMs) via I2C. These multiple storage media are distributed across different components of the server, such as EEPROMs on fixed components like mounting brackets, fan boards, and power supply boards, as well as other available EEPROMs determined through a dynamic lookup mechanism.

[0051] Optionally, the storage medium can also be a non-volatile memory chip that can be accessed independently. For example, each EEPROM chip can be directly connected to the BMC via I2C, and the BMC can bypass the operating system and file system to directly perform independent read and write access to each EEPROM chip.

[0052] When writing configuration data, BMC can also record the time information (such as a timestamp) of this backup in a predetermined storage area (such as a header field) on each storage medium, so as to identify the age of the backup during subsequent recovery. In this way, each storage medium participating in the backup independently stores a complete copy of the server configuration data, realizing redundant storage of configuration data.

[0053] In this embodiment, since each EEPROM chip does not rely on a file system or operating system driver, the BMC can be accessed directly via the I2C bus using hardware addresses. Even if the server's main CPU is not running or the operating system crashes, the BMC can still independently complete read and write operations. Furthermore, because the EEPROM chips are located in different components (mount, fan board, power supply backplane, etc.), it avoids the loss of all backups due to a single physical location failure; it also prevents configuration loss caused by replacing the storage medium (such as the Flash on the BMC card) when replacing the motherboard.

[0054] In step S230, in response to the configuration recovery command, backup data is read from multiple storage media respectively, and primary backup data and at least one secondary backup data are determined based on time information.

[0055] In this embodiment, when the server needs to restore its configuration (e.g., upon first boot after motherboard replacement, or when a user manually triggers a restore), the BMC responds to the configuration restore command by traversing all storage media that may contain backup data. The BMC first reads the backup flag in each storage medium to identify the actual storage medium containing backup data; then, it reads the time information recorded during backup from the identified storage medium; finally, it sorts all storage media containing backup data according to the time information, determining the most recent backup data as the primary backup data and the remaining backup data as secondary backup data. In this way, the BMC can automatically identify available backup sources and establish a priority queue based on time.

[0056] In step S240, the configuration of the primary backup data recovery server is used, and if the recovery fails, the configuration of the secondary backup data recovery server is used.

[0057] In this embodiment, the BMC can first attempt to restore the server configuration using the primary backup data. If the restoration process completes successfully, the configuration restoration process ends. If restoration based on the primary backup data fails (e.g., due to data corruption, checksum errors, or media access failures), the BMC records a status code to identify the cause of failure and automatically switches to restoration based on the secondary backup data. During the switching process, the BMC records a restoration log, including the cause of failure, the switching action, and the final restoration result. If the secondary backup data restoration is successful, the server configuration is restored; if the secondary backup data restoration also fails, more backup attempts can be attempted or error messages can be displayed depending on the actual configuration. Through the above-mentioned exception handling mechanism, this embodiment can still ensure the success rate of configuration restoration even in the event of a single point of failure.

[0058] The server configuration backup and recovery method provided in this application backups server configuration data to multiple storage media, achieving redundant storage of configuration data and avoiding the risk of configuration loss due to single storage media failure or manual archiving omissions. During the recovery process, the primary and secondary backups are automatically determined based on backup time information, and the system automatically switches to the secondary backup for recovery if the primary backup recovery fails, significantly improving the reliability and success rate of configuration recovery. At the same time, multiple backup sources and the time information based on storage media backups provide users with flexible time point recovery options, reducing manual maintenance costs and improving the traceability of server configuration management.

[0059] Based on the above embodiments, in another embodiment provided in this application, such as Figure 3 As shown, step S220 above may specifically include the following steps: In step S221, configuration data is backed up to a preset fixed storage medium according to a preset priority. This fixed storage medium is a pre-adapted non-volatile storage medium located on a fixed component in the server that is not easily plugged in or removed.

[0060] Specifically, when backing up configuration data, BMC can first try using preset fixed storage media for backup. This fixed storage media refers to EEPROM chips pre-configured via configuration files (such as XML files), located in relatively fixed physical positions within the server and not frequently plugged in or out, such as EEPROMs on mounting brackets, fan boards, and power supply boards. BMC presets priorities for these fixed storage media based on factors such as the frequency of plugging and unplugging of each component and their availability; for example, setting the EEPROM on the least frequently replaced component as the highest priority.

[0061] For example, the EEPROM on the power supply backplane can be set to the highest priority because it is located at the innermost part of the server and is rarely involved in daily maintenance and plugging / unplugging; the EEPROM on the fan board is the next highest priority; and the EEPROM on the mounting ears, although not frequently removed, involves front panel maintenance, so its priority is relatively low.

[0062] During the backup process, the BMC can attempt to write configuration data to the fixed storage media in descending order of priority: first, it attempts to back up the highest priority fixed storage media. If the write is successful, the backup is complete; if the write fails (e.g., the component is not connected, the EEPROM is faulty, or communication is abnormal), it continues to attempt to back up the next lower priority fixed storage media, and so on, until the backup is successfully completed or all fixed storage media have been tried.

[0063] This embodiment utilizes storage chips on components that are not easily plugged in or removed. By leveraging the high physical stability of these components and their resistance to loss when the motherboard is replaced, the risk of configuration data loss due to component replacement or damage during plugging and unplugging can be reduced from the outset. Thus, even if the entire motherboard is replaced, the configuration data can still be stored in the storage chips of these components and can be directly read during recovery, avoiding configuration loss caused by motherboard replacement.

[0064] In one optional embodiment, the preset priority is positively correlated with the degree of physical fixation of the component where the storage medium is located; wherein, the storage medium located on the power backplane has a higher priority than the storage medium located on the fan plate, and the storage medium located on the fan plate has a higher priority than the storage medium located on the mounting ears.

[0065] Specifically, when backing up configuration data to fixed storage media, BMC does not randomly select or attempt backups in a fixed order. Instead, it sets backup priorities based on the physical stability of the components containing each storage medium. This physical stability refers to the component's secure installation within the server chassis, the frequency of disassembly during routine maintenance, and the probability of data loss or damage due to plugging, unplugging, or replacement. Higher physical stability indicates that the component is less likely to be disassembled or replaced, resulting in a lower risk of data loss on its storage medium; therefore, it should be given a higher backup priority.

[0066] In this embodiment, the components are arranged from highest to lowest physical fixation as follows: power supply backplate, fan plate, and mounting bracket. Wherein: The power supply backplane, located at the innermost part of the server chassis, typically connects the power supply module to the motherboard. It's not involved in routine maintenance and is rarely disassembled or replaced. Therefore, the EEPROM storage media on the power supply backplane has the highest degree of physical fixation and can be given the highest backup priority. When performing configuration backups, the BMC first attempts to write the configuration data to the storage chips on the power supply backplane.

[0067] The fan board, located inside the server, controls the cooling fans. It is removed infrequently, typically only replaced in case of fan failure or deep maintenance, and its physical fixation is less than that of the power supply backplane. Therefore, the EEPROM storage media on the fan board is given the second-highest priority. When power supply backplane backup fails (e.g., the component is not installed, the chip is damaged, or I2C communication is abnormal), the BMC will attempt to back up to the storage chip on the fan board.

[0068] Server mounting brackets are located on the front panel of the server and are commonly used to identify server models, asset tags, etc. During routine maintenance, these brackets may be touched during operations such as replacing front panel decorations or maintenance indicator lights, resulting in a higher frequency of removal than the power supply backplane and fan plate, but still far lower than hot-swappable components (such as hard drives and power modules). Therefore, the EEPROM storage media on the mounting brackets is given the lowest priority. When backups of the power supply backplane and fan plate fail, the BMC will attempt to write configuration data to the storage chip on the mounting brackets.

[0069] By prioritizing the data as described above, BMC selects the most stable and least likely to lose data during the backup process, thereby maximizing the security of configuration data.

[0070] It should be noted that this embodiment only uses the power supply backplane, fan plate, and mounting ears as examples and does not constitute a limitation on applicable components. Other server models may also include backplanes, midplanes, mounting brackets, and other components with a high degree of physical fixation. Their priority settings follow the principle that the higher the degree of physical fixation, the higher the priority. The specific configuration can be flexibly adapted according to the specific hardware topology.

[0071] This embodiment prioritizes writing configuration data to the components with the highest degree of physical fixation (such as the power supply backplane), making full use of the characteristics of these components that are not easy to disassemble or replace, thereby reducing the risk of configuration data loss due to component plugging or replacement.

[0072] In step S222, when all preset fixed storage media are unavailable, a usable storage media is searched from other components of the server, and a backup is performed using the usable storage media.

[0073] After confirming that all preset fixed storage media cannot be successfully written to, the BMC can use I2C to traverse all other EEPROM chips in the server besides the fixed storage media. These EEPROM chips may be located on expansion cards (such as RAID cards and network cards), adapter cards, backplanes, or even the storage modules of some cables. The BMC reads the CDR (component description record) encoding of these EEPROM chips. This encoding is the chip's hardware-fixed identification information, containing attributes such as manufacturer, device type, and capacity.

[0074] The BMC matches the read CDR code with a pre-configured mapping table. This table stores the codes of all EEPROM chips that support configuration backup functionality. If a match is found, it indicates that although the EEPROM chip is not in the preset list of fixed storage media, its hardware specifications and functions support writing configuration data to its extended area, thus making it usable as a backup medium. The BMC identifies the EEPROM chip as an "available storage medium" and performs the configuration data write operation, while simultaneously recording a backup flag, timestamp, and checksum in the chip's header field.

[0075] This embodiment prioritizes backup using storage media located on fixed components, fully leveraging the characteristics of these components—their difficulty in replacement and high data security. When all fixed media become unavailable, backup is completed by searching for available storage space from other server components, avoiding backup failure due to fixed media failure or loss. This mitigates the risk of configuration loss in scenarios where a single backup source or a fixed backup source fails, providing multiple layers of protection for the persistent storage of server configurations.

[0076] Based on the above embodiments, in another embodiment provided in this application, the search for available storage media in step S222 may specifically include: (1) Traverse the storage media in the server and read the component description record field encoding of each storage medium through the inter-integrated circuit bus.

[0077] In this embodiment, when the BMC determines that all fixed storage media are unavailable, it initiates a dynamic search process. The BMC initiates a traversal scan of all accessible EEPROM chips in the server via the Inter-Integrated Circuit Bus (I2C). During the traversal, the BMC sends a read command to each EEPROM chip to obtain the encoded information stored in its component CDR field. This CDR field is a predefined storage area in the EEPROM chip, used to record attribute information such as the chip's type, manufacturer, capacity, and whether it supports specific functions. By reading the CDR field encoding, the BMC can identify the identity and function of each EEPROM chip.

[0078] In this embodiment, the aforementioned traversal operation refers to the BMC sequentially scanning all possible device addresses on the I2C bus according to the I2C bus protocol, initiating a read request for each address to detect whether a responding device exists. For each responding device, the BMC further sends a read command to obtain the CDR field encoding stored internally.

[0079] Unlike ordinary storage media (such as hard drives, solid-state drives, or USB flash drives), which typically require a file system to access files or partition information and cannot directly obtain hardware-level unique identifier codes, the BMC in this embodiment can directly read the CDR field code of the EEPROM chip via the I2C bus without relying on a file system or driver.

[0080] In this way, BMC can proactively discover all accessible EEPROM chips in the server and obtain their hardware identity information without relying on upper-layer software, providing a basis for subsequent matching and availability judgment.

[0081] (2) Match the read component description record field code with a pre-configured mapping table that contains component description record field codes that support backup.

[0082] Specifically, the BMC maintains a pre-configured mapping table that stores the CDR field codes of all EEPROM chips that support backup functionality. This mapping table can be configured and updated in various ways, such as being pre-configured at the server's factory, updated via firmware upgrades, or dynamically added via management interfaces like IPMI. The mapping table supports multiple matching methods, including exact matching (e.g., codes are completely identical) and fuzzy matching (e.g., wildcard or range matching is supported), to accommodate differences in chip coding rules from different manufacturers. The BMC compares each CDR field code read in step (1) sequentially with the codes in the mapping table to determine whether the chip is included in the backup-supported list.

[0083] (3) The matching storage media is identified as usable storage media.

[0084] For any EEPROM chip that matches a code in the mapping table, the BMC can mark it as an "available storage medium" and add it to the target media list for this backup operation. Subsequently, the BMC writes the server's complete configuration data to the designated storage area of ​​that chip, completing the backup operation. For EEPROM chips that fail to match, the BMC skips that chip and continues traversing the next storage medium until a usable backup medium is found or all storage media have been traversed. If no usable storage medium is found after the traversal is complete, the BMC records a backup failure log and can issue an alarm or retry according to the configuration policy.

[0085] Through the above dynamic search mechanism, the embodiments of this application can automatically discover other storage spaces in the server that can be used for backup when all fixed backup media are unavailable, ensuring that the backup operation of configuration data can still be completed smoothly.

[0086] This embodiment achieves automatic discovery and dynamic selection of available backup media by traversing all storage media in the server and matching them with a pre-configured mapping table based on CDR field encoding. This method of identifying chip identity through CDR field encoding avoids mistakenly using storage media that do not support backup functionality for backup operations, ensuring data storage security. Furthermore, the mapping table supports fuzzy matching and dynamic updates, flexibly adapting to EEPROM chips from different manufacturers and models, improving the compatibility and scalability of the solution. When a fixed backup media becomes unavailable due to hardware failure, missing components, or communication anomalies, this dynamic search mechanism can automatically find available backup space from other server components, effectively avoiding backup failures caused by fixed media failure and enhancing the reliability of configuration backups.

[0087] In this embodiment, before obtaining the server's configuration data, the method can further divide the extended area of ​​the storage medium into a header field and a data field. The header field is used to store backup flags, backup time information, and checksums, while the data field is used to store configuration data.

[0088] Specifically, before server initialization or the first use of the storage medium, BMC plans the storage space for each EEPROM chip involved in configuration backup. Taking a typical 128KB EEPROM as an example, BMC reserves the first 16KB as a standard area (this area is usually used to store the component's own firmware or standard information), and divides the remaining 112KB space into an extended area architecture.

[0089] Within the extended area, BMC further divides it into two logical parts: the header field and the data field.

[0090] This header field marks the beginning of the extended region and occupies a small amount of storage space (such as a few bytes or KB) to store metadata related to backup operations. Specifically, it includes: Backup flag: Used to identify whether the storage medium has been configured for a backup. For example, a specific flag (such as "0x5A") can be set to indicate that a backup has been performed. The BMC can quickly identify a valid backup medium by reading this flag when searching for backup sources later.

[0091] Backup time information: Records the timestamp of this backup operation. The format can be a Unix timestamp or a custom date and time format. This time information is used to sort different backup sources by age during subsequent recovery, ensuring that the latest configuration can be selected for recovery.

[0092] Checksums include header field checksums and data field checksums. The header field checksum verifies the integrity of the metadata stored in the header field itself; the data field checksum performs cyclic redundancy checks (such as CRC32) on the complete configuration data stored in the data field. Before restoring the configuration, the BMC verifies the integrity of the data through checksums to avoid recovery failure due to data corruption.

[0093] The data field is the remaining storage space in the extended area excluding the header field. It is used to store the server configuration data itself, including but not limited to BMC configuration, BIOS configuration, version number information, motherboard electronic tags, white-label documents, etc. The size of the data field can be adjusted according to the actual amount of configuration data. If the extended space of a single EEPROM is insufficient to store the complete configuration, it can be achieved through multiple storage blocks or cross-chip writing.

[0094] Through the aforementioned spatial division, each EEPROM chip participating in the backup forms a standardized storage structure: the header domain centrally manages backup metadata, and the data domain centrally stores configuration content. This structural design provides a unified access interface and a reliable data foundation for subsequent backup writing, backup identification, data verification, and recovery reading.

[0095] This embodiment achieves separate storage and centralized management of backup metadata and configuration data by pre-dividing the header and data fields in the extended area of ​​the storage medium. The backup flag set in the header field enables the BMC to quickly scan and identify all valid backup media during recovery, without traversing the entire storage space, significantly improving search efficiency. Recording backup time information provides a reliable basis for sorting and prioritizing multiple backup sources, supporting users to restore configurations to any historical point in time. Furthermore, the introduction of checksums ensures the integrity of metadata and configuration data; the BMC can verify data integrity before reading backups, avoiding recovery failures due to data errors.

[0096] In one specific embodiment provided in this application, such as Figure 4 As shown, Figure 4 This is a schematic diagram of the storage structure of the storage medium (EEPROM) provided in the embodiments of this application.

[0097] like Figure 4 As shown in the illustration, this application uses a 1Mbit (i.e., 128KB) EEPROM chip as an example to demonstrate its specific storage structure after the extended region is partitioned. This storage structure includes two parts: a standard region and an extended region. 1) Standard area.

[0098] In this embodiment, the first 16KB of the EEPROM can be reserved as a standard area for storing the original basic information of the component. For example... Figure 4 As shown, this area specifically includes: Ear loop electronic tag: Stores electronic tag information of ear loop components, used to identify the component's identity and attributes.

[0099] This standard area follows the original data storage specifications of the component, and this application embodiment does not modify or occupy it to ensure compatibility with the original hardware design.

[0100] 2) Extended area.

[0101] The remaining 112KB of EEPROM space is allocated as an extended area to implement the configuration backup function of this embodiment. Optionally, the extended area can be further divided into a header field and a body field. (1) Head field.

[0102] The header field, located at the beginning of the extended area, stores metadata related to backup operations. In one possible implementation, this header may specifically include: Backup status flag: This flag indicates whether the EEPROM has been configured for backup. The BMC uses this flag to quickly identify valid backup media when searching for backup sources.

[0103] EEPROM Version: Records the version information of the EEPROM chip itself.

[0104] Last backup time: Records the timestamp of this backup operation, which is used to sort different backup sources by age during subsequent recovery.

[0105] Backup repository serial number (backup repository SN): A unique identifier assigned to each backup repository to distinguish different backup copies.

[0106] Header checksum: Cyclic redundancy check (such as CRC32) is performed on the metadata stored in the header field. When reading header information, BMC verifies the integrity of the metadata by checking the checksum.

[0107] Data domain checksum: Verifies the complete configuration data stored in the data domain. Before restoring the configuration, BMC uses this checksum to verify the integrity of the configuration data to avoid recovery failure due to data corruption.

[0108] (2) Data field (Body).

[0109] The data domain is the remaining storage space in the extended region excluding the header domain, used to store the server's complete configuration data. For example... Figure 4 As shown, optionally, the data domain includes the following configuration information: Motherboard electronic tag: refers to a set of unique identification information and product attribute data stored in the server motherboard or related components (such as mounting brackets, EEPROM), used to identify the identity, specifications, production information and customized configuration of the server motherboard.

[0110] BMC non-file-based configuration information includes: factory-customized items (configuration type), such as factory-preset information like the motherboard electronic tag; customer-configured items, which are modified by the customer during use; and BIOS configuration information, which stores the complete configuration parameters of the BIOS.

[0111] Version information: including key firmware version information such as BMC version, BIOS version, and CPLD (complex programmable logic device) version.

[0112] White-label files: Personalized files such as images and logos used for customized models to meet the brand customization needs of different customers.

[0113] Through the above storage structure design, each EEPROM chip participating in backup forms a standardized storage layout. The header domain centrally manages backup metadata, while the data domain centrally stores configuration content. This structure provides a unified access interface for the BMC to perform backup writing, backup identification, data verification, and recovery reading.

[0114] Figure 4The storage structure design shown divides the EEPROM extended area into a header field and a data field, achieving separate storage and centralized management of backup metadata and configuration data. The backup flag and time information set in the header field enable the BMC to quickly scan and identify all valid backup media and sort them based on timestamps. The introduction of checksums ensures the integrity of metadata and configuration data, avoiding recovery failures due to data corruption. The data field stores various types of configuration information (BMC configuration, BIOS configuration, version information, white-label files, etc.) for easy on-demand reading and recovery.

[0115] Based on the above embodiments, in another embodiment provided in this application, such as Figure 5 As shown, step S220 above may specifically include the following steps: Step S223: Determine the required storage block based on the size of the configuration data. The storage block is a storage unit divided in the data domain.

[0116] Specifically, after obtaining the server's complete configuration data, BMC first calculates the total size of that configuration data. Since the configuration complexity varies between different servers, the size of the configuration data may differ (e.g., from tens of KB to hundreds of KB). Based on the calculated configuration data size and the storage unit partitioning rules of the data domain in the storage medium (such as EEPROM), BMC determines the number of storage blocks required for this backup operation.

[0117] by Figure 4 Taking the EEPROM storage structure shown as an example, the data field (Body) is divided into multiple fixed-size storage blocks (e.g., each block is 64KB). If the configuration data size is 150KB, the BMC calculates that three storage blocks are needed to completely store the configuration data (the first two blocks each store 64KB, and the third block stores the remaining 22KB). If the data field adopts a variable block size design, the BMC dynamically determines the block division method according to the configuration data size, ensuring that each block can completely store a portion of the configuration data and that the addresses between blocks are contiguous.

[0118] Optionally, the partitioning of storage blocks in the embodiments may follow one or more of the following principles: Block size can be fixed or variable: It can be flexibly determined according to the characteristics of EEPROM hardware and system design, such as using a fixed 64KB block or dynamically adjusting it according to actual needs.

[0119] Address contiguousness: Multiple storage blocks within the same storage medium have consecutive logical addresses, ensuring that the BMC can write data sequentially by incrementing the address.

[0120] Cross-block addressing: When the configuration data size exceeds the capacity of a single block, BMC can automatically identify the end address of the current block and switch to the start address of the next block to continue writing, achieving seamless data storage.

[0121] Step S224: Write the configuration data sequentially into the storage blocks corresponding to the multiple storage media.

[0122] In this embodiment, for multiple target storage media (including fixed storage media and dynamically searchable available storage media), BMC performs block write operations independently for each storage media.

[0123] Taking the writing of 150KB of configuration data to a target EEPROM as an example, the BMC can perform the following operations: (1) Locating the starting block: The BMC determines the location of the first storage block based on the starting address of the EEPROM data field.

[0124] (2) Block writing: BMC writes the first 64KB of configuration data to the first storage block; after writing, it automatically calculates the starting address of the next block and writes the next 64KB to the second storage block; finally, it writes the remaining 22KB to the third storage block.

[0125] (3) Address switching process: During the writing process, BMC monitors in real time whether the current writing position has reached the block boundary. If the boundary is reached and the data has not been written, BMC automatically switches to the starting address of the next block to continue writing, ensuring that the data is stored continuously without being overwritten or misaligned.

[0126] (4) Repeat execution: After completing the writing of the current storage medium, the BMC repeats the above block writing process and processes the next target storage medium in turn until all selected storage media have been successfully written with complete configuration data.

[0127] For storage media of different capacities, the BMC employs a unified block partitioning and writing mechanism: if the target EEPROM capacity is small (e.g., 64KB), its data field may contain only one storage block. The BMC writes a portion of the configuration data into this block, but must ensure that the amount of data written does not exceed the total capacity of the medium; if the target EEPROM capacity is large (e.g., 256KB), its data field contains multiple storage blocks, and the BMC can flexibly use some or all of these blocks according to the size of the configuration data. Through this unified block-based writing method, the embodiments of this application achieve compatible access to storage media of different capacities.

[0128] After each write operation is completed, BMC can also record backup time information in the header field of each storage medium and update the data field checksum to ensure the integrity and traceability of the backup data.

[0129] This embodiment achieves reliable storage of configuration data by determining the required storage blocks based on the configuration data size and sequentially writing the configuration data to the corresponding storage blocks on multiple storage media. By calculating the required number of blocks, the BMC can manage storage space usage and avoid write failures due to insufficient data volume estimation. Furthermore, the design of address contiguousness and cross-block addressing ensures that large amounts of configuration data can be seamlessly written to a single storage medium, unrestricted by block boundaries. The unified block-based write mechanism is applicable to storage media of different capacities, enabling compatibility with various hardware specifications. Moreover, by independently performing block-based writes on each target storage medium, data consistency among multiple backup copies is guaranteed.

[0130] Based on the above embodiments, in another embodiment provided in this application, such as Figure 6 As shown, step S230 above may specifically include the following steps: In step S231, the backup flag in each storage medium is read by the hardware address to identify the storage medium storing backup data.

[0131] In this embodiment, when the BMC initiates the recovery process in response to a configuration recovery command, it first needs to determine which available backup sources exist in the current server. The BMC can traverse all possible storage media involved in the backup via I2C (such as EEPROMs on mounting brackets, fan boards, power boards, and other available EEPROMs determined by dynamic lookup mechanisms), and read the header field of each storage medium (e.g., ...) via hardware address. Figure 4 The backup flag is stored in the Head area shown.

[0132] The backup flag is specific identification data pre-written during the backup process, such as a fixed byte value (e.g., "0x5A") or a specific combination of flag bits. The BMC quickly identifies whether a storage medium contains valid backup data by reading this flag and determining if its value matches a preset "backed up" rule. If the backup flag is absent or its value does not match the preset rule, the BMC determines that the storage medium does not store backup data and skips that medium, continuing to the next one.

[0133] Specifically, the BMC maintains hardware address information for each storage medium (i.e., EEPROM chips distributed across different components of the server), such as device addresses on the I2C bus. The BMC does not rely on any file system, path, or filename; instead, it directly sends read commands to these hardware addresses via the I2C bus to access predefined offset positions in the header field of each storage medium (e.g., ...). Figure 4The "Backup Flag" field shown is an example of this. This backup flag is a specific value (e.g., a fixed byte 0x5A) written by the BMC during the backup process to indicate that the storage medium has completed the backup of its configuration data.

[0134] The BMC sequentially traverses all known hardware addresses (including fixed storage media and dynamically discovered storage media), reading the backup flag of the chip corresponding to each address. If the read value matches the preset backup flag value, the storage media is determined to contain valid backup data; if the flag does not exist (e.g., a value of 0xFF) or does not match, the media is determined to be unused or invalid, and the media is skipped. Through this process, the BMC can quickly filter out all actually usable backup sources.

[0135] Compared to ordinary storage media (such as solid-state drives or USB flash drives), this embodiment uses a method of directly reading the backup flag using hardware addresses, which can directly access hardware registers or fixed physical addresses without the need for file system support.

[0136] In this way, BMC can quickly filter out all media that actually store backup data from a large number of storage media, filtering out unused or invalid storage space, laying the foundation for subsequent reading and sorting.

[0137] In step S232, the backup time information is read from the identified storage medium.

[0138] In this embodiment, for each storage medium containing backup data identified in step S231, the BMC further reads the time information recorded during backup from its header field. For example... Figure 4 As shown, this time information is stored in the "Last Backup Time" field, and the format can be a Unix timestamp (such as the number of seconds from January 1, 1970 to the backup time) or a custom date and time format (such as "2025-03-12 14:30:00").

[0139] BMC sequentially reads the time information from the header field of each valid backup medium and associates it with the corresponding storage medium identifier (such as I2C address, device path, etc.) for later sorting. If an error occurs during the time information reading process (such as a checksum failure), BMC can decide whether to mark the backup medium as invalid or attempt to read it again according to a preset policy.

[0140] In step S233, all storage media containing backup data are sorted according to the read backup time information, and the backup data with the latest time is determined as the primary backup data, and the remaining backup data is determined as the secondary backup data.

[0141] Specifically, after obtaining all valid backup media and their corresponding time information, BMC performs a sorting operation. The sorting rule can be to arrange them in ascending order of time, that is, the backup media with the larger timestamp (indicating a later backup time) are listed first.

[0142] After sorting, BMC will determine the first (most recent) backup as the primary backup and use it as the first target source for recovery. The remaining backups will be determined in chronological order as secondary backups (such as the second newest backup, the third newest backup, etc.) and used as alternative recovery sources in case the primary backup recovery fails.

[0143] For example, suppose BMC identifies three valid backup media with backup times of "2025-03-12 10:00:00" (storage media A), "2025-03-12 14:00:00" (storage media B), and "2025-03-11 09:00:00" (storage media C). After sorting, media B (the most recent) is determined as the primary backup data, while media A and media C are determined as the first and second backup data, respectively.

[0144] The BMC can store the sorting results in memory and attempt to restore them sequentially according to this order in subsequent step S240. Furthermore, in some embodiments, the BMC can also push the sorted list of backup media and their time information to the front-end interface for display, allowing the user to manually select the desired restoration point in time. In this way, the embodiments of this application support both automatic selection of the latest backup for restoration and the flexibility of users manually selecting historical time points.

[0145] This embodiment uses backup flags to quickly filter valid media, avoiding the traversal and reading of invalid storage space and significantly improving the startup efficiency of the recovery process. Furthermore, timestamp-based sorting ensures that the default recovery source always contains the latest configuration data, restoring the server to its state before replacement to the greatest extent possible. By distinguishing between primary and secondary backups, this embodiment provides a priority basis for subsequent anomaly handling.

[0146] In this embodiment, the number of secondary backup data may include multiple data sets. Before restoring the server configuration based on the secondary backup data, the method may also, in response to a backup selection instruction, determine the target backup data from the multiple secondary backup data sets and restore the server configuration based on the target backup data.

[0147] In this embodiment, the BMC can sort all storage media containing backup data based on the backup time information. In addition to determining the most recent primary backup data, it will also obtain multiple secondary backup data arranged in chronological order (such as the second newest backup, the third newest backup, etc.). These secondary backup data correspond to the server configuration status at different points in time, providing users with flexible historical recovery options.

[0148] Specifically, when recovery based on the primary backup fails, the BMC may not immediately and automatically attempt to retry the most recent secondary backup. Instead, it can enter a mode that waits for user selection, based on preset policies or user configuration. Specific implementation methods include: (1) User selection trigger.

[0149] BMC pushes the sorted list of backup media and their corresponding backup time information to a front-end (e.g., terminal) management interface (e.g., Web UI or command-line interface) connected to the server for visual display. The displayed content includes, but is not limited to: Each backup media is identified (e.g., EEPROM with mounting ear, EEPROM with fan board, etc.). Backup timestamp (e.g., "2025-03-12 14:30:00"); Backup status (e.g., "Primary Backup", "Secondary Backup 1", "Secondary Backup 2", etc.); Other metadata (such as checksum status, media health, etc.).

[0150] After viewing the above information through the front-end interface, users can manually select a backup point in time they wish to restore based on their needs and trigger the backup selection command. For example, a user may want to restore to the configuration state before yesterday's changes, rather than the latest configuration state; or a user may know that the latest backup data may be corrupted, so they choose to restore the backup from the previous point in time.

[0151] Optionally, in some embodiments, the BMC may also support triggering backup selection commands in other ways, such as: Command line interface: Administrators can send recovery commands specifying backup timestamps via management protocols such as IPMI or Redfish; Script automation: The operation and maintenance script automatically calculates the target backup time point and triggers the recovery based on preset rules (such as "restore to the configuration at yesterday morning"); Default policy: If the user does not make a selection within the preset time, BMC can revert to the default policy (such as automatically trying the most recent backup data).

[0152] Through the above mechanism, when there are multiple backup data, users can flexibly choose the historical configuration time point they want to restore according to their actual needs, instead of passively accepting the backup source automatically selected by the system.

[0153] (2) BMC response and execution.

[0154] After receiving a backup selection command from the user via the front-end interface, the BMC parses the target backup media identifier (such as I2C address or device path) contained in the command. Subsequently, the BMC reads the complete configuration data stored in the target backup media and performs server configuration recovery operations based on this data. During the recovery process, the BMC also performs data integrity checks (such as verifying data field checksums) to ensure the reliability of the recovered data.

[0155] In some embodiments, the user's manual selection mechanism described above can work in conjunction with the exception handling process in step S240. For example: BMC will first attempt to restore based on the primary backup data; if that fails, it will enter user selection mode. Users can select target backup data from multiple backup data sets; BMC restores based on the target backup data selected by the user; If the backup data selected by the user also fails to be restored, BMC can prompt the user to select another backup data, or automatically try the most recent backup data; If all recovery attempts fail, the BMC logs detailed failure information and issues an alert.

[0156] This collaborative mechanism retains the efficiency of automatic recovery while also allowing for the flexibility of manual intervention by the user.

[0157] This embodiment introduces backup selection commands and a user manual selection mechanism, providing users with flexible historical recovery point selection capabilities in scenarios with multiple backup data.

[0158] Based on the above embodiments, in another embodiment provided in this application, to illustrate in detail how to restore the server configuration based on the secondary backup data in the event of a recovery failure, as follows: Figure 7 As shown, step S240 above may specifically include the following steps: In step S241, when recovery based on primary backup data fails, a status code is recorded to identify hardware access error or data integrity error.

[0159] Specifically, when executing step S240, the BMC can prioritize attempting configuration recovery using the primary backup data determined in step S233. During the recovery process, the BMC may fail to recover for various reasons, such as: Data integrity error: After reading the primary backup data, the BMC calculates its data field checksum, which does not match the data field checksum stored in the header field, indicating that the configuration data is corrupted; Media access failure: A communication timeout or bus error occurred when the BMC accessed the storage media where the primary backup was located via the I2C bus, and it was unable to read complete data; Data format error: The configuration data being read is not in the expected format and cannot be parsed or loaded into the corresponding module on the server; Address error: The logical address space of the storage medium is not contiguous or the address switching fails when writing across chips, resulting in incomplete data reading; Hardware failure: The storage medium where the primary backup is located has suffered physical damage and is unable to respond to read and write commands normally.

[0160] In this embodiment, when the BMC fails to restore the server configuration based on the primary backup data, the embodiment does not simply abandon or blindly switch to the secondary backup. Instead, it first records a status code to identify the cause of the failure. This status code can distinguish different fault types such as hardware access errors or data integrity errors.

[0161] Specifically, during the configuration recovery process, the BMC performs a series of hardware-level read and verification operations on the storage medium (non-volatile storage chip, such as EEPROM) where the primary backup data resides. If an exception occurs during the operation, the BMC will generate a corresponding predefined status code based on the exception type. Hardware access error status codes: For example, when the BMC sends a read command to the memory chip via the I2C bus and does not receive a response (device no response), experiences a communication timeout, a bus collision, or receives invalid data, the BMC determines it as a hardware access error and records the corresponding status code (e.g., 0xE1 indicates I2C communication timeout, 0xE2 indicates no device response, and 0xE3 indicates a bus collision). These types of errors are usually related to the physical connection of the memory chip, damage to the chip itself, or unstable power supply.

[0162] Data integrity error status codes: When the BMC successfully reads configuration data, but finds inconsistencies through checksum verification (such as header field checksum or data field CRC32 checksum), a data integrity error is determined, and the corresponding status code is recorded (e.g., 0xD1 indicates a header checksum error, 0xD2 indicates a data field checksum error, and 0xD3 indicates an abnormal configuration data format). These types of errors are usually caused by bit flips in the memory chip, unexpected interruptions during the write process, or chip aging.

[0163] The BMC records this status code in the system's log storage area (such as the BMC's local non-volatile storage or a shared log partition), and associates it with information such as the time of the failure and the media identifier of the primary backup. This status code is not only used for subsequent recovery decisions, but also provides maintenance personnel with a basis for quickly locating the root cause of the problem. For example, when the status code displays "Data checksum error," maintenance personnel can determine that the primary backup data is corrupted and there is no need to repeat the attempt; when the status code displays "I2C communication timeout," it may indicate a hardware connection problem in the component where the storage media is located.

[0164] The implementation uses status codes to accurately distinguish between hardware access layer errors (such as I2C communication timeouts or no device response) and data integrity layer errors (such as checksum mismatches). This allows the BMC to adopt differentiated recovery strategies based on the error type. For example, for communication errors, it can directly switch the backup source; for checksum errors, it can attempt to reread or correct the error, avoiding the time wasted by blind retries. Furthermore, the status code recording provides a clear trigger for automatic switching to the secondary backup. Switching is only initiated when the primary backup is confirmed to be unrecoverable (such as hardware failure or permanent data corruption), preventing the erroneous abandonment of a valid backup due to momentary communication interference. In addition, status codes can be combined with recovery logs to provide maintenance personnel with more accurate fault diagnosis information, enabling them to quickly locate the root cause of configuration recovery failures (such as damage to a storage chip or bus connection problems), thereby shortening troubleshooting time.

[0165] In step S242, recovery is performed based on the backup data, and a recovery log is recorded.

[0166] Specifically, after recording the failure status code, the BMC triggers the switchover and recovery process based on the secondary backup data list determined in step S233. The BMC attempts to recover the data sequentially according to the priority order of the secondary backup data (usually the second newest data takes precedence): (1) Selecting a secondary backup: BMC selects the one with the highest priority (i.e. the secondary backup data whose time is closest to the primary backup) from the secondary backup data list as the current recovery source.

[0167] (2) Reading data: BMC reads the complete configuration data from the storage medium where the backup is located via the I2C bus and verifies its data field checksum to ensure data integrity.

[0168] (3) Perform recovery: If the data integrity verification passes, BMC will load the read configuration data into the corresponding module of the server to complete the configuration recovery operation.

[0169] (4) Successful processing: If the recovery is successful, the BMC records the recovery log, including: the switching action identifier ("Switched to the secondary backup"), the secondary backup media identifier, the recovery completion time, the final recovery result ("Success"), and other information.

[0170] (5) Retry on failure: If the current backup recovery also fails (for example, there is data corruption or access failure), the BMC will record the corresponding failure status code again and automatically try the next backup data until the recovery is successful or all backups have been tried.

[0171] (6) Final failure handling: If all backups fail to recover, the BMC records the final failure log, including all backup media that were tried and their corresponding failure status codes, and can trigger an alarm to notify the operation and maintenance personnel to intervene.

[0172] The recovery log contains, but is not limited to: Recovery process start time; Primary backup recovery failure time and failure status code; Switch to the trigger time of the secondary backup; Each backup attempt includes the media identifier, timestamp, recovery result (success / failure), and failure status code. Final recovery result (success or failure); Recovery process completion time.

[0173] Recovery logs can be stored in the BMC's local log system and can be queried and exported by operations and maintenance personnel through management interfaces (such as IPMI, Redfish, and WebUI). Detailed log records allow operations and maintenance personnel to fully trace the entire recovery process, understand the reasons for failure, the switchover path, and the final result, providing a basis for subsequent troubleshooting and system optimization.

[0174] In some embodiments, after a successful recovery, BMC may also push the detailed recovery logs and failure status codes to the front-end interface for display, or proactively send alarm notifications when a serious failure occurs, to ensure that maintenance personnel can be informed of the recovery status in a timely manner and take appropriate measures.

[0175] This embodiment introduces failure status codes, enabling the BMC to identify and record the reasons for failures. This provides a basis for subsequent recovery decisions and fault diagnosis, avoiding the efficiency loss caused by blind retries. Furthermore, when the primary backup data recovery fails, switching to the secondary backup ensures that configuration recovery is completed as much as possible, significantly improving the success rate of the recovery process.

[0176] It should be noted that the storage medium in the embodiment can be configured to have a continuous logical address space and support cross-chip data writing, for compatibility access to storage media of different capacities when writing the configuration data.

[0177] To achieve compatibility support for EEPROM chips of different capacities, this application embodiment sets unified hardware configuration requirements for the storage media involved in backup. This contiguous logical address space means that regardless of the physical storage medium organization of the EEPROM chip, the address space presented when accessed by the BMC is continuous. For example, for a 128KB EEPROM, its logical address range is 0x0000 to 0x1FFFF; if the server simultaneously contains 64KB and 256KB EEPROMs, they present contiguous logical address spaces of 0x0000 to 0x0FFFF and 0x0000 to 0x3FFFF, respectively. This contiguous address design ensures that the BMC, during read and write operations, does not need to concern itself with the internal physical storage structure of the chip, but only needs to access it in ascending address order.

[0178] Cross-chip data writing in this embodiment refers to the BMC's ability to automatically perform write operations across chip boundaries when the storage space of a single storage medium is insufficient to hold the complete configuration data. For example, in some server designs, a logical storage unit may consist of multiple physical EEPROM chips (e.g., through address cascading). When writing configuration data, the BMC first writes data to the first chip until its address space is exhausted, and then automatically switches to the starting address of the next chip to continue writing, achieving seamless data storage across chips. This mechanism allows multiple small-capacity chips to be combined, equivalent to a large-capacity storage space.

[0179] With the hardware configuration described above, this embodiment of the application can achieve a unified access interface for storage media of different capacities. The BMC does not need to be aware of the specific capacity of each chip, but only needs to perform read and write operations according to consecutive logical addresses; when the configured data size exceeds the capacity of a single chip, the cross-chip write mechanism automatically handles address switching to ensure that the data can be stored completely.

[0180] By dividing each functional module according to its corresponding function, this application provides a server configuration backup and recovery device, which can be a server or a chip applied to a server. Figure 8 This is a schematic block diagram illustrating the functional modules of a server configuration backup and recovery device provided for an exemplary embodiment of this application. Figure 8 As shown, the server is configured with backup and recovery devices including: Configuration data acquisition module 81 is used to acquire server configuration data; The data backup module 82 is used to back up the configuration data to multiple storage media, which are non-volatile storage chips installed on different components of the server; each storage medium stores one copy of the configuration data and records the backup time information. The backup data reading module 83 is used to read backup data from multiple storage media in response to a configuration recovery command, and to determine the primary backup data and at least one secondary backup data based on time information. The configuration recovery module 84 is used to recover the configuration of the primary backup data server and, in the event of recovery failure, to recover the configuration of the secondary backup data server.

[0181] This application embodiment achieves redundant storage of configuration data by backing up the complete configuration data of the server to multiple storage media, avoiding the risk of configuration loss due to single storage media failure or manual archiving omissions; during the recovery process, the primary and secondary backups are automatically determined based on the backup time information, and the recovery is automatically switched to the secondary backup when the primary backup recovery fails, which significantly improves the efficiency of configuration recovery.

[0182] In another embodiment provided in this application, the data backup module 82 is specifically used for: The configuration data is backed up to the preset fixed storage media in sequence according to the preset priority. When all preset fixed storage media are unavailable, search for available storage media from other components of the server and perform backups using the available storage media.

[0183] This embodiment prioritizes backups using storage media located on fixed components, leveraging the characteristics of these components being difficult to replace and offering high data security. When all fixed media become unavailable, a dynamic lookup mechanism searches for available storage space from other server components to complete the backup, avoiding backup failures due to fixed media failure or loss. This mitigates the risk of configuration loss in scenarios where a single backup source or a fixed backup source fails, providing multiple layers of protection for persistent server configuration storage.

[0184] In another embodiment provided in this application, the preset priority is positively correlated with the degree of physical fixation of the component where the storage medium is located; wherein, the storage medium located on the power supply backplane has a higher priority than the storage medium located on the fan plate, and the storage medium located on the fan plate has a higher priority than the storage medium located on the mounting ears.

[0185] This embodiment prioritizes writing configuration data to the components with the highest degree of physical fixation, making full use of the characteristics of these components that are not easy to disassemble or replace, thereby reducing the risk of configuration data loss due to component plugging or replacement.

[0186] In another embodiment provided in this application, the data backup module 82 is further configured to: Traverse the storage media in the server and read the component description record field encoding of each storage media through the inter-integrated circuit bus; The read component description record field codes are matched with a pre-configured mapping table that contains component description record field codes that support backup. The matching storage media are identified as usable storage media.

[0187] This embodiment achieves automatic discovery and dynamic selection of available backup media by traversing all storage media in the server and matching them with a pre-configured mapping table based on CDR field codes. This method of identifying chip identity through CDR field codes avoids mistakenly using storage media that do not support backup functionality for backup operations, thus ensuring the security of data storage.

[0188] In another embodiment provided in this application, the device further includes a region division module, specifically used for: The extended area of ​​the storage medium is divided into a header field and a data field. The header field is used to store backup flags, backup time information and checksums, while the data field is used to store configuration data.

[0189] This embodiment achieves separate storage and centralized management of backup metadata and configuration data by pre-dividing the header field and data field in the extended area of ​​the storage medium. The backup flag set in the header field enables the BMC to quickly scan and identify all valid backup media during recovery, without having to traverse the entire storage space, significantly improving search efficiency.

[0190] In another embodiment provided in this application, the data backup module 82 is specifically used for: The required storage blocks are determined based on the size of the configuration data. A storage block is a storage unit divided within the data domain. The configuration data is written sequentially to the corresponding storage blocks of multiple storage media.

[0191] This embodiment achieves reliable storage of configuration data by determining the required storage blocks based on the size of the configuration data and sequentially writing the configuration data into the corresponding storage blocks on multiple storage media. By calculating the required number of blocks, the BMC can manage storage space usage and avoid write failures due to insufficient data volume estimation.

[0192] In another embodiment provided in this application, the backup data reading module 83 is specifically used for: The backup flag in each storage medium is read by hardware address to identify the storage medium storing backup data. Read the backup time information from the identified storage medium; Based on the read backup time information, all storage media containing backup data are sorted, and the most recent backup data is determined as the primary backup data, while the remaining backup data is determined as the secondary backup data.

[0193] This embodiment uses backup flags to quickly filter valid media, avoiding the traversal and reading of invalid storage space and significantly improving the startup efficiency of the recovery process. Furthermore, timestamp-based sorting ensures that the default recovery source always contains the latest configuration data, restoring the server to its state before replacement to the greatest extent possible. By distinguishing between primary and secondary backups, this embodiment provides a priority basis for subsequent anomaly handling.

[0194] In another embodiment provided in this application, the number of secondary backup data includes multiple data sets, and the device further includes a configuration module, specifically used for: In response to a backup selection command, the target backup data is determined from multiple backup data sets, and the server configuration is restored based on the target backup data.

[0195] This embodiment introduces backup selection commands and a user manual selection mechanism, providing users with flexible historical recovery point selection capabilities in scenarios with multiple backup data.

[0196] In another embodiment provided in this application, when recovery fails, the recovery module 84 is configured to: When recovery based on primary backup data fails, a status code is recorded to identify hardware access errors or data integrity errors. Restore based on backup data and record recovery logs.

[0197] This embodiment introduces failure status codes, enabling the BMC to identify and record the reasons for failures. This provides a basis for subsequent recovery decisions and fault diagnosis, avoiding the efficiency loss caused by blind retries. Furthermore, when the primary backup data recovery fails, switching to the secondary backup ensures that configuration recovery is completed as much as possible, significantly improving the success rate of the recovery process.

[0198] In another embodiment provided in this application, the storage medium is configured to have a contiguous logical address space and support cross-chip data writing for compatible access to storage media of different capacities when writing configuration data.

[0199] The embodiments of this application can realize a unified access interface for storage media with different capacities. The BMC does not need to know the specific capacity of each chip, but only needs to perform read and write operations according to consecutive logical addresses; when the configuration data size exceeds the capacity of a single chip, the cross-chip write mechanism automatically handles address switching to ensure that the data can be stored completely.

[0200] This application also provides a computing device, such as... Figure 9 As shown, Figure 9 This is a schematic diagram of the structure of a computing device provided in an embodiment of this application. The computing device can specifically be the server mentioned above, including BMC1901, communication interface 1902, memory 1903 and communication bus 1904, wherein BMC1901, communication interface 1902 and memory 1903 communicate with each other through communication bus 1904.

[0201] Memory 1903 is used to store computer programs; BMC1901 is used to implement the above-described method provided in the embodiments of this application when executing the program stored in memory 1903.

[0202] The communication bus mentioned in the computing device above can be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not mean that there is only one bus or one type of bus.

[0203] The communication interface is used for communication between the aforementioned computing device and other devices.

[0204] The memory may include random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device.

[0205] In another embodiment provided in this application, a computer-readable storage medium is also provided, which stores a computer program that, when executed by the BMC, implements the methods described above in the embodiments of this application.

[0206] In another embodiment provided in this application, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to execute the methods described above in the embodiments of this application.

[0207] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially as a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid state disk (SSD)).

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

[0209] The various embodiments in this specification are described in a related manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the embodiments of apparatus, computing devices, and computer-readable storage media are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0210] The above description is merely a preferred embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application are included within the scope of protection of this application.

Claims

1. A server configuration recovery method, characterized in that, The method includes: Retrieve server configuration data; The configuration data is backed up to multiple storage media, which are non-volatile memory chips installed on different components of the server; each storage media stores one copy of the configuration data and records the backup time information. In response to a configuration recovery command, backup data is read from the plurality of storage media respectively, and primary backup data and at least one secondary backup data are determined based on the time information; The server configuration is restored based on the primary backup data, and if the restoration fails, the server configuration is restored based on the secondary backup data.

2. The method according to claim 1, characterized in that, The step of backing up the configuration data to multiple storage media includes: The configuration data is backed up to a preset fixed storage medium in sequence according to a preset priority. When all preset fixed storage media are unavailable, a usable storage medium is searched from other components of the server, and a backup is performed using the usable storage medium.

3. The method according to claim 2, characterized in that, The preset priority is positively correlated with the degree of physical fixation of the component where the fixed storage medium is located; wherein, the storage medium located on the power supply backplane has a higher priority than the storage medium located on the fan plate, and the storage medium located on the fan plate has a higher priority than the storage medium located on the mounting ears.

4. The method according to claim 2, characterized in that, The search for available storage media includes: The storage media in the server are traversed, and the component description record field encoding of each storage medium is read through the inter-integrated circuit bus; The read component description record field codes are matched with a pre-configured mapping table, which contains component description record field codes that support backup. The matching storage media are identified as usable storage media.

5. The method according to claim 1, characterized in that, Before obtaining the server's configuration data, the method further includes: The extended area of ​​the storage medium is divided into a header field and a data field. The header field is used to store the backup flag, backup time information and checksum, and the data field is used to store the configuration data.

6. The method according to claim 5, characterized in that, The step of backing up the configuration data to multiple storage media includes: The required storage blocks are determined based on the size of the configuration data, and the storage blocks are storage units divided within the data domain; The configuration data is written sequentially to the corresponding storage blocks of multiple storage media.

7. The method according to claim 1, characterized in that, The step of reading backup data from the plurality of storage media respectively, and determining the primary backup data and at least one secondary backup data based on the time information, includes: The backup flag in each storage medium is read by hardware address to identify the storage medium storing backup data. Read the backup time information from the identified storage medium; Based on the read backup time information, all storage media containing backup data are sorted, and the most recent backup data is determined as the primary backup data, while the remaining backup data is determined as the secondary backup data.

8. The method according to claim 1, characterized in that, The number of backup data items includes multiple items; before restoring the server configuration based on the backup data, the method further includes: In response to a backup selection command, a target backup data is determined from multiple backup data sets, and the server configuration is restored based on the target backup data.

9. The method according to claim 1, characterized in that, The step of restoring the server configuration based on the secondary backup data in the event of a recovery failure includes: When recovery based on the primary backup data fails, a status code is recorded to identify hardware access errors or data integrity errors. The recovery is performed based on the backup data, and a recovery log is recorded.

10. A computing device, characterized in that, include: Baseboard Management Controller (BMC); Memory used to store the executable instructions of the BMC; The BMC is configured to execute the instructions to implement the method of any one of claims 1-9.

Images