Unified data backup and disaster recovery equipment

Abstract

The invention relates to unified data backup and disaster recovery equipment, in particular to the field of data security, and specifically comprises a data backup module, a disaster recovery module and a recovery verification module, the data backup module is used for carrying out data fragmentation on data needing to be backed up, then carrying out Hash processing on each data block by utilizing a Hash function, distributing each data fragment to a plurality of backup nodes, registering a Hash value of the data fragment on a block chain by the backup nodes, and storing the Hash value on the corresponding backup node; in the storage process, a smart contract is utilized to manage data backup operation according to a preset rule, and by utilizing the characteristics of decentralization and non-tampering provided by a block chain technology, security guarantee of data backup can be realized in backup and disaster recovery, the problems of security and consistency of traditional centralized backup are solved, and data backup efficiency is improved. And through a block chain technology, distributed storage of the data can be realized, and it is ensured that the data is not tampered in a backup process.

Description

Technical Field

[0001] The present invention relates to the field of data security, and more specifically, to a unified data backup and disaster recovery device. Background Art

[0002] In modern enterprise and personal applications, data backup and disaster recovery are key components to ensure business continuity and data security. With the rapid development of information technology, the amount of data has increased dramatically, and traditional backup and recovery methods are facing a series of challenges. At present, data backup and disaster recovery technologies can be mainly divided into two categories: backup solutions based on local storage and backup solutions based on cloud storage. Existing backup solutions based on local storage, such as tape backup and hard disk backup, can provide fast backup and recovery speeds, but there is a risk of data loss and cannot provide effective disaster recovery in the event of a major disaster. Backup solutions based on cloud storage, although they can provide higher disaster recovery capabilities and flexibility, are often slow to recover large amounts of data due to network bandwidth and data transmission limitations, and data security during transmission is difficult to guarantee.

[0003] However, current backup and disaster recovery solutions often encounter the following problems in actual applications:

[0004] Data consistency issues: In a complex distributed environment, data backup may encounter consistency issues. For example, when multiple databases are updated at the same time, how to ensure that the backed-up data remains consistent during disaster recovery to avoid partial data loss or inconsistency.

[0005] Insufficient data security: Many backup solutions lack effective data encryption and anti-tampering mechanisms, making them vulnerable to data leakage and tampering. Summary of the invention

[0006] The present invention aims at the technical problems existing in the prior art and provides a unified data backup and disaster recovery device, which solves the problems raised in the above background technology through modules and modules.

[0007] The technical solution of the present invention to solve the above technical problem is as follows: it specifically includes a data backup module, a disaster recovery module and a recovery verification module;

[0008] Data backup module: the data to be backed up is divided into data shards, and then each data block is hashed using a hash function, and each data shard is distributed to multiple backup nodes. At the same time, the backup node registers the hash value of the data shard on the blockchain and stores it on the corresponding backup node. During the storage process, smart contracts are used to manage data backup operations according to pre-set rules;

[0009] Disaster recovery module: When a disaster or data loss occurs in the system, the user or application actively initiates a data recovery request. The smart contract checks the legitimacy of the request, selects a valid backup copy using the consensus mechanism, and starts restoring data based on the backup record.

[0010] Recovery verification module: During recovery, the smart contract verifies the hash value of the backup data to ensure that the data has not been tampered with. The hash value of the restored data will be recalculated and compared with the hash value on the backup node to ensure consistency. After the recovery is completed, the records on the blockchain will be automatically updated and the data recovery will be marked as successful.

[0011] In a preferred embodiment, the data backup module uses a hash function to divide the data (D) into (n) data fragments (D_1, D_2, ..., D_n), and calculates the hash value of each data fragment (D_i). The specific calculation formula is:

[0012]

[0013] Among them, (H) represents a hash function, (H(D_i)) represents the hash value of each data shard (D_i), (D_i) represents the i-th data shard, and Hash(D_i) represents a hash operation, that is, the hash value obtained by processing the data (D_i) through the hash function (H).

[0014] In a preferred embodiment, the data backup module uses a redundant storage strategy to store each data shard in multiple backup nodes. At the same time, the hash value of each data shard is recorded through the blockchain as the unique identifier of the data shard, and is stored on the corresponding backup node together with the timestamp of the hash value of each data shard recorded on the blockchain.

