A disaster recovery method, device, equipment and medium of a storage system

Abstract

Embodiments of the present application disclose a disaster recovery method, device and equipment of a storage system and a medium. According to calling data corresponding to each function module in the storage system, hot data to be backed up is determined. In order to reduce the amount of data to be backed up, the hot data is backed up to a pre-set disaster recovery data space according to a timing task. When an exception occurs in the running of the storage system itself, an exception function module is determined according to exception information, and the exception function module is configured and recovered by using data stored in the disaster recovery data space. Only the data of the exception function module needs to be configured and recovered, and the whole data does not need to be recovered, thereby reducing the time spent on configuration and recovery. Through detection of the running of the storage system itself, intelligent disaster recovery management of the data of the storage system itself can be realized. Without other complex configuration conditions, disaster recovery and recovery can be completed, and the shortage of the storage management software in disaster recovery of the data of the system itself is fundamentally made up.

Description

Technical Field

[0001] This application relates to the field of storage system technology, and in particular to a disaster recovery method, apparatus, device, and computer-readable storage medium for a storage system. Background Technology

[0002] As a crucial management platform, the security and stability of storage systems have always been goals pursued by manufacturers and are key indicators for customers. However, an increasing number of customers are placing higher demands on storage system management software, with intelligent disaster recovery being a critical task. Traditional disaster recovery methods often focus on the disaster recovery protection of disk data on the storage nodes managed by the system, i.e., the storage devices themselves. Storage devices can be storage pools, volumes, etc.

[0003] Storage systems possess absolute management capabilities over their storage nodes, enabling the management of data on each node. However, the most common method for managing the storage system's own data is currently manual backup and recovery. Disaster recovery is meant to prevent problems before they occur; only by ensuring the stability of the storage system's own data can storage nodes be better managed, thereby ensuring greater stability for user businesses.

[0004] It is evident that how to achieve intelligent disaster recovery management of the storage system's own data is a problem that needs to be solved by those skilled in the art. Summary of the Invention

[0005] The purpose of this application is to provide a disaster recovery method, apparatus, device, and computer-readable storage medium for a storage system, which can realize intelligent disaster recovery management of the storage system's own data.

[0006] To address the aforementioned technical problems, embodiments of this application provide a disaster recovery method for a storage system, comprising:

[0007] Based on the call data corresponding to each functional module in the storage system, the hot data to be backed up is determined;

[0008] The hot data is backed up to the pre-set disaster recovery data space according to the scheduled task;

[0009] When the storage system itself malfunctions, the abnormal functional module is identified based on the abnormal information, and the abnormal functional module is configured and restored using the data stored in the disaster recovery data space.

[0010] Optionally, the call data includes the user's call status for each functional module, as well as the usage frequency, read / write count, and interface call count of each functional module within a set time period;

[0011] The process of determining the hot data to be backed up based on the call data corresponding to each functional module in the storage system includes:

[0012] Based on user calls to each functional module, as well as the frequency of use, read / write operations, and API call counts of each functional module within a set time period, the functional modules are ranked by their call popularity.

[0013] The data corresponding to the top N most frequently accessed functional modules will be used as hot data.

[0014] Optionally, the ranking of functional modules by call popularity based on user usage and the frequency of use, read / write operations, and interface calls within a set time period includes:

[0015] Based on the user's calls to each functional module, the functional modules to be sorted are determined;

[0016] The usage frequency, read / write count, and API call count of each unsorted functional module within a set time period are accumulated.

[0017] Based on the accumulated values ​​of each unsorted functional module, sort them in descending order.

[0018] Optionally, the module for determining the abnormality based on the abnormality information when the storage system itself malfunctions includes:

[0019] Real-time monitoring of the storage system's own operational data; wherein, the operational data includes data in at least six dimensions, namely, service process information, log alarm information, physical resource information, network security information, database read and write status, and data interface service operation status;

[0020] When there is an anomaly in the operational data of any dimension, the functional module corresponding to the abnormal operational data is designated as the abnormal functional module; each dimension has its corresponding functional module.

[0021] Optionally, the module for determining the abnormality based on the abnormality information when the storage system itself malfunctions includes:

[0022] Real-time monitoring of the storage system's own operational data; wherein, the operational data includes data in at least six dimensions, namely, service process information, log alarm information, physical resource information, network security information, database read and write status, and data interface service operation status;

[0023] The operational data is comprehensively and quantitatively analyzed according to the weights corresponding to each dimension.

