Method for fast recovery of backup data based on emergency backup system

Abstract

The application discloses a kind of based on the quick recovery backup data of emergency backup system, it is related to data backup and recovery technical field.The method includes: real-time monitoring production system operating state, when detecting abnormal event, automatically generating the data recovery request carrying the data to be recovered data identification information and recovery time point information;According to the identification information, corresponding backup data storage volume information is inquired in backup index table;Determine target storage volume and map, mount to recovery client;According to recovery time point, the closest backup time point is found in target storage volume and snapshot data is acquired, if there is incremental backup data thereafter, then complete backup data is generated by merging and is recovered to specified target path.The application realizes the automatic quick accurate recovery of backup data in emergency scene, and can be widely applied in meteorological monitoring, environmental monitoring and other fields.

Description

Technical Field

[0001] This invention relates to the field of data backup and recovery technology, and specifically to a method for rapidly restoring backup data based on an emergency backup system. Background Technology

[0002] With the rapid development of information technology, various production systems are increasingly reliant on data. In fields such as meteorological monitoring, environmental monitoring, financial services, and industrial control, the integrity and availability of data are directly related to business continuity and security. Once a production system experiences an anomaly such as system crash, storage device failure, data corruption, or human error, how to quickly and accurately restore backup data to a usable state has become a pressing technical problem in the field of data protection.

[0003] In the prior art, some data recovery schemes based on emergency backup systems have been proposed. For example, Chinese patent application CN110262928A discloses a method for quickly restoring backup data based on an emergency backup system. Its basic process includes: selecting the data to be restored in the backup data list, finding the data storage volume to be restored in the Pool filesystem snapshot system volume list, mapping it to the recovery client through a communication protocol (such as iSCSI, IB, FC), mounting the storage volume mapped here on the recovery client, restoring the data in the mounted volume to the specified target path, and checking whether the data has been restored successfully.

[0004] However, the aforementioned existing technologies have the following shortcomings: First, the data recovery is triggered manually, requiring users to select the data to be recovered from the backup data list. In emergency scenarios, every second of delay after an anomaly occurs can lead to greater business losses. The manually triggered recovery method has a slow response time and cannot meet the urgent need for rapid recovery in emergency situations.

[0005] Second, the granularity of data recovery is limited to the entire data set, meaning it can only restore to a specific version of the data selected from the backup list. It cannot support precise recovery at a specified historical point in time. In practical applications, users often need to restore data to a state at a specific point in time (e.g., the data state 5 minutes before the failure), a capability that current technology cannot provide.

[0006] Third, the backup data is searched by traversing the system volume list, which lacks an efficient indexing mechanism. When the backup data volume is large, the traversal search is inefficient and seriously affects the recovery speed.

[0007] Fourth, the recovery process only involves the direct recovery of snapshot data, without processing incremental backup data. In backup systems that employ a "full backup + incremental backup" strategy, if it is necessary to restore to a data state at a point in time other than a full backup, existing technologies require sequentially applying all incremental backup data from the full backup to the target point in time, resulting in long recovery times and low efficiency.

[0008] Furthermore, existing backup systems often employ a single-node storage architecture. When the storage node itself fails, the backup data becomes inaccessible, leading to recovery failure.

[0009] To address the shortcomings of the existing technologies, this invention provides a method for rapidly restoring backup data based on an emergency backup system. This method enables automatic detection and recovery triggering of abnormal events, precise recovery at specified time points, rapid storage volume location based on index tables, and efficient data recovery based on the merging of snapshots and incremental backups. Summary of the Invention

[0010] This invention addresses the technical problems in existing technologies, such as reliance on manual triggering for emergency backup data recovery, inability to recover at specified time points, lack of efficient indexing mechanisms, and low incremental backup recovery efficiency. It provides a method for rapidly recovering backup data based on an emergency backup system, aiming to achieve automatic, rapid, and accurate recovery of backup data in emergency scenarios.

[0011] This invention provides a method for rapidly restoring backup data based on an emergency backup system, comprising: S1. Monitor the operating status of the production system in real time. When a preset type of abnormal event is detected in the production system, automatically generate a data recovery request. The data recovery request carries the identification information of the data to be recovered and the recovery time point information. S2. Based on the identification information of the data to be recovered, query the backup data storage volume information corresponding to the data to be recovered in the backup index table of the emergency backup system. The backup index table records at least the storage location, backup time point and data version information of each backup data storage volume. S3. Determine the target storage volume based on the queried backup data storage volume information, and map the target storage volume to the recovery client through a communication protocol; S4. Mount the mapped target storage volume on the recovery client; S5. Based on the recovery time point information, find the backup time point closest to the recovery time point in the target storage volume and obtain the corresponding snapshot data. If there is incremental backup data after the closest backup time point, merge the snapshot data and the incremental backup data to generate complete backup data corresponding to the recovery time point, and restore the complete backup data to the specified target path.