[0015] In a preferred embodiment, when new backup data is added to the data backup module, the smart contract verifies whether the data hash value is consistent with the on-chain record according to preset rules;

[0016] If it is verified that the data hash value is consistent with the on-chain record, the data backup is confirmed to be valid. If it is verified that the data hash value is inconsistent with the on-chain record, the data backup is confirmed to be invalid.

[0017] In a preferred embodiment, the smart contract preset rule is specifically: the data backup is confirmed to be valid only when the hash value of the backup data is consistent on at least two backup nodes.

[0018] In a preferred embodiment, the data recovery request received by the disaster recovery module includes the following information: S1, data identifier (D_i): the identifier of the data slice or file requested to be recovered; S2, the reason for recovery; S3, recovery timestamp: the requested recovery time; S4, requester information: the identity of the requester;

[0019] Based on the received recovery request, the smart contract checks the legitimacy of the request using a legitimacy check formula, and the legitimacy check formula of the smart contract is:

[0020]

[0021] Among them, R.user_id represents the identity of the requester, Valid_Users represents the set of users with recovery permissions, R.data_id represents the data identifier requested for recovery, and Data_Registry represents the valid data shard registration table. If the request is invalid, the smart contract will reject the recovery request. If it is legal, it will proceed to the next step.

[0022] In a preferred embodiment, when the disaster recovery module selects a valid backup copy using a consensus mechanism and restores data according to the backup record, the calculation formula of the consensus mechanism is:

[0023]

[0024] Wherein, I represents the indicator function. When the hash value H(D_i)Node_j on node j is consistent with that of the majority of nodes, I=1, otherwise I=0. The majority hash value H(D_i)majority represents the hash value that appears most frequently among all nodes. If the data stored in more than half of the nodes is consistent, the backup copy of the data shard is considered valid. (H(D_i)) represents the hash value of each data shard (D_i), k represents the number of backup nodes, and Consensus(H(D_i)) represents the final consensus result.

[0025] In a preferred embodiment, during the recovery process, the recovery verification module first retrieves the original data (D_i) from the backup node of the data backup module, and then recalculates the hash value of the recovered data (H(D_i)recovered), and compares it with the hash value of the backup node H(D_i)Node_j to ensure that the data has not been tampered with, wherein the calculation formula for recalculating the hash value of the recovered data is:

[0026]

[0027] In a preferred embodiment, the hash consistency verification formula is:

[0028]

[0029] Among them, I represents the indicator function. If the hash value of the restored data is consistent with the hash value on the backup node, the indicator function returns 1, indicating that the data has not been tampered with, and then proceeds to the next step; otherwise, it returns 0, indicating that the data may have been tampered with. At this time, the recovery process is terminated and a warning is issued to indicate that the data has been tampered with.

[0030] In a preferred embodiment, after the recovery verification module successfully verifies the recovery process, the smart contract will update the record on the blockchain to mark the successful data recovery. The specific update includes recording the recovered data status, timestamp and related transaction information.

[0031] In a preferred embodiment, the method specifically includes the following steps:

[0032] The beneficial effects of the present invention are as follows: by utilizing the decentralized and tamper-proof characteristics provided by blockchain technology, the present application can be used for backup and disaster recovery to achieve security protection for data backup, solve the security and consistency issues of traditional centralized backup, and through blockchain technology, it can realize distributed storage of data and ensure that data is not tampered with during the backup process. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] Figure 1 is a flow chart of the method of the present invention;

[0034] Figure 2 This is a system structure block diagram of the present invention. DETAILED DESCRIPTION

[0035] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of this application.

[0036] In the description of this application, the terms "first" and "second" are used for descriptive purposes only and should not be understood as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of the features. In the description of this application, "plurality" means two or more, unless otherwise clearly and specifically defined.