[0024] When the comprehensive quantitative analysis results meet the abnormal conditions, the functional modules corresponding to the abnormal operating data are designated as abnormal functional modules; each dimension has its corresponding functional module.

[0025] Optionally, the disaster recovery data space includes a local data space and a remote data space.

[0026] Optionally, the step of configuring and restoring the abnormal function module using the data stored in the disaster recovery data space includes:

[0027] Determine whether the local data space records the target configuration data corresponding to the abnormal function module;

[0028] If the local data space records target configuration data corresponding to the abnormal function module, then the target configuration data will overwrite the original configuration data of the abnormal function module;

[0029] If the local data space does not record the target configuration data corresponding to the abnormal function module, then the target configuration data corresponding to the abnormal function module is read from the remote data space, and the target configuration data is used to overwrite the original configuration data of the abnormal function module.

[0030] This application embodiment also provides a disaster recovery device for a storage system, including a data determination unit, a backup unit, a module determination unit, and a recovery unit;

[0031] The data determination unit is used to determine the hot data to be backed up based on the call data corresponding to each functional module in the storage system.

[0032] The backup unit is used to back up the hot data to a pre-set disaster recovery data space according to a scheduled task.

[0033] The module determination unit is used to determine the abnormal functional module based on the abnormal information when the storage system itself malfunctions.

[0034] The recovery unit is used to configure and restore the abnormal function module using the data stored in the disaster recovery data space.

[0035] Optionally, the call data includes the user's call status for each functional module, as well as the usage frequency, read / write count, and interface call count of each functional module within a set time period;

[0036] The data determination unit includes a sorting subunit and a filtering subunit;

[0037] The sorting subunit is used to sort the functional modules by their call popularity based on the user's call to each functional module and the frequency of use, read / write times and interface call times of each functional module within a set time period.

[0038] The filtering subunit is used to select the data corresponding to the top N most frequently called functional modules as hot data.

[0039] Optionally, the sorting subunit is used to determine the functional modules to be sorted based on the user's calling behavior of each functional module; to accumulate the usage frequency, read / write count, and interface call count of each functional module to be sorted within a set time period; and to sort the functional modules to be sorted in descending order based on the accumulated values ​​of each functional module to be sorted.

[0040] Optionally, the function determination unit includes a detection subunit and an as a subunit;

[0041] The detection subunit is used to detect the storage system's own operating data in real time; wherein, the operating data includes data in at least six dimensions, namely, service process information, log alarm information, physical resource information, network security information, database read and write status, and data interface service operation status;

[0042] The sub-unit is used to designate the functional module corresponding to the abnormal operating data as the abnormal functional module when there is an anomaly in the operating data of any dimension; wherein, each dimension has its corresponding functional module.

[0043] Optionally, the function determination unit includes a detection subunit, a quantization subunit, and an as a subunit;

[0044] The detection subunit is used to detect the storage system's own operating data in real time; wherein, the operating data includes data in at least six dimensions, namely, service process information, log alarm information, physical resource information, network security information, database read and write status, and data interface service operation status;

[0045] The quantization subunit is used to perform comprehensive quantitative analysis on the running data according to the weights corresponding to each dimension.

[0046] The sub-unit is used to designate the functional module corresponding to the abnormal operating data as the abnormal functional module when the comprehensive quantitative analysis result meets the abnormal conditions; wherein, each dimension has its corresponding functional module.

[0047] Optionally, the disaster recovery data space includes a local data space and a remote data space.

[0048] Optionally, the recovery unit includes a judgment subunit, a cover subunit, and a read subunit;

[0049] The judgment subunit is used to determine whether the local data space records the target configuration data corresponding to the abnormal function module;

[0050] The overlay subunit is used to overwrite the original configuration data of the abnormal function module with the target configuration data if the local data space records target configuration data corresponding to the abnormal function module.

[0051] The reading subunit is configured to read the target configuration data corresponding to the abnormal function module from the remote data space if the local data space does not record the target configuration data corresponding to the abnormal function module, and trigger the overwrite subunit to perform the step of overwriting the original configuration data of the abnormal function module with the target configuration data.

[0052] This application also provides a disaster recovery device for a storage system, including:

[0053] Memory, used to store computer programs;

[0054] A processor for executing the computer program to implement the steps of the disaster recovery method for the storage system described above.

[0055] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the disaster recovery method for the storage system described above.