[0012] Compared with the prior art, the present invention has the following advantages: 1. By monitoring the production system's operating status in real time and automatically generating data recovery requests when abnormal events are detected, the recovery process can be triggered without manual intervention, significantly shortening the emergency response time.

[0013] 2. By including recovery time point information in the data recovery request and combining it with the merging mechanism of snapshots and incremental backups, data recovery at any historical time point is achieved, meeting the business needs for refined recovery.

[0014] 3. By establishing a structured backup index table to record storage location, backup time, and data version information, the target storage volume can be quickly located, avoiding the inefficient operation of traversal search.

[0015] 4. By using the mechanism of "finding the snapshot closest to the time point + merging only incremental backups after that time point", the system avoids sequentially applying all incremental backups from the full backup to the target time point, significantly improving recovery efficiency.

[0016] 5. By adopting a distributed storage architecture and supporting automatic switching between primary and backup storage nodes, data recovery can still be completed through replica nodes when the primary storage node fails, ensuring the reliability of emergency recovery. Attached Figure Description

[0017] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0018] Figure 1 This is a flowchart illustrating a method for rapidly restoring backup data based on an emergency backup system, according to an embodiment of the present invention. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0020] like Figure 1As shown, the present invention provides a method for rapidly restoring backup data based on an emergency backup system, comprising: S1. Monitor the operational status of the production system in real time. When a preset type of abnormal event is detected in the production system, automatically generate a data recovery request. The data recovery request carries the identification information of the data to be recovered and the recovery time point information.

[0021] Specifically, this invention provides real-time monitoring of the operational status of a production system. Specifically, monitoring agents can be deployed in key components of the production system (such as the operating system, database management system, storage devices, and applications). Each monitoring agent periodically reports operational status information to the status monitoring center of the emergency backup system. The status monitoring center maintains a status information table, recording the latest reported status of each monitoring agent and its update time.

[0022] The status information reported by the monitoring agent includes, but is not limited to: system heartbeat signal (used to determine system liveness); read / write error rate of storage devices; database transaction log status; application process status and response time. Preset types of exception events: In one optional implementation, the preset types of abnormal events include system crashes, storage device failures, data corruption, and human error. For different types of abnormal events, the present invention employs different detection methods: (1) System downtime detection: When the status monitoring center does not receive a heartbeat signal from a certain monitoring agent within a preset time threshold, it determines that the production system has downtime. Let the expected reception period of the heartbeat signal be... (Unit: seconds), the maximum allowed number of packet losses is (For example, 3 times), then the crash determination condition is: ; in, This indicates the duration (in seconds) since the last successful reception of a heartbeat signal. Indicates the expected reception period of the heartbeat signal (unit: seconds); This represents the maximum number of consecutive packet losses allowed (a dimensionless integer).

[0023] (2) Storage device fault detection: When the storage device read / write error rate reported by the monitoring agent exceeds the preset error rate threshold. When (e.g., 0.1%), or when the available capacity of the storage device is lower than a preset capacity threshold. When the value reaches (unit: GB), a storage device failure is determined.

[0024] Assume the storage device is within the statistical time period. The total number of read and write operations within is The number of failed read / write operations was 100. Then the read / write error rate for: ; when When this occurs, a storage device fault alarm is triggered and a data recovery request is automatically generated.

[0025] (3) Data corruption detection: Checksums (such as MD5, SHA, or CRC values) are periodically calculated for critical data files in the production system and compared with previously stored baseline checksums. If the checksums do not match, data corruption is determined. Let the data file... The current check value is The baseline verification value is The criteria for determining data corruption are: ; in, This represents the data file checksum (string type) calculated at the current moment. This represents the baseline check value (string type) of the pre-stored data file.