[0037] In the description of the present application, the term "for example" is used to mean "used as an example, illustration or description". Any embodiment described as "for example" in the present application is not necessarily to be construed as being more preferred or advantageous than other embodiments. The following description is given to enable any technician in the field to implement and use the present invention. In the following description, details are listed for the purpose of explanation. It should be understood that a person of ordinary skill in the art can recognize that the present invention can be implemented without using these specific details. In other examples, well-known structures and processes will not be elaborated in detail to avoid unnecessary details to obscure the description of the present invention. Therefore, the present invention is not intended to be limited to the embodiments shown, but is consistent with the widest scope consistent with the principles and features disclosed in the present application.

[0038] Example 1

[0039] This embodiment provides Figure 1-2 A unified data backup and disaster recovery device is shown, which specifically includes a data backup module, a disaster recovery module and a recovery verification module;

[0040] Data backup module: The data to be backed up is sharded into several data blocks, where the data source includes databases, file systems, etc., and then each data block is hashed using a hash function, and each data shard is distributed to multiple backup nodes. At the same time, the backup node registers the hash value of the data shard on the blockchain and stores it on the corresponding backup node. During the storage process, smart contracts are used to manage data backup operations according to pre-set rules;

[0041] Disaster recovery module: When a disaster or data loss occurs in the system, the user or application actively initiates a data recovery request. The smart contract checks the legitimacy of the request, selects a valid backup copy using the consensus mechanism, and starts restoring data based on the backup record.

[0042] Recovery verification module: During recovery, the smart contract verifies the hash value of the backup data to ensure that the data has not been tampered with. The hash value of the restored data will be recalculated and compared with the hash value on the backup node to ensure consistency. After the recovery is completed, the records on the blockchain will be automatically updated and the data recovery will be marked as successful.

[0043] In this embodiment, it should be specifically explained that the data backup module uses a hash function to divide the data (D) into (n) data fragments (D_1, D_2, ..., D_n), and calculates the hash value for each data fragment (D_i). The hash value is usually represented as a hexadecimal string, which is unique and unpredictable. The specific calculation formula is:

[0044]

[0045] Wherein, (H) represents a hash function, which is used to map input data (such as files, strings, etc.) to an output of a fixed length, usually a hash value. The output of the hash function is irreversible and generates different outputs for different inputs. Secondly, the hash function preferably used in this application is SHA-256, (H(D_i)) represents the hash value of each data shard (D_i), (D_i) represents the i-th data shard, Hash(D_i) represents a hash operation, that is, the hash value obtained by processing the data (D_i) through the hash function (H). For example, if (D_i) is a string (such as "hello"), at this time, the hash function SHA-256 is used for hash processing, and the specific calculation formula is:

[0046]

[0047] The data backup module uses a redundant storage strategy to store each data shard in multiple backup nodes. Usually, multiple copies of each data shard are distributed in different physical locations or servers. For example, data shard (D_1) will be stored on nodes A and B, data shard (D_2) will be stored on nodes C and D, and so on. At the same time, the hash value of each data shard is recorded through the blockchain as the unique identifier of the data shard, ensuring the immutability and verifiability of the data. The hash value is essentially the digital fingerprint of the data, which is used to confirm the integrity and uniqueness of the data content. For example: for data shard (D_1), The hash value (H(D_1)) is calculated through the hash function, and then (H(D_1)) is stored in the blockchain as a transaction or information. The record on the blockchain not only ensures the originality of the data, but also provides a timestamp (timestamp on the blockchain) to prove that the data exists at a specific time. The advantage of the above setting is that the blockchain itself has the characteristics of decentralization and immutability, which can provide strong anti-tampering protection for backup data, and the timestamp of the hash value of each data shard recorded by the blockchain is stored on the corresponding backup node. Each backup node will store the corresponding data shard. If the data shard (D_1) is stored on node A

[0048] and B, then nodes A and B will store copies of the data shards respectively. At the same time, each backup node will perform health checks regularly to ensure the integrity and accessibility of the data. For example, node A will store the data shard (D_1) and be responsible for providing access to the shard. Node B will also store the same shard in case of node A failure. By combining redundant storage with blockchain, this backup method can ensure high availability, security and verifiability of data, and even if node failure or data corruption occurs, it can ensure data integrity and recovery.