[0056] As can be seen from the above technical solution, hot data to be backed up is determined based on the call data corresponding to each functional module in the storage system; hot data is critical data that users access frequently. To effectively reduce the amount of data to be backed up, hot data can be backed up to a pre-defined disaster recovery data space according to scheduled tasks. Compared to backing up all data, this technical solution only needs to back up hot data, effectively reducing the time spent on data backup. When the storage system itself experiences an anomaly, the abnormal functional module can be identified based on the anomaly information, and the data stored in the disaster recovery data space can be used to configure and restore the abnormal functional module. When performing data recovery, only the data of the abnormal functional module needs to be configured and restored, without the need to restore all data, thus reducing the time spent on configuration and recovery while ensuring the normal operation of other functional modules. By monitoring its own operation, intelligent disaster recovery management of the storage system's own data can be achieved. Disaster recovery and restoration can be completed without other complex configuration conditions, fundamentally making up for the shortcomings of storage management software in terms of disaster recovery of its own system data. Attached Figure Description

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

[0058] Figure 1 A flowchart illustrating a disaster recovery method for a storage system provided in this application embodiment;

[0059] Figure 2 This application provides a schematic diagram of a disaster recovery scenario for a storage system.

[0060] Figure 3 A schematic diagram of the structure of a disaster recovery device for a storage system provided in this application embodiment;

[0061] Figure 4 This is a structural diagram of a disaster recovery device for a storage system provided in an embodiment of this application. Detailed Implementation

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

[0063] The terms "comprising" and "having," and any variations thereof, in the specification, claims, and accompanying drawings of this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the steps or units listed, but may include steps or units not listed.

[0064] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0065] Next, a disaster recovery method for a storage system provided by the embodiments of this application will be described in detail. Figure 1 A flowchart of a disaster recovery method for a storage system provided in this application embodiment is included, the method comprising:

[0066] S101: Based on the call data corresponding to each functional module in the storage system, determine the hot data to be backed up.

[0067] The storage system itself contains a massive amount of data. Backing up all the data would not only require a significant amount of storage space but also take a considerable amount of time. In this embodiment, to improve the disaster recovery management efficiency of the storage system, only the data corresponding to functional modules that have a strong impact on the security of the storage system can be backed up. In this embodiment, functional modules with a strong impact on the security of the storage system can be selected based on their usage.

[0068] The call data is used to characterize the usage of functional modules. The call data can include information such as user calls to each functional module, as well as the usage frequency, read / write count, and API call count of each functional module within a set time period.

[0069] User usage patterns for each functional module can be determined based on user habits. Based on these patterns, frequently used functional modules can be identified. In this embodiment, functional modules can be ranked by usage frequency, read / write frequency, and interface call frequency within a set time period.

[0070] In practice, functional modules can be initially screened based on user calls to each module, that is, functional modules to be sorted can be determined based on user calls to each module.

[0071] For a given functional module, its usage frequency, read / write frequency, and API call frequency are strongly correlated and equally important for evaluating the module. Therefore, to more accurately assess the usage frequency of functional modules, the usage frequency, read / write frequency, and API call frequency of each module to be sorted can be accumulated over a set time period. Based on the accumulated values ​​of each module, they are then sorted in descending order.

[0072] After sorting the functional modules by their usage frequency, the data corresponding to the top N functional modules with the highest usage frequency can be taken as hot data.

[0073] The value of N can be set based on actual needs and is not limited here.

[0074] S102: Back up hot data to the pre-defined disaster recovery data space according to the scheduled task.

[0075] In this embodiment, only the data corresponding to the most popular functional modules needs to be backed up, and the amount of data to be backed up is small. Therefore, the time of the scheduled task can be set to be shorter.

[0076] Setting the time interval for scheduled tasks to a shorter duration ensures timely updates of data in the disaster recovery data space. This prevents data from remaining unupdated for extended periods, which could lead to the storage system reverting to a near-initial state during subsequent recovery operations that rely on data stored in the disaster recovery data space.

[0077] S103: When an abnormality occurs in the operation of the storage system itself, the abnormal functional module is identified based on the abnormal information, and the abnormal functional module is configured and restored using the data stored in the disaster recovery data space.

[0078] The disaster recovery data space stores the configuration information of the storage system under normal operating conditions. When the storage system itself malfunctions, it indicates a problem with the current configuration. In this case, the faulty functional module can be identified based on the fault information, and the configuration of the faulty functional module can be restored using the data stored in the disaster recovery data space.