[0026] (4) Human error detection: By monitoring the data modification operation logs in the production system (such as database DML operation logs, file system modification logs, etc.), when a large number of data deletion, modification, or overwrite operations are detected within a short period of time, it is determined that a human error has occurred. Specifically, a unit time... The number of data modification operations that occurred within (unit: seconds) is The average number of operations per unit time under normal circumstances is The standard deviation is The determination condition is: ; in, Represents unit of time The actual number of data modification operations that occurred (dimensionless integer). This represents the statistical mean (dimensionless real number) of the number of data modification operations per unit time under normal circumstances. This represents the statistical standard deviation (dimensionless real number) of the number of data modification operations per unit time under normal circumstances. This represents the preset threshold coefficient (dimensionless constant), for example, taking... When the number of operations exceeds the mean plus three times the standard deviation, it is considered an abnormal operation.

[0027] When any of the above-mentioned abnormal events is detected, step S1 automatically generates a data recovery request. The data recovery request is generated in a structured data format (such as JSON or XML) and carries at least the following information: Data Identification Information for Data to be Recovered ): Used to uniquely identify the data object that needs to be recovered; Recovery Time Point Information ): Specifies the historical point in time to which the data should be restored.

[0028] Recovery time point information The determination method is as follows: For system crashes and storage device failures, recovery time points The default is the last normal backup point in time before the abnormal event occurred; For data corruption, recovery time point The default time is the most recent full backup before the data corruption occurred; For human error, recovery time point The default time is the time before the erroneous operation began (which can be determined by the operation timestamp in the operation log).

[0029] In addition, data recovery requests can also carry event type information (Event Type, The emergency backup system is based on the type of abnormal event. Determine recovery priorities: For example, system crashes and storage device failures have higher priority than data corruption, and data corruption has higher priority than human error. When multiple recovery requests exist simultaneously, execute the recovery operations sequentially according to their priority from highest to lowest.

[0030] S2. Based on the identification information of the data to be recovered, query the backup data storage volume information corresponding to the data to be recovered in the backup index table of the emergency backup system. The backup index table records at least the storage location, backup time, and data version information of each backup data storage volume.

[0031] The emergency backup system maintains a backup index table. The backup index table 1 must record at least the following fields: Table 1

[0032] Backup index table The records are updated after each backup operation. When a full backup is performed, a new record is added to the backup index table, recording the storage volume information, backup time, and data version number corresponding to the full backup. When an incremental backup is performed, a new record is also added to the backup index table, recording the storage volume information corresponding to the incremental backup.

[0033] In one alternative implementation, the index table is backed up. Establish a multi-level index structure based on the importance level and data type of the data.

[0034] Data types include the following three categories: Time-series data: Data generated in chronological order, such as meteorological monitoring data, environmental monitoring data, sensor data, etc. Structured data: Data with a fixed format and structure, such as data in a relational database; Unstructured data: Data without a fixed format, such as log files, images, and videos.

[0035] Importance levels can be divided into multiple levels based on business needs, for example: Level 1 (Highest Importance): Core business data; loss of this data would result in significant business disruption. Level 2 (High Importance): Critical business data; loss of this data will restrict business functionality. Level 3 (General Importance): Ordinary business data, loss has a relatively small impact.

[0036] The specific organization of a multi-level index structure is as follows: In the first-level index, it is classified according to data type (time-series / structured / unstructured); in the second-level index, it is further subdivided according to importance level; in the third-level index, specific data entry indexes are established according to data identification information (such as data name, ID, etc.).

[0037] In addition, based on the identification information of the data to be recovered Query backup index table When doing so, priority is given to matching the index level that corresponds to the data type and importance level of the data to be recovered.

[0038] Specifically, let the identification information of the data to be recovered be... The emergency backup system first starts from Parse the data type identifier Importance level label Then follow these steps to perform the query: Step 1: Back up the index table In the first-level index (data type index), locate the... Matching index partitions.

[0039] Step Two: Within the located index partition, further locate the corresponding index within the second-level index (importance level index). Matching index sub-partitions.

[0040] Step 3: In the located index sub-partition, based on the identification information of the data to be recovered... Perform exact or fuzzy matching to find matches with The corresponding backup data storage volume information.

[0041] Step 4: Extract storage volume information from the found index entries, including storage location ( ), backup time point ( ) and data version number ( ).

[0042] Let the storage volume information set be... The above query process can then be represented as: ; in, Represents complete identification information (string type) of the data to be recovered; Indicates from The target data type identifier (enumeration type) parsed from the data; Indicates from The target importance level identifier (integer type) parsed from the data; Indicates from The specific data object identifier (string type) parsed from the data; This represents the collection of storage volume information returned by the query.

[0043] When the identification information of the data to be recovered When the data includes monitoring station identifiers, monitoring data type identifiers, and monitoring time period identifiers (such as meteorological monitoring data or environmental monitoring data scenarios), the query process also includes further filtering of index entries based on the monitoring station identifiers and monitoring time period identifiers.

[0044] S3. Query the backup data storage volume information returned by the backup index query step. Determine the target storage volume A target storage volume is a logical storage unit in the storage device of an emergency backup system that stores backup data.

[0045] in, This represents the collection of storage volume information returned by the backup index query step; Indicates the recovery time point information; This indicates the selection of the recovery time point from the storage volume information set. The function to select the best-matching storage volume; This indicates the final target storage volume.

[0046] and transmit the target storage volume via communication protocol Mapping to the recovery client. Mapping refers to establishing a logical connection between the recovery client and the storage device of the emergency backup system, enabling the recovery client to access the remote target storage volume as if it were a local storage device.

[0047] The communication protocols supported by this invention include, but are not limited to: (1) iSCSI protocol (Internet Small Computer System Interface): a storage protocol based on TCP / IP networks, suitable for IP network environments. (2) Fibre Channel Protocol (Fibre Channel Protocol). (3) InfiniBand protocol: A storage protocol based on the InfiniBand network, suitable for high-performance computing environments, with extremely high throughput and extremely low latency.

[0048] In an optional implementation, the present invention further includes: obtaining network environment parameters between the recovery client and the emergency backup system, and automatically selecting a target communication protocol from the communication protocols for storage volume mapping based on the network environment parameters.

[0049] The network environment parameters include: Network bandwidth ): The maximum amount of data that a network can transmit per unit of time, expressed in Mbps or Gbps; Network latency ): The data transmission delay from the sender to the receiver, in milliseconds (ms). Link Reliability The stability of a network link is represented by the link failure rate or packet loss rate, with a value range of [value missing]. The closer the value is to 1, the higher the reliability.