[0049] When new backup data is added to the data backup module, the smart contract verifies whether the data hash value is consistent with the on-chain record according to the preset rules. The smart contract is an automatically executed and unchangeable contract protocol that runs in the blockchain network and can automatically execute operations according to preset rules and conditions. In the scenario of this application, the task of the smart contract is to verify whether the hash value of the backup data is consistent with the on-chain record, thereby confirming the validity of the data. When a new data backup is added, the verification process of the smart contract is as follows:

[0050] S1, the data backup module receives a new backup data slice (D′i), i.e., a slice of the backup data;

[0051] S2. Perform hash calculation on the new backup data shard (D′i) using the SHA-256 hash function to obtain its hash value (H′(D′i)).

[0052] S3. The smart contract checks the hash value records stored in the blockchain according to the pre-set rules to confirm whether there is a hash value corresponding to (H′(D′i));

[0053] If the data hash value is verified to be consistent with the on-chain record, it means that the backup data has not been tampered with, the verification is passed, and the data backup is confirmed to be valid. If the data hash value is verified to be inconsistent with the on-chain record, it means that the backup data may have been tampered with or an error has occurred, the verification fails, and the data backup is confirmed to be invalid;

[0054] S4. According to the verification results, the smart contract will automatically perform the corresponding operations. For example:

[0055] D1. If the backup data is confirmed to be valid, the smart contract will mark the backup as "valid" and record it on the blockchain.

[0056] D2. If the backup data is confirmed to be invalid, the contract will reject the backup, mark it as "invalid", and may trigger an alarm or rollback operation;

[0057] In addition, the benefits of using smart contracts combined with blockchain for data verification in this application are:

[0058] Immutability: Records on the blockchain are immutable. Once the hash value is stored on the blockchain, no one can change it. Therefore, the hash value can serve as a strong proof of data integrity.

[0059] Automation and decentralization: Smart contracts automatically perform verification and processing on the blockchain without the need for centralized managers or intervention. The automation and decentralization of the verification process reduces human errors and operational risks.

[0060] Transparency and traceability: All operations are recorded on the blockchain, and the history of data backup and verification is public and traceable. Anyone can view the verification process and results;

[0061] The smart contract preset rules are specifically as follows: the data backup is confirmed to be valid only when the hash value of the backup data is consistent on at least 2 or more backup nodes. The number of backup nodes required to be consistent mentioned in the smart contract preset rules is determined by the number of nodes where the data shard (D_1) is stored. If the data shard (D_1) is stored in nodes A, B and C, the data backup is confirmed to be valid only when the hash value of the backup data is consistent on the three backup nodes.

[0062] In this embodiment, the disaster recovery module specifically needs to be explained. The data recovery request received by the disaster recovery module includes the following information: S1, data identifier (D_i): the identifier of the data slice or file requested to be recovered; S2, the reason for recovery (for example: system crash, data loss, etc.); S3, recovery timestamp: the requested recovery time; S4, requester information: the identity of the requester;

[0063] Based on the received recovery request, the smart contract checks the legitimacy of the request using a legitimacy check formula, and the legitimacy check formula of the smart contract is:

[0064]

[0065] Among them, R.user_id represents the identity of the requester, Valid_Users represents the set of users with recovery permissions, R.data_id represents the data identifier requested for recovery, and Data_Registry represents the valid data shard registry. If the request is invalid, the smart contract will reject the recovery request. If it is legal, it will proceed to the next step. This formula means that when the identity of the requester is in the valid user list and the requested data identifier is in the valid data shard registry, 1 is returned and the recovery request is considered legal. Otherwise, 0 is returned to indicate that it is illegal.

[0066] When the disaster recovery module uses the consensus mechanism to select a valid backup copy and restore data based on the backup record, the calculation formula of the consensus mechanism is:

[0067]

[0068] Where I represents the indicator function. When the hash value H(D_i)Node_j on node j is consistent with the majority of nodes, I=1, otherwise I=0. The majority hash value H(D_i)majority represents the hash value with the highest frequency among all nodes. If the data stored by more than half of the nodes are consistent (i.e., the consistency condition is met), the backup copy of the data shard is considered valid. (H(D_i)) represents the hash value of each data shard (D_i), k represents the number of backup nodes (i.e., the number of nodes storing the data shard), and Consensus(H(D_i)) represents the final consensus result, which is usually a condition or function, indicating whether the data shard has been verified and meets the backup consistency. The calculation formula for its consistency condition is:

[0069]

[0070] Consensus Threshold represents the consistency threshold, which is used to evaluate whether the nodes in this application have reached a consistent state. It represents the sum of nodes, and sums each node from j=1 to j=k, k represents the total number of nodes, and I[·] represents the indicator function, which is a conditional judgment function that returns 1 if the condition in the brackets is true, otherwise it returns 0. In this formula, It means that if the (H(D_i)) value of node j is the same as the (H(D_i)) value of most nodes, then the indicator function returns 1; otherwise it returns 0. H(D_i)Node_j represents the hash value of the data (D_i) on node j or the value of a specific identifier H. Here (D_i) is the number or identifier of the data or information. H(D_i)Nodej represents the hash value or processing result of node j for (D_i). H(D_i)majority represents the hash value or processing result of most nodes for data (D_i), which usually refers to the (H(D_i)) value that appears the most times among all nodes. It represents half of k (number of nodes), rounded up. After the consistency check passes, the smart contract confirms that the data backup copy is valid, and then selects the valid backup copy with the same hash value according to the consensus result of Consensus (H(D_i)), and starts to restore data according to the backup record.

[0071] In this embodiment, it is specifically necessary to explain the recovery verification module. During the recovery process, the recovery verification module first retrieves the original data (D_i) from the backup node of the data backup module, and then recalculates the hash value of the recovered data (H(D_i)recovered), and compares it with the hash value of the backup node H(D_i)Node_j to ensure that the data has not been tampered with. The calculation formula for recalculating the hash value of the recovered data is:

[0072]

[0073] The hash consistency verification formula is:

[0074]

[0075] Where I represents the indicator function. If the hash value of the restored data is consistent with the hash value on the backup node, the indicator function returns 1, indicating that the data has not been tampered with, and then proceeds to the next step; otherwise, it returns 0, indicating that the data may have been tampered with. At this time, the recovery process is terminated and a warning is issued to indicate that the data has been tampered with;

[0076] After the recovery verification module successfully verifies the recovery process, the smart contract will update the record on the blockchain to mark the successful data recovery. The specific update includes recording the recovered data status, timestamp, and related transaction information.

[0077] It should be noted that in the above embodiments, the description of each embodiment has its own emphasis, and for parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0078] Those skilled in the art will appreciate that embodiments of the present invention may be provided as methods, systems, or computer program products. Therefore, the present invention may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0079] The present invention is described with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded computer, or other programmable data processing device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0080] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture including an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0081] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process in the computer or other programmable device. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0082] Although the preferred embodiments of the present invention have been described, those skilled in the art may make other changes and modifications to these embodiments once they have learned the basic creative concept. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications that fall within the scope of the present invention.

[0083] Obviously, those skilled in the art can make various changes and modifications to the present invention without departing from the spirit and scope of the present invention. Thus, if these modifications and variations of the present invention fall within the scope of the claims of the present invention and their equivalents, the present invention is also intended to include these modifications and variations.

Claims

1. A unified data backup and disaster recovery device, characterized in that: Specifically including data backup module, disaster recovery module and recovery verification module; Data backup module: the data to be backed up is divided into data shards, and then each data block is hashed using a hash function, and each data shard is distributed to multiple backup nodes. At the same time, the backup node registers the hash value of the data shard on the blockchain and stores it on the corresponding backup node. During the storage process, smart contracts are used to manage data backup operations according to pre-set rules; Disaster recovery module: When a disaster or data loss occurs in the system, the user or application actively initiates a data recovery request. The smart contract checks the legitimacy of the request, selects a valid backup copy using the consensus mechanism, and starts restoring data based on the backup record. Recovery verification module: During recovery, the smart contract verifies the hash value of the backup data to ensure that the data has not been tampered with. The hash value of the restored data will be recalculated and compared with the hash value on the backup node to ensure consistency. After the recovery is completed, the records on the blockchain will be automatically updated and the data recovery will be marked as successful.