[0079] In this embodiment, by analyzing the abnormal information, it can be determined which or which functional modules have malfunctioned. Only the data of the malfunctioning functional module needs to be restored, without having to restore the data of all functional modules in the storage system. This ensures both disaster recovery of the storage system and the normal execution of the workflow of other functional modules that do not have malfunctions.

[0080] There are several ways to identify abnormal functional modules. One feasible approach is to monitor the storage system's own operational data in real time. This operational data includes at least six dimensions: service process information, log and alarm information, physical resource information, network security information, database read / write status, and the operational status of data interface services. When any dimension of the operational data shows an anomaly, the functional module corresponding to that anomaly can be identified as the abnormal functional module. Each dimension has its own corresponding functional module.

[0081] Service process information is used to indicate the running status of a process.

[0082] Log alerts are alerts generated by the storage system when it detects abnormal conditions.

[0083] Physical resource information represents the physical resources currently configured in the storage system. In practical applications, minimum physical resource standards are set to ensure the normal operation of each functional module, such as the number of CPUs, the number of cores, and the storage space size. When the physical resource information of the storage system does not meet the minimum physical resource standards, it indicates that there is an anomaly in the physical resource information.

[0084] Network security information is used to indicate whether a storage system has been subjected to a cyberattack.

[0085] Database read / write activity indicates the number of times a database is read from or written to within a given unit of time. Under normal storage system operation, database read / write activity remains relatively stable, without a sudden surge in frequency over a short period. Therefore, a sharp change in database read / write activity within a short timeframe indicates an anomaly in the database read / write activity.

[0086] The operational status of the data interface service indicates the interaction between the storage system and external devices. When the data interface service experiences timeouts, data loss, or no response, it indicates an anomaly in the data interface service.

[0087] Another feasible approach is to monitor the storage system's own operational data in real time. This operational data includes at least six dimensions: service process information, log and alarm information, physical resource information, network security information, database read / write status, and the operational status of data interface services. The operational data is then comprehensively and quantitatively analyzed according to the weights corresponding to each dimension. When the comprehensive quantitative analysis results meet the abnormal conditions, the functional modules corresponding to the abnormal operational data are designated as abnormal functional modules. Each dimension has its corresponding functional module.

[0088] The impact of parameters in different dimensions on the security of the storage system varies. In this embodiment, weights can be set based on the impact of parameters in each dimension on the security of the storage system.

[0089] In practical applications, log alert information can be given a higher weight, while the weights for service process information, physical resource information, network security information, database read / write status, and data interface service operation status can be set to the same value. This setting method is only for illustrative purposes; in this embodiment, the weights corresponding to each dimension are not specifically limited.

[0090] In practical implementation, a score list can be set for each dimension of data. By querying the score list, the score corresponding to the specific data in each dimension can be determined. The scores are then weighted and summed, and the weighted sum is used as the comprehensive quantitative analysis result. When the weighted sum exceeds a preset threshold, the functional module corresponding to the abnormal running data is designated as an abnormal functional module.

[0091] By setting multiple dimensions of data to evaluate the operating status of the storage system itself, the accuracy of the storage system operating status assessment can be improved.

[0092] In practical applications, to improve disaster recovery reliability, two disaster recovery data spaces can be configured: a local data space located on the storage system and a remote data space on a host other than the host where the storage system resides. During data recovery, even if data in the local data space is corrupted, the necessary data can be retrieved from the remote data space to restore the storage system's configuration.

[0093] Figure 2 This illustration shows a disaster recovery scenario for a storage system provided in this application. The storage system can manage multiple storage devices, and users can access the storage system through terminal devices. There can be two storage locations for storing hot data: one is the local data space of the storage system, and the other is a remote data space on a host other than the host where the storage system is located. The remote data space and the local data space can be synchronized. Considering that data stored in the local data space may become abnormal in practical applications, data stored in the remote data space can be used to recover abnormal data in the local data space.

[0094] When configuration recovery of the storage system is required, it can be determined whether the local data space records the target configuration data corresponding to the malfunctioning module. If the local data space records the target configuration data corresponding to the malfunctioning module, the target configuration data can be directly overwritten with the original configuration data of the malfunctioning module.

[0095] If the local data space does not record the target configuration data corresponding to the abnormal function module, it indicates that data loss has occurred in the local data space. In this case, the target configuration data corresponding to the abnormal function module can be read from the remote data space, and the target configuration data can overwrite the original configuration data of the abnormal function module.