[0050] The decision logic for adaptive protocol selection is as follows: Let the set of available communication protocols be . ,in Indicates the iSCSI protocol. Indicates Fibre Channel protocol. This represents the InfiniBand protocol. For each protocol... Define its performance score in a given network environment. : ; in, Protocol The overall performance score (dimensionless real number) in the current network environment. The higher the score, the better the performance of the protocol in the current network environment. Protocol In the current network bandwidth Normalized theoretical transmission rate (dimensionless real number, range of values) This value is obtained through the query protocol. The transmission rate can be obtained from a table comparing different bandwidths, or by using a formula. Calculation, where For the agreement The theoretical maximum bandwidth; Protocol In the current network latency The round-trip time (in milliseconds) is specified via a protocol. In delay The round-trip time can be obtained by referring to the table below; Protocol Current link reliability The connection stability probability (dimensionless real number, range of values) This value is obtained through the protocol. The connection success rate comparison table under different reliability levels was obtained by querying the table. , , These are the weighting coefficients. ,and , , It can be adjusted according to the actual application scenario (for example, increasing the bandwidth in bandwidth-sensitive scenarios). Increase in latency-sensitive scenarios Increase in reliability-sensitive scenarios ); This means taking the reciprocal of the round-trip time, so that the smaller the delay, the higher the score for this item.

[0051] Select the protocol with the highest performance score as the target communication protocol. : ; in, Indicates in protocol set Selecting from the options allows for performance scoring. Protocol for obtaining the maximum value ; This indicates the target communication protocol that was ultimately selected.

[0052] For example, when the recovery client and the emergency backup system are connected via a high-speed Fibre Channel network, the network bandwidth is high and the latency is low, and the protocol adaptive selection step automatically selects the Fibre Channel protocol for mapping; when the network environment is a normal IP network, the iSCSI protocol is automatically selected for mapping.

[0053] S4. Mount the mapped target storage volume on the recovery client. .

[0054] In one optional implementation, step S4 specifically includes: S41. Obtain the target storage volume Mount parameters. Mount parameters refer to the configuration information required when mounting a storage volume on the recovery client, including: Mount Point Path ): In the file system of the recovery client, the directory path to which the target storage volume will be mounted; Read-write permission ): Specifies whether the mounted storage volume is accessed in read-only mode or read-write mode; Mount Options ): This includes file system type, block size, caching strategy, and other mount configurations.

[0055] In this invention, to ensure that the original backup data is not accidentally modified during the recovery process, read and write permissions are specified in the mount parameters. The default mode is read-only.