2. The unified data backup and disaster recovery device according to claim 1, characterized in that: The data backup module uses a hash function to divide the data (D) into (n) data slices (D_1, D_2, ..., D_n), and calculates the hash value of each data slice (D_i). The specific calculation formula is: [H(D_i)=Hash(D_i)] Among them, (H) represents a hash function, (H(D_i)) represents the hash value of each data shard (D_i), (D_i) represents the i-th data shard, and Hash(D_i) represents a hash operation, that is, the hash value obtained by processing the data (D_i) through the hash function (H).

3. The unified data backup and disaster recovery device according to claim 2, characterized in that: The data backup module uses a redundant storage strategy to store each data shard in multiple backup nodes. At the same time, the hash value of each data shard is recorded through the blockchain as the unique identifier of the data shard, and is stored on the corresponding backup node together with the timestamp of the hash value of each data shard recorded on the blockchain.

4. The unified data backup and disaster recovery device according to claim 3, characterized in that: When new backup data is added to the data backup module, the smart contract verifies whether the data hash value is consistent with the on-chain record according to the preset rules; If it is verified that the data hash value is consistent with the on-chain record, the data backup is confirmed to be valid. If it is verified that the data hash value is inconsistent with the on-chain record, the data backup is confirmed to be invalid.

5. The unified data backup and disaster recovery device according to claim 4, characterized in that: The smart contract preset rule is specifically: the data backup is confirmed to be valid only when the hash value of the backup data is consistent on at least two backup nodes.

6. The unified data backup and disaster recovery device according to claim 5, characterized in that: The data recovery request received by the disaster recovery module includes the following information: S1, data identifier (D_i): the identifier of the data slice or file requested to be recovered; S2, reason for recovery; S3, recovery timestamp: request recovery time; S4, requester information: the identity of the requester; Based on the received recovery request, the smart contract checks the legitimacy of the request using a legitimacy check formula, and the legitimacy check formula of the smart contract is: Among them, R.user_id represents the identity of the requester, Valid_Users represents the set of users with recovery permissions, R.data_id represents the data identifier requested for recovery, and Data_Registry represents the valid data shard registration table. If the request is invalid, the smart contract will reject the recovery request. If it is legal, it will proceed to the next step.

7. The unified data backup and disaster recovery device according to claim 6, characterized in that: When the disaster recovery module selects a valid backup copy using the consensus mechanism and restores data according to the backup record, the calculation formula of the consensus mechanism is: Wherein, I represents the indicator function. When the hash value H(D_i)Node_j on node j is consistent with that of the majority of nodes, I=1, otherwise I=0. The majority hash value H(D_i)majority represents the hash value that appears most frequently among all nodes. If the data stored in more than half of the nodes is consistent, the backup copy of the data shard is considered valid. (H(D_i)) represents the hash value of each data shard (D_i), k represents the number of backup nodes, and Consensus(H(D_i)) represents the final consensus result.

8. The unified data backup and disaster recovery device according to claim 7, characterized in that: During the recovery process, the recovery verification module first retrieves the original data (D_i) from the backup node of the data backup module, then recalculates the hash value of the recovered data (H(D_i)recovered) and compares it with the hash value of the backup node H(D_i)Node_j to ensure that the data has not been tampered with. The calculation formula for recalculating the hash value of the recovered data is: [H(D_i)recovered=Hash(D_i)].

9. The unified data backup and disaster recovery device according to claim 8, characterized in that: The hash consistency verification formula is: Among them, I represents the indicator function. If the hash value of the restored data is consistent with the hash value on the backup node, the indicator function returns 1, indicating that the data has not been tampered with, and then proceeds to the next step; otherwise, it returns 0, indicating that the data may have been tampered with. At this time, the recovery process is terminated and a warning is issued to indicate that the data has been tampered with.

10. The unified data backup and disaster recovery device according to claim 9, characterized in that: After the recovery verification module successfully verifies the recovery process, the smart contract will update the record on the blockchain to mark the successful data recovery. The specific update includes recording the recovered data status, timestamp and related transaction information.

Images