[0096] As can be seen from the above technical solution, hot data to be backed up is determined based on the call data corresponding to each functional module in the storage system; hot data is critical data that users access frequently. To effectively reduce the amount of data to be backed up, hot data can be backed up to a pre-defined disaster recovery data space according to scheduled tasks. Compared to backing up all data, this technical solution only needs to back up hot data, effectively reducing the time spent on data backup. When the storage system itself experiences an anomaly, the abnormal functional module can be identified based on the anomaly information, and the data stored in the disaster recovery data space can be used to configure and restore the abnormal functional module. When performing data recovery, only the data of the abnormal functional module needs to be configured and restored, without the need to restore all data, thus reducing the time spent on configuration and recovery while ensuring the normal operation of other functional modules. By monitoring its own operation, intelligent disaster recovery management of the storage system's own data can be achieved. Disaster recovery and restoration can be completed without other complex configuration conditions, fundamentally making up for the shortcomings of storage management software in terms of disaster recovery of its own system data.

[0097] Figure 3 A schematic diagram of the structure of a disaster recovery device for a storage system provided in this application embodiment includes a data determination unit 31, a backup unit 32, a module determination unit 33, and a recovery unit 34;

[0098] The data determination unit 31 is used to determine the hot data to be backed up based on the call data corresponding to each functional module in the storage system.

[0099] Backup unit 32 is used to back up hot data to a pre-set disaster recovery data space according to scheduled tasks;

[0100] The module determination unit 33 is used to determine the abnormal functional module based on the abnormal information when the storage system itself malfunctions.

[0101] Recovery unit 34 is used to configure and restore abnormal function modules using data stored in the disaster recovery data space.

[0102] Optionally, the call data includes the user's call to each functional module, as well as the usage frequency, read / write count, and interface call count of each functional module within a set time period;

[0103] The data determination unit includes a sorting subunit and a filtering subunit;

[0104] The sorting subunit is used to sort the functional modules by their usage frequency, read / write frequency, and interface call frequency within a set time period.

[0105] The filtering sub-unit is used to select the data corresponding to the top N most frequently called functional modules as hot data.

[0106] Optionally, the sorting subunit is used to determine the functional modules to be sorted based on the user's calling behavior of each functional module; to accumulate the usage frequency, read / write count, and interface call count of each functional module to be sorted within a set time period; and to sort the functional modules to be sorted in descending order based on the accumulated values ​​of each functional module to be sorted.

[0107] Optionally, the function determination unit includes a detection subunit and a function subunit;

[0108] The detection subunit is used to detect the storage system's own operational data in real time. The operational data includes data in at least six dimensions, namely service process information, log and alarm information, physical resource information, network security information, database read and write status, and data interface service operation status.

[0109] As a sub-unit, it is used to identify the functional module corresponding to the abnormal running data when there is an anomaly in the running data of any dimension; each dimension has its corresponding functional module.

[0110] Optionally, the function determination unit includes a detection subunit, a quantization subunit, and an as subunit;

[0111] The detection subunit is used to detect the storage system's own operational data in real time. The operational data includes data in at least six dimensions, namely service process information, log and alarm information, physical resource information, network security information, database read and write status, and data interface service operation status.

[0112] The quantization subunit is used to perform comprehensive quantitative analysis on the running data according to the weights corresponding to each dimension.

[0113] As a sub-unit, when the comprehensive quantitative analysis results meet the abnormal conditions, the functional module corresponding to the abnormal running data is designated as the abnormal functional module; each dimension has its corresponding functional module.

[0114] Optionally, the disaster recovery data space includes local data space and remote data space.

[0115] Optionally, the recovery unit includes a judgment subunit, a cover subunit, and a read subunit;

[0116] The judgment subunit is used to determine whether the local data space records the target configuration data corresponding to the abnormal function module;

[0117] The overlay subunit is used to overwrite the original configuration data of the abnormal function module if the local data space records the target configuration data corresponding to the abnormal function module.

[0118] The read subunit is used to read the target configuration data corresponding to the abnormal function module from the remote data space if the local data space does not record the target configuration data corresponding to the abnormal function module, and to trigger the overwrite subunit to execute the step of overwriting the original configuration data of the abnormal function module with the target configuration data.

[0119] Figure 3 For a description of the features in the corresponding embodiments, please refer to Figure 1 The relevant descriptions of the corresponding embodiments will not be repeated here.