[0056] S42. Based on the obtained mount parameters, perform the mount operation of the storage volume on the recovery client.

[0057] The specific implementation of the mount operation depends on the type of operating system of the recovery client: for Linux systems, the mount operation can be implemented through the mount command or the corresponding system call; for Windows systems, the mount operation can be implemented through disk management tools or the corresponding API.

[0058] The mounting operation process includes: verifying the mount point path. Does the target storage volume exist (or be created automatically if it does not exist)? Mount point path Establish association and apply mount options. Configure the recovery client to access the mount point path. Access the target storage volume The data in the middle.

[0059] S43. Confirm the target storage volume Mounting successful. Specifically, after the mount operation is completed, verify the mount status using the following methods: (1) Check the return status code of the mount command or API call. If the return is successful, the mount is preliminarily confirmed to be successful. (2) Try on the mount point path Next, read the target storage volume's metadata information (such as volume label, file system type, available space, etc.). If the reading is successful, then the mounting is confirmed to be successful. (3) For read-only mode mounting, you can also try to perform a read-only operation to verify the accessibility of the data.

[0060] If mounting fails, a retry operation is performed. The retry strategy can employ the Exponential Backoff algorithm: Let the... The waiting time for the second retry is ,but: ; in, Indicates the current retry number (a dimensionless integer, starting from 1); Indicates the first Time to wait before the next retry (in seconds); Indicates the initial waiting time (in seconds), for example Second.

[0061] Wait after each retry The next mounting attempt will be performed after a certain time.

[0062] If the number of retries exceeds the preset threshold (For example If the number of retries is less than or equal to 1, a mount failure alarm will be generated. Mount failure alarms are sent to operations and maintenance personnel via logs, emails, SMS messages, or system notifications. The alarm content includes: target storage volume identifier, recovery client identifier, reason for failure, and number of retries.

[0063] S5. Based on recovery time point information In the target storage volume Search and recover time points The system retrieves the closest backup time point and its corresponding snapshot data. If incremental backup data exists after the closest backup time point, the snapshot data and incremental backup data are merged to generate the recovery time point. The corresponding complete backup data.

[0064] In a preferred embodiment of the present invention, the emergency backup system employs a backup strategy combining full backup and incremental backup. Specifically: Full Backup: A complete backup of the source data is performed at a specific point in time (e.g., 00:00 every day), generating a full backup snapshot. The full backup snapshot contains a complete copy of the source data at that point in time.

[0065] Incremental backup: Between full backups, periodically (e.g., hourly) backups are performed on the data that has changed since the last backup, generating incremental backup data. Incremental backup data only records the changed parts of the data and does not include unchanged data.

[0066] Using the backup strategy described above, the emergency backup system stores multiple full backup snapshots and multiple incremental backup data. Each backup data is stored in a backup index table. Each of these records has a corresponding record, which shows the backup time and data version information.

[0067] Find the backup closest to the backup time: Let the recovery time point information be... (Recovery Time Point). On the target storage volume There are multiple backup time points. Each backup point in time corresponds to a snapshot (full backup snapshot) or incremental backup data.

[0068] First, in all full backup snapshots, look for... closest and no later than Full backup time point : ; in, This indicates that the target full backup time point (timestamp type) found is the latest one among all full backup time points that meet the conditions; Indicates the target storage volume The first in One backup time point (timestamp type); Indicates the recovery time point specified by the user (timestamp type); Conditions in a set Ensure that the backup time is no later than the restore time. The corresponding backup is a full backup to ensure that the search is only performed in the full backup.

[0069] Get Corresponding full backup snapshot data .

[0070] Acquisition and merging of incremental backup data: Find the closest full backup time point Afterwards, it was determined that... after, Previously (including) Does incremental backup data exist?

[0071] If incremental backup data exists, let's assume this incremental backup data is arranged in chronological order as follows: The corresponding backup time point is ,satisfy: ; in, Indicates the total number of incremental backup data that need to be merged (dimensionless integer). Indicates the first Incremental backup data ( Each incremental backup records the data changes within a time interval; Indicates the first Each incremental backup data point corresponds to a backup time point (timestamp type) that satisfies a strict ascending order.

[0072] In one optional implementation, when merging snapshot data and incremental backup data, they are merged sequentially according to the chronological order of the incremental backup data. The merging process is as follows: Step 1: Perform a full backup of the snapshot data As basic data .

[0073] Step 2: For incremental backup data (corresponding time point) ),Will The data changes recorded in the middle are applied to Up, get the updated data Specifically, incremental backup data Recorded from arrive The data blocks that changed during the period and their new values, apply these changes to The corresponding data block can be used to obtain Data status at any given moment .

[0074] Step 3: For incremental backup data (corresponding time point) ),Will The data changes recorded in the middle are applied to Up, get And so on.

[0075] Step 4: Repeat the above process, applying the steps sequentially. Finally obtained That is, the recovery time point Corresponding complete backup data .

[0076] The above merging process can be expressed mathematically as follows: ; Or, equivalently, recursively defined as: ; ; ; in, This refers to the initial base data before the merge, i.e., the full backup snapshot data. ; Indicates before application Data obtained after incremental backups ( ); Indicates the first Incremental backup data The data changes recorded in the middle are applied to the data. Operation functions on; This indicates the final result relative to the recovery time point. The corresponding complete backup data.

[0077] Analysis of merging efficiency: Through the above-mentioned mechanism of "finding the full snapshot closest to the time point + merging only the incremental backups after that time point", the merging efficiency of the present invention is significantly better than that of the prior art.

[0078] Let's assume the time point from the full backup By recovery time There are a total of The existing technology (applying all incremental backups sequentially starting from the earliest full backup) requires a total of [number] incremental backups to be applied. The present invention only requires the application of... After Each incremental backup is the same number. However, the key point is: In the existing technology, if there is no... A perfectly aligned full backup typically requires applying all subsequent increments starting from the most recent previous full backup, which is consistent with this invention.

[0079] However, existing technologies lack backup index tables during the search phase. The support requires traversing all snapshots to locate the target full backup, resulting in a search time complexity of O(n log n). ,in This represents the total number of snapshots. This invention utilizes a backup index table. With a multi-level index structure, the search time complexity can be reduced to [missing information]. Levels, among which For the total number of snapshots, It represents the logarithm to the base 2.

[0080] Furthermore, existing technologies often require retrieving all incremental backup data from the backup storage during recovery, while this invention utilizes a backup index table. Precise positioning can be achieved by simply reading Subsequent incremental backups reduced unnecessary I / O operations. Let the total amount of incremental data to be read be... This invention only requires reading ,in Indicates the first The size of each incremental backup (in bytes).

[0081] Restore to the specified target path: Generation and recovery time points Corresponding complete backup data Afterwards, Restore to the specified target path Specify the target path It can be the original data storage path (i.e., overwrite recovery, writing the data back to the original location) or a user-specified alternative recovery path (i.e., cross-machine recovery or cross-directory recovery).

[0082] For overwrite recovery, the recovery operation will Write the data to the original data storage path, overwriting any existing corrupted data. Optionally, back up the original data before performing the overwrite recovery to prevent further data loss in case of recovery failure.

[0083] For cross-machine or cross-directory recovery, the recovery operation will... Write to the user-specified alternative path without affecting the original data.

[0084] In one alternative implementation, the emergency backup system employs a distributed storage architecture, comprising multiple backup storage nodes.

[0085] Distributed storage architecture includes the following components: Multiple backup storage nodes: Each backup storage node is an independent storage server with its own storage media (such as hard disk arrays, SSDs, etc.). The total number of backup storage nodes is... Each backup storage node is interconnected via a network to form a unified storage cluster.

[0086] Metadata Management Node: Responsible for managing backup index tables. It also collects storage node status information to coordinate data distribution and load balancing among storage nodes.

[0087] Client access interface: Provides a unified access point for recovery clients to connect to the storage cluster via communication protocols.

[0088] Backup data storage volume information includes primary backup storage node information and at least one replica backup storage node information.

[0089] When writing backup data, the emergency backup system uses synchronous or asynchronous replication to store the backup data simultaneously on both the primary backup storage node and the replica backup storage node. Specifically: Primary Backup Storage Node ): The primary replica stores backup data and is the preferred access node during data recovery; Replica Backup Storage Node ): Stores a copy of the backup data, serving as a backup access node when the primary node is unavailable.

[0090] Each backup data storage volume This corresponds to one primary replica and at least one replica. Let the number of replicas be... It can be based on the importance level of the data. Sure: ; in, Indicates the number of copies (dimensionless integer); Indicates the importance level of the data (dimensionless integer, with a value of 1, 2 or 3).