[0120] As can be seen from the above technical solution, hot data to be backed up is determined based on the call data corresponding to each functional module in the storage system; hot data is critical data that users access frequently. To effectively reduce the amount of data to be backed up, hot data can be backed up to a pre-defined disaster recovery data space according to scheduled tasks. Compared to backing up all data, this technical solution only needs to back up hot data, effectively reducing the time spent on data backup. When the storage system itself experiences an anomaly, the abnormal functional module can be identified based on the anomaly information, and the data stored in the disaster recovery data space can be used to configure and restore the abnormal functional module. When performing data recovery, only the data of the abnormal functional module needs to be configured and restored, without the need to restore all data, thus reducing the time spent on configuration and recovery while ensuring the normal operation of other functional modules. By monitoring its own operation, intelligent disaster recovery management of the storage system's own data can be achieved. Disaster recovery and restoration can be completed without other complex configuration conditions, fundamentally making up for the shortcomings of storage management software in terms of disaster recovery of its own system data.

[0121] Figure 4 A structural diagram of a disaster recovery device for a storage system provided in this application embodiment is shown below. Figure 4 As shown, the disaster recovery equipment of the storage system includes: a memory 20 for storing computer programs;

[0122] The processor 21 is used to implement the steps of the disaster recovery method of the storage system as described in the above embodiments when executing a computer program.

[0123] The disaster recovery equipment for the storage system provided in this embodiment may include, but is not limited to, smartphones, tablets, laptops, or desktop computers.

[0124] The processor 21 may include one or more processing cores, such as a quad-core processor or an octa-core processor. The processor 21 may be implemented using at least one hardware form selected from DSP (Digital Signal Processing), FPGA (Field-Programmable Gate Array), and PLA (Programmable Logic Array). The processor 21 may also include a main processor and a coprocessor. The main processor, also known as a CPU (Central Processing Unit), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, the processor 21 may integrate a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, the processor 21 may also include an AI (Artificial Intelligence) processor, which is used to handle computational operations related to machine learning.

[0125] The memory 20 may include one or more computer-readable storage media, which may be non-transitory. The memory 20 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In this embodiment, the memory 20 is used to store at least the following computer program 201, which, after being loaded and executed by the processor 21, is capable of implementing the relevant steps of the disaster recovery method of the storage system disclosed in any of the foregoing embodiments. In addition, the resources stored in the memory 20 may also include an operating system 202 and data 203, and the storage method may be temporary storage or permanent storage. The operating system 202 may include Windows, Unix, Linux, etc. The data 203 may include, but is not limited to, access data, hot data, etc.

[0126] In some embodiments, the disaster recovery device of the storage system may further include a display screen 22, an input / output interface 23, a communication interface 24, a power supply 25, and a communication bus 26.

[0127] Those skilled in the art will understand that Figure 4 The structure shown does not constitute a limitation on the disaster recovery equipment of the storage system and may include more or fewer components than shown.

[0128] It is understood that if the disaster recovery method of the storage system in the above embodiments is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and executes all or part of the steps of the methods in the various embodiments of this application. The aforementioned storage medium includes: USB flash drive, mobile hard disk, read-only memory (ROM), random access memory (RAM), electrically erasable programmable ROM, register, hard disk, removable disk, CD-ROM, magnetic disk or optical disk, and other media capable of storing program code.

[0129] Based on this, embodiments of the present invention also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the disaster recovery method of the storage system described above.

[0130] The functions of each functional module of the computer-readable storage medium described in the embodiments of the present invention can be specifically implemented according to the methods in the above method embodiments. The specific implementation process can be referred to the relevant descriptions in the above method embodiments, which will not be repeated here.

[0131] The foregoing has provided a detailed description of a disaster recovery method, apparatus, device, and computer-readable storage medium for a storage system according to embodiments of this application. The various embodiments are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section.

[0132] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0133] The foregoing has provided a detailed description of a disaster recovery method, apparatus, device, and computer-readable storage medium for a storage system. Specific examples have been used to illustrate the principles and implementation methods of the invention. The descriptions of these embodiments are merely illustrative of the method and its core ideas. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from the principles of the invention, and these improvements and modifications also fall within the scope of protection of the claims of this application.

Claims