[0091] When the primary backup storage node When unavailable, automatically switch to the replica backup storage node. Perform storage volume mapping.

[0092] Primary backup storage node The conditions for determining unusable conditions include: (1) Master node Heartbeat signal loss exceeds a preset time threshold (Unit: seconds); (2) Master node The storage device malfunctioned and was unable to respond to read and write requests; (3) Master node The network connection between the client and the recovery client was interrupted.

[0093] When the master node is detected When unavailable, the emergency backup system automatically performs a failover process: Step 1: Back up the index table Querying and Target Storage Volumes Corresponding replica backup storage node information .

[0094] Step 2: Select an available replica backup storage node according to a preset priority order (e.g., based on the replica node's network distance, load status, etc.). Availability is determined by the following conditions: the node heartbeat is normal and the storage device is in good condition.

[0095] Step 3: Map the target address of the storage volume from the master node address. Switch to the selected replica node address : ; in, Indicates the target address (string type) of the storage volume mapping; Indicates the network address (string type) of the primary backup storage node; Indicates the first The network address (string type) of each replica backup storage node.

[0096] Through the above-mentioned automatic failover mechanism, even the primary and backup storage nodes In the event of a failure, recovery operations can still be performed through replica nodes. The mission was successfully completed, significantly improving the reliability of emergency recovery.

[0097] In one optional implementation, the data to be recovered is meteorological monitoring data or environmental monitoring data. This data has the following characteristics: Strong temporal sequence: Data is collected and recorded at fixed time intervals (such as every minute or every hour), and the time dimension is the core dimension for data organization and retrieval; Multi-site distribution: Data comes from multiple monitoring stations (such as meteorological stations, air quality monitoring stations, hydrological monitoring stations, etc.), and each station generates data independently; Multiple data types: including temperature, humidity, air pressure, wind speed, wind direction, PM2.5 concentration, PM10 concentration, sulfur dioxide concentration, nitrogen dioxide concentration and other monitoring indicators.

[0098] Identification information of data to be recovered include: Monitoring Station ID ): Used to uniquely identify the meteorological or environmental monitoring station that generates the data. For example, It could be "BJ-101" (Beijing Monitoring Station No. 101); Monitoring Data Type ID ): Used to identify the type of monitoring indicator for the data. For example, It can be "TEMP" (temperature), "HUMI" (humidity), "PM25" (PM2.5 concentration), etc.; Monitoring Time Period ID ): Used to identify the time period corresponding to the data. For example, It could be "2026-07-30-00:00:00_to_2026-07-30-23:59:59".

[0099] Data identification information This can be represented in triplet form as: ; in, Indicates the monitoring site identifier (string type); Indicates the data type identifier (string type) being monitored; Indicates the monitoring time period identifier (string type or timestamp range).

[0100] Backup index table The system also records the monitoring site information and monitoring data type information corresponding to each backup data.

[0101] Specifically, back up the index table. In addition to the basic fields, the following fields are expanded, as shown in Table 2: Table 2

[0102] The extended backup index table query conditions can be expressed as: ; in, Indicates the target monitoring site identifier (string type); Indicates the target monitoring data type identifier (string type); Indicates the start time of the time period for which data to be recovered (timestamp type); Indicates the end time of the time period for which data to be recovered (timestamp type); This indicates the recovery time point (timestamp type), that is, the data state restored to that moment.

[0103] Taking a certain meteorological monitoring station ( Temperature data () Taking the data corruption that occurred at 14:30 on July 30, 2026 as an example, the recovery process of this invention is explained as follows: Step 1: The emergency trigger detection step detects corrupted temperature data (anomalies are found through checksum comparison) and automatically generates a data recovery request. The data recovery request includes: Recovery time point (5 minutes before the damage occurred).

[0104] Step Two: Backup Index Query Steps and In the backup index table Querying in the middle. Due to backing up the index table. According to monitoring station information and monitoring data type information An index has been created, allowing queries to quickly locate all backup records of "TEMP" type data for the "BJ-101" site.

[0105] Step 3: In the query results, find and restore the time point. The closest full backup time (e.g., a full backup at 00:00 on the same day) (and incremental backup data after that point in time) .

[0106] Step 4: Full backup of snapshot data With subsequent incremental backup data Merge according to time order, following the formula. Generate complete temperature data for 14:25:00 on 2026-07-30.

[0107] Step 5: Write the recovered temperature data back to the specified target path The recovery is complete.

[0108] Through the above process, the data from the meteorological monitoring station can be quickly restored to its pre-damage state after an anomaly occurs, ensuring the continuity of meteorological monitoring operations and the integrity of the data.

[0109] The method, apparatus, and computer equipment for rapidly restoring backup data based on an emergency backup system provided by this invention can be widely applied in the following scenarios: 1. Meteorological monitoring field: Used for emergency recovery of meteorological monitoring data to ensure the continuity of weather forecasting and early warning services; 2. Environmental monitoring field: Used for emergency recovery of environmental monitoring data (air quality, water quality, soil, etc.) to ensure the normal operation of environmental monitoring services; 3. Financial sector: Used for emergency recovery of financial transaction data, ensuring the continuity of financial operations and data integrity; 4. Industrial control field: Used for emergency recovery of data in industrial control systems to ensure the continuity and security of industrial production; 5. Government and enterprise IT sectors: Used for emergency data recovery of various government and enterprise information systems.

[0110] The method of this invention can be deployed and implemented on the basis of existing emergency backup systems without large-scale modifications to production systems, and has good compatibility and scalability.

[0111] Although embodiments of the invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the invention, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A method for rapidly restoring backup data based on an emergency backup system, characterized in that, include: S1. Monitor the operating status of the production system in real time. When a preset type of abnormal event is detected in the production system, automatically generate a data recovery request. The data recovery request carries the identification information of the data to be recovered and the recovery time point information. S2. Based on the identification information of the data to be recovered, query the backup data storage volume information corresponding to the data to be recovered in the backup index table of the emergency backup system. The backup index table records at least the storage location, backup time point and data version information of each backup data storage volume. S3. Determine the target storage volume based on the queried backup data storage volume information, and map the target storage volume to the recovery client through a communication protocol; S4. Mount the mapped target storage volume on the recovery client; S5. Based on the recovery time point information, find the backup time point closest to the recovery time point in the target storage volume and obtain the corresponding snapshot data. If there is incremental backup data after the closest backup time point, merge the snapshot data and the incremental backup data to generate complete backup data corresponding to the recovery time point, and restore the complete backup data to the specified target path.

2. The method according to claim 1, characterized in that, The preset types of abnormal events include system crashes, storage device failures, data corruption, and human error. In step S1, when the abnormal event is detected in the production system, a recovery priority is determined according to the type of the abnormal event, and a data recovery operation is performed according to the recovery priority.

3. The method according to claim 1, characterized in that, The backup index table is a multi-level index structure built according to the importance level and data type of the data. The data types include time-series data, structured data, and unstructured data. In step S2, when querying the backup index table based on the identification information of the data to be recovered, the index level corresponding to the data type and importance level of the data to be recovered is matched first.

4. The method according to claim 1, characterized in that, In S3, the communication protocol is selected from at least one of the iSCSI protocol, Fibre Channel protocol, and InfiniBand protocol; The method further includes: obtaining network environment parameters between the recovery client and the emergency backup system, the network environment parameters including network bandwidth, network latency and link reliability, and automatically selecting a target communication protocol from the communication protocols for storage volume mapping based on the network environment parameters.

5. The method according to claim 1, characterized in that, S4 specifically includes: S41. Obtain the mount parameters of the target storage volume, the mount parameters including mount point path, read and write permissions and mount options; S42. According to the mount parameters, mount the target storage volume in read-only mode on the recovery client; S43. Confirm that the target storage volume is successfully mounted. If the mounting fails, perform a retry operation and generate a mounting failure alarm when the number of retries exceeds a preset threshold.

6. The method according to claim 1, characterized in that, In step S5, the snapshot data is full backup snapshot data; the incremental backup data is multiple incremental backup data from the backup time point of the full backup snapshot data to the recovery time point; when merging the snapshot data and the incremental backup data, they are merged sequentially according to the time order of the incremental backup data.

7. The method according to claim 1, characterized in that, The emergency backup system adopts a distributed storage architecture, including multiple backup storage nodes; the backup data storage volume information includes primary backup storage node information and at least one replica backup storage node information; In step S3, when the primary backup storage node is unavailable, the system automatically switches to the replica backup storage node for storage volume mapping.

8. The method according to claim 1, characterized in that, The data to be recovered is meteorological monitoring data or environmental monitoring data. The identification information of the data to be recovered includes the monitoring station identifier, the monitoring data type identifier, and the monitoring time period identifier. The backup index table also records the monitoring station information and monitoring data type information corresponding to each backup data.

Images