1. A disaster recovery method for a storage system, characterized in that, include: Based on the call data corresponding to each functional module in the storage system, the hot data to be backed up is determined; The hot data is backed up to a pre-defined disaster recovery data space according to a scheduled task; the data stored in the disaster recovery data space is the configuration information corresponding to the storage system under normal operating conditions. When it is determined that the storage system itself is malfunctioning based on its own operating data, the abnormal functional module is identified based on the abnormal information, and the abnormal functional module is configured and restored using the data stored in the disaster recovery data space. The operational data includes data from at least six dimensions: service process information, log and alarm information, physical resource information, network security information, database read and write status, and data interface service operation status; each dimension has its corresponding functional module. The call data includes the user's call status for each functional module, as well as the usage frequency, read / write count, and interface call count of each functional module within a set time period. The step of determining the hot data to be backed up based on the call data corresponding to each functional module in the storage system includes: sorting each functional module by call popularity based on the user's call to each functional module, as well as the usage frequency, read / write count, and interface call count of each functional module within a set time period; and taking the data corresponding to the top N functional modules with the highest call popularity as hot data. The process of ranking functional modules by usage frequency, read / write frequency, and interface call frequency within a set time period, based on user calls to each module, includes: determining functional modules to be ranked based on user calls; these modules are those with a significant impact on storage system security; accumulating the usage frequency, read / write frequency, and interface call frequency of each module within the set time period; and then arranging the modules in descending order based on the accumulated values.

2. The disaster recovery method for a storage system according to claim 1, characterized in that, The module for determining the abnormality based on the abnormality information when the storage system itself malfunctions includes: When any dimension of the running data is abnormal, the functional module corresponding to the abnormal running data will be designated as the abnormal functional module.

3. The disaster recovery method for a storage system according to claim 1, characterized in that, The module for determining the abnormality based on the abnormality information when the storage system itself malfunctions includes: The operational data is comprehensively and quantitatively analyzed according to the weights corresponding to each dimension. When the comprehensive quantitative analysis results meet the abnormal conditions, the functional module corresponding to the abnormal operating data will be regarded as the abnormal functional module.

4. The disaster recovery method for a storage system according to any one of claims 1 to 3, characterized in that, The disaster recovery data space includes local data space and remote data space.

5. The disaster recovery method for a storage system according to claim 4, characterized in that, The step of configuring and restoring the abnormal function module using the data stored in the disaster recovery data space includes: Determine whether the local data space records the target configuration data corresponding to the abnormal function module; If the local data space records target configuration data corresponding to the abnormal function module, then the target configuration data will overwrite the original configuration data of the abnormal function module; If the local data space does not record the target configuration data corresponding to the abnormal function module, then the target configuration data corresponding to the abnormal function module is read from the remote data space, and the target configuration data is used to overwrite the original configuration data of the abnormal function module.

6. A disaster recovery device for a storage system, characterized in that, It includes a data determination unit, a backup unit, a module determination unit, and a recovery unit; The data determination unit is used to determine the hot data to be backed up based on the call data corresponding to each functional module in the storage system. The backup unit is used to back up the hot data to a pre-set disaster recovery data space according to a scheduled task; the data stored in the disaster recovery data space is the configuration information corresponding to the storage system under normal operating conditions. The module determination unit is used to determine the abnormal functional module based on the abnormal information when it is determined that the storage system itself is malfunctioning based on its own operating data. The recovery unit is used to configure and restore the abnormal function module using the data stored in the disaster recovery data space; The operational data includes data from at least six dimensions: service process information, log and alarm information, physical resource information, network security information, database read and write status, and data interface service operation status; each dimension has its corresponding functional module. The call data includes the user's call status for each functional module, as well as the usage frequency, read / write count, and interface call count of each functional module within a set time period. The data determination unit is specifically used to sort the functional modules by their call frequency based on the user's call to each functional module and the frequency of use, read / write operations, and interface call operations of each functional module within a set time period; and to take the data corresponding to the top N functional modules with the highest call frequency as hot data. The data determination unit is specifically used to determine the functional modules to be sorted based on the user's calling of each functional module; the functional modules to be sorted are the functional modules in the storage system that have a strong impact on the security of the storage system; the usage frequency, read and write times and interface call times of each functional module to be sorted are accumulated within a set time period; and the functional modules to be sorted are arranged in descending order based on the accumulated value of each functional module to be sorted.

7. A disaster recovery device for a storage system, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the steps of the disaster recovery method for the storage system as described in any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the disaster recovery method for the storage system as described in any one of claims 1 to 5.

Images