CN117453454A

CN117453454A - Data backup method, device, computer equipment, medium and product

Info

Publication number: CN117453454A
Application number: CN202311354081.0A
Authority: CN
Inventors: 时一防; 王宗友; 聂凯轩; 刘区城; 朱耿良; 廖志勇; 黄杨峻; 刘汉卿
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2023-10-18
Filing date: 2023-10-18
Publication date: 2024-01-26

Abstract

The embodiment of the application discloses a data backup method, a device, computer equipment, a medium and a product, wherein the method comprises the following steps: generating a target modified pipeline record based on the modifying operation when the modifying operation of the data is detected on the blockchain of the target blockchain node; storing the target modified running water record in a running water storage area; when detecting that the data backup requirement exists, acquiring the backed-up first block height in the historical backup data of the backup storage area, and acquiring the second block height of the latest block in the block chain; determining incremental backup data from the pipelined storage region and the blockchain based on the first block height and the second block height, and storing the incremental backup data in the backup storage region; the dynamic incremental backup of the block chain data can be realized, and the time and the storage space required by the backup are reduced.

Description

Data backup method, device, computer equipment, medium and product

Technical Field

The present disclosure relates to the field of blockchain technologies, and in particular, to a data backup method, apparatus, computer device, medium, and product.

Background

The blockchain is a decentralized distributed ledger, multiple parties maintain, and data cannot be tampered with. A blockchain is a chain of blocks, each of which holds certain data, which are linked in a respective time sequence. In order to avoid failure at the block link point, which results in loss of data on the blockchain, data backup of the data on the blockchain is often required. Currently, in the operation of backing up data on a blockchain, it is generally required to backup all data on the blockchain once when a blockchain link point is in a shutdown state, and the backup of a large amount of data requires a long time and also requires a large storage space to store the backup data.

Disclosure of Invention

The embodiment of the application provides a data backup method, a data backup device, computer equipment, media and products, which can realize the dynamic incremental backup of block chain data and reduce the time and storage space required by backup.

In a first aspect, an embodiment of the present application provides a data backup method, including:

generating a target modified pipeline record based on a modification operation of data when the modification operation is detected on a blockchain of a target blockchain node;

Storing the target modified running water record in a running water storage area;

when detecting that the data backup requirement exists, acquiring the backed-up first block height in the historical backup data of the backup storage area, and acquiring the second block height of the latest block in the block chain;

and determining incremental backup data from the pipeline storage area and the blockchain based on the first block height and the second block height, and storing the incremental backup data in the backup storage area.

In a second aspect, an embodiment of the present application provides a data backup apparatus, including:

a processing unit configured to generate a target modified pipeline record based on a modification operation of data when the modification operation is detected on a blockchain of a target blockchain node;

a storage unit for storing the target modified running water record in a running water storage area;

the processing unit is further configured to, when detecting that a data backup requirement exists, obtain a backed-up first block height in historical backup data of a backup storage area, and obtain a second block height of a latest block in the block chain;

the storage unit is further configured to determine incremental backup data from the pipelined storage area and the blockchain based on the first block height and the second block height, and store the incremental backup data in the backup storage area.

In a third aspect, embodiments of the present application provide a computer device comprising a processor and a memory, wherein the memory is configured to store a computer program comprising program instructions, the processor being configured to invoke the program instructions to perform some or all of the steps of the above-described method.

In a fourth aspect, embodiments of the present application also provide a computer readable storage medium storing a computer program comprising program instructions for performing part or all of the steps of the above method when executed by a processor.

In a fifth aspect, embodiments of the present application also provide a computer program product or computer program comprising program instructions which, when executed by a processor, implement some or all of the steps of the above-described method.

In the embodiment of the application, when the modification operation of the data is detected on the blockchain of the target blockchain node, the target modification pipeline record can be generated based on the modification operation; and the target modified running water record can be stored in the running water storage area; when detecting that the data backup requirement exists, acquiring the backed-up first block height in the historical backup data of the backup storage area, and acquiring the second block height of the latest block in the block chain; the incremental backup data is determined from the pipelined storage region and the blockchain based on the first block height and the second block height, and the incremental backup data may be stored in the backup storage region. By implementing the method, the method for realizing the dynamic incremental backup by recording the modification flow of the nodes is provided, and only partial block chain data can be backed up instead of the whole block chain data in the data backup process, so that the time and the storage space required by backup can be greatly reduced, and the backup efficiency is further effectively improved.

Drawings

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings that are required in the embodiments or the description of the prior art will be briefly described below, it being obvious that the drawings in the following description are only some embodiments of the present application, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.

FIG. 1a is a schematic diagram of a data sharing system according to an embodiment of the present application;

FIG. 1b is a schematic block diagram of a block composition according to an embodiment of the present disclosure;

FIG. 1c is a flow chart of a new block generation provided by an embodiment of the present application;

FIG. 1d is a schematic block diagram illustrating another block configuration according to the embodiments of the present application;

FIG. 2 is a schematic flow chart of a data backup method according to an embodiment of the present application;

FIG. 3a is a schematic diagram of a determination that a data backup requirement exists provided by an embodiment of the present application;

FIG. 3b is a schematic diagram of a backup block determination structure according to an embodiment of the present application;

FIG. 4 is a flowchart illustrating another data backup method according to an embodiment of the present disclosure;

FIG. 5 is a schematic structural diagram of a data backup device according to an embodiment of the present disclosure;

fig. 6 is a schematic structural diagram of a computer device according to an embodiment of the present application.

Detailed Description

The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application.

For a better understanding of aspects of embodiments of the present application, related terms and concepts that may be related to embodiments of the present application are described below.

Embodiments of the present application relate to blockchain networks, and related terms and concepts of blockchain networks are briefly described below:

the blockchain network 10 refers to a network for data sharing between nodes, and a plurality of nodes 101 may be included in the blockchain network, where the plurality of nodes 101 may include nodes of various types such as consensus nodes, full nodes, light nodes (e.g., SPV (Simplified Payment Verification, simple payment verification) nodes), and the like. A full node may refer to a node that maintains a complete blockchain in a blockchain network, a light node may refer to a node that maintains a blockhead in the blockchain, and a light node may be understood as a node that does not own a finished blockchain. Each node 101 may receive input information while operating normally and maintain shared data (i.e., blockchains) within the blockchain network based on the received input information.

Wherein different nodes in the blockchain network may store a same blockchain that includes a series of blocks (blocks) that succeed each other in chronological order of generation. Nodes herein may refer to nodes that maintain a complete blockchain in a blockchain network, such as the full nodes described above, consensus nodes, and the like. Block 1, block M-1, etc., as shown in fig. 1a, M being a positive integer greater than 1; the new block, once added to the blockchain, is no longer removed, and the recorded data submitted by nodes in the blockchain network is recorded in the block. In order To ensure information intercommunication in the blockchain network, information connection can exist between every two nodes, point-To-point (Peer To Peer) communication can be realized between any two nodes, and in particular, point-To-point communication can be performed through a wired communication link or a wireless communication link. For example, when any node in the blockchain network receives input information, other nodes acquire the input information according to a consensus algorithm, and store the input information as data in shared data, so that the data stored on all nodes in the blockchain network are consistent.

The client 102 may access the blockchain network and may communicate with nodes in the blockchain network, e.g., send data backup requests to the nodes, etc. The terminal where the client 102 is located may specifically be a smart phone, a tablet computer, a notebook computer, a desktop computer, an on-board smart terminal, etc., which is not limited in this embodiment.

It should be noted that the number of nodes shown in fig. 1a is merely illustrative, and any number of nodes may be deployed according to actual needs, where the nodes may refer to any form of computer device in an access network, such as a server, and a terminal, all may join to become nodes.

Each node in the blockchain network has a node identifier corresponding to the node identifier, and each node in the blockchain network can store the node identifiers of other nodes in the blockchain network, so that the generated blocks can be broadcast to other nodes in the blockchain network according to the node identifiers of the other nodes. Each node can maintain a node identification list shown in the following table, and the node names and the node identifications are correspondingly stored in the node identification list. The node identifier may be an internet protocol (Internet Protocol, IP) address, or any other information that can be used to identify the node, and the table is described only by way of example as an IP address.

Node name	Node identification
		Node 1	117.114.151.174
Node 2	117.116.189.145
		…	…
Node N	119.123.789.258

Wherein each node in the blockchain network stores one and the same blockchain. The blockchain is composed of a plurality of blocks, see fig. 1b, the blockchain is composed of a plurality of blocks, the starting block comprises a block head and a block main body, the block head stores an input information characteristic value, a version number, a time stamp and a difficulty value, and the block main body stores input information; the next block of the starting block takes the starting block as a father block, the next block also comprises a block head and a block main body, the block head stores the input information characteristic value (or referred to as a merck root hash value, a merkle_root and the like) of the current block, the block head characteristic value (or referred to as a prev_hash and the like) of the father block, the version number, the time stamp and the difficulty value, and the like, so that the block data stored in each block in the block chain is associated with the block data stored in the father block, and the safety of the input information in the block is ensured.

When each block in the blockchain is generated, referring to fig. 1c, when the node where the blockchain is located receives input information, checking the input information, after the checking is completed, storing the input information into a memory pool, and updating a hash tree used for recording the input information; then, updating the update time stamp to the time of receiving the input information, trying different random numbers, and calculating the characteristic value for a plurality of times, so that the calculated characteristic value can meet the following formula:

SHA256(SHA256(version+prev_hash+merkle_root+ntime+nbits+x))<TARGET

wherein SHA256 is a eigenvalue algorithm used to calculate eigenvalues; version (version number) is version information of the related block protocol in the block chain; the prev_hash is the block header characteristic value of the parent block of the current block; the merkle_root is a characteristic value of input information; ntime is the update time of the update timestamp; the nbits is the current difficulty, is a fixed value in a period of time, and is determined again after exceeding a fixed period of time; x is a random number; TARGET is a eigenvalue threshold that can be determined from nbits.

Thus, when the random number meeting the formula is calculated, the information can be correspondingly stored to generate the block head and the block main body, and the current block is obtained. And then, the node where the blockchain is located sends the newly generated blocks to other nodes in the blockchain network where the newly generated blocks are located according to the node identifications of other nodes in the blockchain network, the other nodes verify the newly generated blocks, and the newly generated blocks are added into the blockchain stored in the newly generated blocks after the verification is completed.

A block: in a blockchain system, data is permanently recorded in the form of files, which may be referred to as blocks. A tile may contain a set of transaction records that occur over a period of time and that are not recorded by previous tiles, each tile recording events that occurred before it was created. A tile is understood to be a data structure that records transactions. Blocks created on the chain are linked in sequence, typically new blocks will load the tail of the blockchain and link to the last block. Wherein the transaction represents an operation of the user in the transaction system, which results in a change of the state of the ledger, a record is added in the ledger; the block records the transaction and state result occurring in a period of time, and is a consensus of the current account book state; the chain is formed by connecting blocks in series according to the creation time sequence, and is a log record of the state change of the whole account book.

For example, referring to fig. 1d, each block is composed of a block header and a block body, and the block header may include information such as a time stamp, a version number, and the like; the block is responsible for recording transaction information in a previous period of time, for example, the block records information of a plurality of transactions occurring in a period of time, for example, transaction 1, transaction 2, … … and transaction n. The blocks also have a block height in the blockchain that can be used to identify the location of the blocks in the blockchain. The block height of the first block (i.e., the created block) is 0, the height of the block referencing the created block is 1, and so on, each block that is then stored in the blockchain is "higher" than the previous block by one position, the block height value being equal to the block height value of the previous block plus one. Each block has a defined, fixed block height.

The intelligent contract is a non-tamperable and automatically executed computer program running on the blockchain, the intelligent contract is a code implementation for executing when a certain condition is met, a developer can define contract logic through programming language, issue the contract logic to the blockchain (intelligent contract registration), call a key or trigger execution according to the logic of contract clauses to complete the contract logic, and simultaneously provide functions of upgrading and logging off the intelligent contract.

In some possible embodiments, when there is a need for data backup of data on a blockchain of a blockchain node, a modified pipeline record may be generated for each modification operation on the blockchain, and the modified pipeline record may be stored in a pipeline storage area, such as a separate log file or database, to facilitate subsequent data backup and data recovery operations. When the data backup requirement is detected, incremental backup can be performed, and in a specific implementation, corresponding incremental backup data can be determined from the pipeline storage area and the blockchain according to the block height of the block in backup and the block height of the latest block of the blockchain, and the incremental backup data is stored in the backup storage area. The incremental backup data may include corresponding block data and transaction data read from the blockchain and a modified pipeline record since the last backup.

As can be seen from the above description, the embodiment of the present application provides a method for implementing dynamic incremental backup by recording the modification flow of a node, and when the blockchain data is backed up, the data backup can be performed without stopping the machine, so that the influence of the backup on the normal operation of the node is effectively reduced; in the process of data backup, only partial blockchain data can be backed up, but the whole blockchain data is not backed up, so that the time and the storage space required by backup can be greatly reduced, and the backup efficiency is effectively improved.

The implementation details of the technical solutions of the embodiments of the present application are described in detail below:

referring to fig. 2, fig. 2 is a flowchart of a data backup method according to an embodiment of the present application, and as shown in fig. 2, the data backup method may include:

s201, when a modification operation to data is detected on a blockchain of a target blockchain node, a target modification pipeline record is generated based on the modification operation.

The target blockchain node may refer to a blockchain node in the blockchain network where a data backup requirement exists, and the blockchain node may be any node in the blockchain network. It should be noted that the number of target blockchain nodes may be one or more, and in this embodiment of the present application, data backup is described with reference to one example.

It will be appreciated that where there is limited storage pressure or backup overhead, there may be a failure to backup data for a large number of blockchain nodes, in which case a blockchain node that needs to be backed up may need to be screened from a plurality of blockchain nodes, i.e., the target blockchain node herein. The target blockchain node may be preset by a backup person, or may be determined based on a characteristic parameter of the blockchain node, for example, the characteristic parameter may include failure frequency, importance degree, and the like of the blockchain node, that is, the target blockchain node to be backed up may be determined based on the failure frequency or importance level of the blockchain node. The failure frequency of the blockchain node may refer to the number of times that the blockchain node fails in a historical time period, where the historical time period refers to a time period that is located before the current time and is spaced from the current time by a preset time period (e.g., 15 days, 30 days, etc.), and the current time may refer to a time when a requirement for determining the target blockchain node needs to exist. The importance level characterizes the importance level of the blockchain node, which may be predefined by the relevant personnel, without limitation.

Based on this, in the case that the characteristic parameter is the failure frequency of the blockchain node, for the case that there are a plurality of blockchain nodes currently, the specific implementation of determining the target blockchain node from the plurality of blockchain nodes may be: acquiring failure frequency of each block chain node to determine a target block chain node from a plurality of block chain nodes based on the failure frequency of each block chain node; for example, the failure frequency of each blockchain node may be compared with a preset failure frequency, and the blockchain node corresponding to the failure frequency greater than the preset failure frequency is determined as the target blockchain node; for another example, the blockchain nodes may be sequentially ordered according to the order of the failure times from the big to the small, and the blockchain node in the first N bits in the ordering result is used as the target blockchain node, where N is a positive integer greater than or equal to 1, and may be a numerical value such as 1, 3, etc. According to the description, the blockchain node with higher failure frequency can be used as the target blockchain node with data backup requirement, so that backup cost is reduced, storage pressure is reduced, and data recovery can be conveniently performed on the blockchain nodes with higher failure frequency based on backup data in time when the follow-up failure occurs, and the reliability of the data is ensured.

In the case where the characteristic parameter is the importance level of the blockchain node, for the case where there are a plurality of blockchain nodes at present, the specific implementation of determining the target blockchain node from the plurality of blockchain nodes may be: acquiring importance degrees of all the block chain nodes to determine a target block chain node from a plurality of block chain nodes based on the importance degrees of all the block chain nodes; for example, the importance level of each blockchain node may be compared with a preset importance level, and the blockchain node corresponding to the importance level greater than the preset importance level may be determined as the target blockchain node; for another example, the blockchain nodes may be sequentially ordered in order of importance from a big order to a small order, and the blockchain node in the top N bits in the ordering result is used as the target blockchain node. According to the description, the blockchain node with higher importance degree can be used as the target blockchain node with the data backup requirement, so that the backup cost is reduced, the storage pressure is reduced, and meanwhile, the data backup can be carried out on the more important blockchain node.

In the case that the characteristic parameter is the failure frequency and the importance degree of the blockchain node, for the case that a plurality of blockchain nodes exist currently, the specific implementation of determining the target blockchain node from the plurality of blockchain nodes may be: the failure frequency and the importance degree of each blockchain node are obtained, so that a target blockchain node is determined from a plurality of blockchain nodes based on the failure frequency and the importance degree of each blockchain node. Therefore, the target blockchain node can be determined from the blockchain nodes by combining the characteristics of multiple dimensions, so that the rationality and the reliability of determining the link point of the target area are effectively enhanced.

For example, the failure frequency of each blockchain node may be compared with a preset failure frequency, and the blockchain node corresponding to the failure frequency greater than the preset failure frequency is determined as the initial blockchain node; and then, comparing the importance degree of the initial block chain node with a preset importance degree, and determining the initial block chain link point corresponding to the importance degree larger than the preset importance degree as a target block chain node.

For another example, the blockchain nodes may be sequentially ordered according to the order of the failure frequency from the high frequency to the low frequency, so as to obtain a corresponding first ordering result; sequencing all the block chain nodes in sequence from the big importance level to the small importance level to obtain a corresponding second sequencing result; then, the ranks of the blockchain nodes may be partitioned from the first ranking result and the second ranking result, and a target rank of each blockchain node may be determined, e.g., for any blockchain node, a sum value of the ranks of the blockchain node in the first ranking result and the ranks of the blockchain node in the second ranking result may be taken as the target rank of the blockchain node; further, a target blockchain node may be determined based on the target ordering of each blockchain node, e.g., a blockchain node with a target rank of the top N bits may be used as the target blockchain node.

Considering that when all data on a block chain is backed up once, the block chain node needs to be set to a shutdown state, and shutdown processing also causes data to stop writing, and the data of the block chain node needs to be completely written and then shutdown is required to be ensured, and the data cannot be stopped again when the data is written into a part, so that the incomplete data of the block chain node can be caused.

Based on this, in the embodiment of the present application, in the target blockchain node, a modified pipeline record may be generated for each modification operation (such as updating the state, etc.), so that when the data is recovered, the target of recovering from the backup data to the latest state may be achieved by using the modified pipeline record. That is, when a modification operation is detected on a blockchain node, a modified pipeline record may be generated based on the modification operation. Wherein the modification operation may include updating of an account, claiming of an invoice, and the like; modifying the pipeline record may include modifying information of the type of operation, time (timestamp), data involved, etc.; the types of modification operations may include types of addition, deletion, update, and the like.

In one implementation, when the modification operation is an update of the account, the update may specifically refer to transferring the resource in the account, that is, the modification operation is a transfer operation of the resource in the account, and in this case, the specific implementation of generating the target modification flow record may be: the method comprises the steps that the residual resources in an account after transferring the resources in the account can be determined, and the time of modification operation and the operation type of the modification operation are obtained; to generate a target modification flow record based on the account corresponding to the modification operation, the remaining resources of the account, the time corresponding to the modification operation, the operation type, and the like.

For example, the modification operation is specifically: the amount of resources transferred from account a to account B is 100, in which case the blockchain node may calculate the amounts of resources remaining in account a and account B, and store the calculated results, and at this time, may generate a modified flow record based on the calculated results, where the modified flow record records the amounts of resources remaining in account a and account B (e.g., the modified flow record records the amount of resources remaining in account a as 0 and the amount of resources remaining in account B as 200), the time when the transfer operation occurs, and the type of operation (e.g., update).

In one implementation, when data backup is performed, all data on the blockchain can be performed, and also, when a modification pipeline record is generated, only the modification pipeline record of the data needing to be performed with data backup can be generated, and when other data has modification operation, the corresponding modification pipeline record does not need to be generated.

Optionally, when data backup is performed on a portion of data on the blockchain, the portion of data may be determined based on a characteristic parameter of each data, where the characteristic parameter may include importance, historical backup frequency, and so on. For example, with the data as the account data, the data of a portion of the accounts on the blockchain may be backed up.

The importance degree of the account can be preset by related personnel, for example, a corresponding importance level can be preset for each account, and when the data backup is performed, the data backup can be performed on the account with higher importance level, namely, the corresponding modification flow record is generated only for the modification operation of the resource amount of the account with high importance level. The principle of determining the account to generate the modified flow record based on the importance level of the account is similar to that of determining the target blockchain node based on the importance level of the blockchain node, and is not repeated herein.

The historical backup frequency may refer to the number of times data in an account is backed up in a historical time period, where the historical time period may refer to a time period that is located before a current time and is preset with the current time interval by a preset duration (for example, 20 days, 40 days, etc.), and the current time may refer to a time when a request for determining the account exists. In this case, the account with higher historical backup frequency can be used as the account needing to generate the modified flow record, namely, the account needing to perform data backup currently. In a specific implementation, the historical backup frequency of each account can be compared with the preset backup frequency, and the account corresponding to the historical backup frequency larger than the preset backup frequency is determined as the account (for example, the account can be called as a target account) needing to generate the modified flow record; for another example, the accounts may be sequentially sorted according to the order of the historical backup frequency from large to small, and the account in the first L bits in the sorting result is used as the target blockchain node, where L is a positive integer greater than or equal to 1.

S202, storing the target modified running water record in a running water storage area.

In one implementation, the modified flow records (such as the target modified flow records herein) may be stored in a separate area to facilitate subsequent backup and restore operations; such an area may be referred to as a pipelined storage area, which may be a log file or database, etc.

In one implementation, to ensure orderly recording of the running water and avoid the problem of concurrent operation, modifying the running water record may be performed in units of blocks, and may be performed by adding according to the block height, without out-of-order modification. For example, modified pipeline records generated in blocks with block heights 0, 1, 2, … on the blockchain are recorded sequentially.

In one implementation, each time a modified flow record is generated, the modified flow record may be stored in a flow storage area; or, in order to reduce the storage space occupied by storing the modified pipeline records and reduce the storage pressure of the pipeline storage area as much as possible, the modification of the same block on the same data can be combined, and only the final value of the data is reserved, i.e. the same data only records the final result. In this case, each time a modified pipeline record is generated, it may be determined whether there is a modification operation for the same data based on the modified pipeline record and the existing modified pipeline record in the pipeline storage area, and if so, the data may be merged, with only the final result for the data being recorded.

Optionally, the data merge is described in relation to the current generated target modified pipeline record. Specifically, the historical modification pipeline records of the data can be searched from the modification pipeline records which are stored in the pipeline storage area and are in the same block with the target modification pipeline records; and merging the historical modification flow records and the target modification flow records to obtain merged target modification flow records, and storing the merged target modification flow records in a flow storage area. The merging process herein may refer to taking the latest modified pipeline record as the merged target modified pipeline record, that is, for the modification operation of the same data in one block, only the modified pipeline record corresponding to the latest modification operation is stored in the pipeline storage area. Therefore, through the merging operation, useless data in the modified flow record can be deleted, the simplicity of the modified flow record is ensured, and meanwhile, the storage pressure of a storage space can be effectively reduced.

For example, in the modified flow record for the account a, according to the chronological order, the first record is 100 of the remaining resource amount of the account a, the second record is 0 of the remaining resource amount of the account a, and the third record is 300 of the remaining resource amount of the account a, and in the modified flow record for the account a stored in the flow storage area, only the third record may be reserved, and the first record and the second record may be deleted.

And S203, when the data backup requirement is detected, acquiring the backed-up first block height in the historical backup data of the backup storage area, and acquiring the second block height of the latest block in the block chain.

In one implementation, when there is a data backup requirement, an operation of performing data backup on data in the blockchain may be performed, and considering that in the embodiment of the present application, not all data in the blockchain is backed up once, but incremental backup is performed, that is, only a part of data in the blockchain is backed up at a time, when there is a data backup requirement, the data to be backed up at the current time needs to be determined first, for example, the data may be referred to as incremental backup data. Alternatively, when performing incremental backup, the backup may be performed in units of blocks, in which case, to determine the current incremental backup data, a block to be backed up may be determined first, for example, the block may be referred to as a backup block. In one embodiment, the specific implementation of determining the backup block may be: firstly, acquiring the block height backed up in the historical backup data of the backup storage area, wherein the block height can be called as a first block height; and may obtain the block height of the latest block in the blockchain, such as may be referred to as the second block height.

In one implementation, it may be determined that a data backup requirement currently exists when a computer device receives a data backup request. For example, a data backup person may send a data backup request to a computer device to cause the computer device to receive the data backup request, and after the computer device receives the data backup request, it is determined that a data backup requirement exists. In one implementation, when a data backup person needs to perform data backup on data on a blockchain, the data backup person can perform related operations through a user operation interface output by a terminal to send a data backup request to a computer device. See, for example, fig. 3 a: the terminal used by the data backup person may display an operation interface in the terminal screen, which may include at least a trigger control marked 301 for performing data backup. If the data backup person wants to perform data backup, the data backup person can perform a triggering operation (such as a clicking operation, a pressing operation, etc.) on the triggering control 301, so that a terminal used by the triggering data backup person can send a data backup request to the computer device.

In another implementation, the data backup requirement may also be generated when a trigger condition is met. The triggering condition may be that the number of newly added blocks on the blockchain reaches a preset number of blocks, or the current time reaches a preset backup time, etc.

S204, determining incremental backup data from the pipeline storage area and the blockchain based on the first block height and the second block height, and storing the incremental backup data in the backup storage area.

In one implementation, the backup block may be determined based on the first block height and the second block height; alternatively, the block between the second block height and the first block height may be used as a backup block, where it should be noted that, because the second block is the latest block and no backup is performed, the block corresponding to the second block height may also be used as a backup block. For example, referring to fig. 3b, assuming that the first block height of the backed up blocks is 5 and the second block height of the latest block in the blockchain is 9, the blocks with block heights of 6, 7, 8, and 9 are needed to be used as backup blocks to perform incremental backup on the data corresponding to the 4 backup blocks.

After the backup block is determined, incremental backup data may be determined based on the data corresponding to the backup block. Optionally, the block data of the backup block may be obtained from the blockchain; the modified flow record corresponding to the backup block can be obtained from the flow storage area, namely the modified flow record from the last backup can be obtained from the flow storage area; the obtained block data, transaction data and the modified flow record can be used as incremental backup data.

The block data may include data in a block header of the block and data in a block body, where the data in the block body may include transaction information (e.g., detailed description information of a transaction request, for example, in a case that a transaction is an account resource transfer, the transaction information may include a current resource amount of an account, an account address, a resource amount to be transferred, and the like). It should be noted that, the transaction data acquired here is not only transaction information in the block, but may also include transaction information stored in other areas than the block. For example, after a transaction is performed, the corresponding transaction information may be stored in the tile, but the transaction response piece for the subsequent transaction information is not stored in this tile, but needs to be retrieved from another storage area, i.e., the transaction data herein may refer to the transaction response piece. The modified flow record is for a transaction result obtained after the transaction is executed (e.g., in the case that the transaction is an account resource transfer, the transaction result may specifically refer to the amount of remaining resources in the account after the resource transfer is performed).

In one implementation, when there is a data recovery requirement for the backup data, the historical backup data and the incremental backup data may be acquired from the backup storage area, and the acquired historical backup data and the acquired incremental backup data are used as the backup data after recovery. When the backup data is restored, the last backup data and the incremental backup data can be restored into a complete backup data in advance, and the complete backup data can be directly utilized for restoration in the follow-up process, and the complete backup data is the data to be restored.

In one implementation, when there is a data recovery requirement for the backup data, the historical backup data and the modified pipeline record in the incremental backup data may also be obtained from the backup storage area, and the backup data may be recovered based on the obtained historical backup data and the modified pipeline record. For example, the original full backup data can be restored by using the historical backup data, then the modification operation can be sequentially applied to the original full backup data based on the modification pipeline record in the incremental backup data, so as to trace back the data corresponding to the modification pipeline record, and the data and the original full backup data are utilized for restoration, namely the data and the original full backup data can be used as the data to be restored, thereby realizing the goal of restoring the backup data to the latest state.

The data recovery requirement may be generated when the block link point fails, or may be generated by triggering by other conditions, which is not limited. The backup data corresponding to the data recovery request may be all data on the blockchain at the current time, or may be partial data (for example, only data of a partial account is recovered), and the related personnel may utilize the backup data to recover the required data based on the requirement. The current time herein may refer to a time when there is a data recovery requirement.

In the embodiment of the application, a method for realizing dynamic incremental backup by recording the modification flow of the node is provided, when the block chain data is backed up, the data backup can be carried out under the condition that the normal operation is not influenced without stopping the machine, and the influence of the backup on the normal operation of the node is effectively reduced; in the process of data backup, only partial blockchain data can be backed up, but the whole blockchain data is not backed up, so that the time and the storage space required by backup can be greatly reduced, and the backup efficiency is effectively improved.

Based on the foregoing embodiments, another data backup method is provided in the embodiments of the present application, referring to fig. 4, and the data backup method includes, but is not limited to, the following steps:

S401, when a modification operation to data is detected on a blockchain of a target blockchain node, a target modification pipeline record is generated based on the modification operation.

S402, storing the target modified running water record in a running water storage area.

The specific embodiments of steps S401 to S402 may be referred to the descriptions in steps S201 to S202, and are not repeated here.

S403, acquiring characteristic parameters of the target block chain node, and determining a triggering condition for carrying out data backup on the target block chain node based on the characteristic parameters of the block chain node.

The characteristic parameter may include one or more of a third block height of a latest block on the blockchain, a block generation speed of a block on the blockchain, a historical backup frequency of a target blockchain node, a failure frequency of the target blockchain node, and the like.

The third block height of the latest block on the blockchain may be referred to as the block height of the latest block on the blockchain.

The block generation speed of the blocks may refer to the number of blocks generated in a preset time period; the preset time period may be preset, and the value may not be particularly limited. For example, assuming that the number of blocks generated by the target blockchain node within the preset time period is 3, the block generation speed of the target blockchain node may be determined to be 3; as another example, assuming that the number of blocks generated by the target blockchain node within the preset time period is 6, the block generation speed of the target blockchain node may be determined to be 6.

The historical backup frequency of the target blockchain node may refer to the execution times of executing the data backup operation on the data on the blockchain in the historical time period. The historical time period refers to a time period that is located before the current time and is spaced from the current time by a preset length (e.g., 30 days), where the current time may refer to a time when there is a need to determine the backup period.

The failure frequency of the target blockchain node may refer to the number of times that the target blockchain node fails in a historical time period, where the historical time period and the historical time period may be the same time period or different time periods, and this is not limited.

In one implementation, backing up data on a blockchain of a blockchain node may be triggered based on a trigger condition, i.e., when the trigger condition is met, a subsequent data backup operation may be performed. The triggering conditions can be determined based on the characteristic parameters, and different triggering conditions can be set under different characteristic parameters; the determination of the trigger condition is specifically explained below.

In one implementation, in order to avoid the need to perform data backup on a large number of blocks when the number of blocks on the blockchain is excessive, a longer backup time and a larger storage space are caused, so that the newly added blocks can be timely subjected to data backup. In this case, the triggering condition may be that the number of blocks of the newly added blocks on the blockchain reaches a preset number of blocks at the current time; the newly added block number may be determined based on the block height of the block chain at the current time and the block height of the block chain at the previous time, for example, a difference between the block height of the block chain at the current time and the block height of the block chain at the previous time may be used as the block number. The block height of the last incremental backup operation is the backed up block height, and the block height of the current block chain is the block height of the latest block in the block chain.

Based on this, a specific implementation of determining the trigger condition may be: the block height backed up in the historical backup data can be determined, for example, the block height can be called as a fourth block height; after determining the third block height and the fourth block height, a trigger condition may be determined based on the two block heights.

In one embodiment, a difference in height between the fourth block height and the third block height may be calculated, e.g., the difference between the third block height and the fourth block height may be used as the difference in height to determine the trigger condition based on the difference in height; for example, the difference in height may be set to a preset difference in height as a trigger condition. The preset height difference may be preset, and the specific value may not be limited, for example, the height difference may be a value of 3, 5, or the like. The height difference may be understood as the same as the number of newly added blocks, and the preset height difference may be understood as the same as the number of preset blocks.

It should be noted that the number of blockchain nodes requiring data backup may be plural, that is, the number of blockchain nodes to be backed up may be plural, in this case, a corresponding preset height difference may be set for each blockchain node. The preset height difference corresponding to each blockchain node may be the same or different, which is not limited. For example, the predetermined height difference corresponding to one blockchain node may be 5, and the predetermined height difference corresponding to another blockchain node may be 4.

In one embodiment, if different blockchain nodes correspond to different backup storage areas and the storage spaces of the different backup storage areas are different, in this case, in order to reduce the storage pressure of each backup storage area as much as possible, the preset height difference corresponding to each blockchain node may be adaptively adjusted based on the size of the storage space of each backup storage area. For example, the preset height difference corresponding to a blockchain node may be in positive correlation with the size of the storage space of the backup storage area, i.e., the larger the storage space of the backup storage area corresponding to the blockchain node, the larger the preset height difference corresponding to the blockchain node may be, and the smaller the storage space of the backup storage area corresponding to the blockchain node, the smaller the preset height difference corresponding to the blockchain node may be.

In one possible implementation, a mapping relationship between a preset reference storage space and a reference height difference may be considered to determine a preset height difference of a blockchain node based on the mapping relationship and a storage space size of a backup storage space of the blockchain node. The relation between the reference storage space and the reference height difference in the mapping relation can be positive correlation relation, and the reference storage space specifically refers to a space range; the specific implementation of determining the preset height difference for a blockchain node may be: acquiring the storage space size of a backup storage area corresponding to the block chain node, and determining a space range corresponding to a reference storage space in which the storage space size is located in a mapping relation, namely determining which reference storage space corresponds to the storage space; after determining the space range of the reference storage space, the reference height difference corresponding to the reference storage space can be used as the preset height difference corresponding to the blockchain node.

In one implementation, the trigger condition may also be that the current time reaches the backup time; the backup time may be predefined, for example, the backup time may be determined based on a backup period, and the backup period may be used to indicate a time interval for performing data backup on the block link point, that is, incremental data backup operations may be periodically performed; that is, the time indicated by the current time reaching the backup period of the target blockchain node may be used as a trigger condition.

The backup period of the target blockchain node may be predetermined, e.g., the backup period may be determined based on a characteristic parameter of the target blockchain node, the characteristic parameter may be a block generation speed of a block of the target blockchain node, a historical backup frequency of the target blockchain node, a failure frequency of the target blockchain node, and so on.

In one embodiment, the backup period of the target blockchain node may be inversely related to the block generation speed, i.e., if the block generation speed of the target blockchain node is faster, the backup period of the target blockchain node may be set shorter, and if the block generation speed of the target blockchain node is slower, the backup period of the target blockchain node may be set longer. For example, assuming that the block generation speed of the target blockchain node is 5, the backup period of the target blockchain node may be set to 1 day, and if the block generation speed of the target blockchain node is 10, the backup period of the target blockchain node may be set to 2 days.

In one possible implementation, a mapping relationship between a preset reference block generation speed and a reference backup period may be considered to determine a backup period of a blockchain node based on the mapping relationship and the block generation speed of the blockchain node. The relationship between the reference block generation speed and the reference backup period in the mapping relationship may be a negative correlation relationship, and the reference block generation speed may specifically refer to a speed range; the specific implementation of determining the backup period for the target blockchain node may be: obtaining a block generation speed corresponding to the target block link point, and determining a speed range corresponding to a reference block generation speed in which the block generation speed is located in the mapping relation, namely determining which reference block generation speed is located in the speed range corresponding to the block generation speed; after determining the speed range of the reference block generating speed, the backup period corresponding to the reference block generating speed can be used as the backup period corresponding to the target block link point.

In one embodiment, the backup period of the target blockchain node may have a negative correlation with the historical backup frequency, i.e., if the historical backup frequency of the target blockchain node is higher, the backup period of the target blockchain node may be set shorter, and if the historical backup frequency of the target blockchain node is lower, the backup period of the target blockchain node may be set longer. For example, assuming that the historical backup frequency of the target blockchain node is 8, the backup period of the target blockchain node may be set to 1 day, and if the historical backup frequency of the target blockchain node is 4, the backup period of the target blockchain node may be set to 2 days. In a possible implementation manner, a mapping relationship between a preset reference historical backup frequency and a reference backup period may also be considered, so as to determine a backup period of the blockchain node based on the mapping relationship and the historical backup frequency of the blockchain node; the implementation principle is similar to the above-mentioned principle of determining the backup period by using the block generation speed and the corresponding mapping relation, and will not be repeated here.

In one embodiment, the backup period of the target blockchain node may be inversely related to the failure frequency, i.e., if the failure frequency of the target blockchain node is higher, the backup period of the target blockchain node may be set shorter, and if the failure frequency of the target blockchain node is lower, the backup period of the target blockchain node may be set longer. For example, assuming that the failure frequency of the target blockchain node is 12, the backup period of the target blockchain node may be set to 3 days, and if the historical backup frequency of the target blockchain node is 4, the backup period of the target blockchain node may be set to 5 days. In a possible implementation manner, a mapping relationship between a preset reference failure frequency and a reference backup period may also be considered, so as to determine a backup period of the blockchain node based on the mapping relationship and the failure frequency of the blockchain node; the implementation principle is similar to the above-mentioned principle of determining the backup period by using the block generation speed and the corresponding mapping relation, and will not be repeated here.

It should be noted that the number of blockchain nodes requiring data backup may be plural, that is, the number of blockchain nodes to be backed up is plural, and the target blockchain node is any one of the plural blockchain nodes to be backed up. In this case, the backup period for each blockchain node may be the same or different; for example, the same backup period may be set in advance for each blockchain node, such as may be 7 days; for another example, a different backup period may be preset for each blockchain node, e.g., the backup period of one blockchain node may be set to 7 and the backup period of another blockchain node may be set to 5 days.

In one embodiment, similar to the above-described backup period of determining the target blockchain node, the backup period of the corresponding blockchain node may also be determined based on the block generation speed, the historical backup frequency, the failure frequency, and the like of each blockchain node. The following description is related to determining backup periods of each blockchain node under the block generation speed, the historical backup frequency and the failure frequency:

for block generation speed, the specific implementation of determining the backup period of each blockchain node may be: the block generation speeds of the blocks in the block link points of the block chain nodes can be obtained first to determine the backup period of each block chain node based on the block generation speeds corresponding to the block link points.

The backup period and the block generation speed may be in a negative correlation, i.e., if the block generation speed corresponding to a certain blockchain node is faster, the backup period corresponding to the blockchain node may be shorter, and if the block generation speed corresponding to another blockchain node is slower, the backup period corresponding to the blockchain node may be longer. Through the setting operation of the backup period, after a certain amount of blocks are newly generated on the block chain, the newly generated blocks can be timely and incrementally backed up, so that the subsequent backup of excessive accumulated blocks is avoided.

For historical backup frequency, the specific implementation of determining the backup period of each blockchain node may be: the historical backup frequency of each blockchain node of the plurality of blockchain nodes can be obtained first to determine the backup period of each blockchain node based on the historical backup frequency corresponding to each blockchain node.

The backup period and the historical backup frequency may be in a negative correlation, i.e., if the historical backup frequency corresponding to a certain blockchain node is higher, the backup period corresponding to the blockchain node may be shorter, and if the historical backup frequency corresponding to another blockchain node is lower, the backup period corresponding to the blockchain node may be longer. Through the setting operation of the backup period, the current backup period can be adjusted by effectively utilizing the historical backup condition, the rationality of data backup is improved, and the calculation cost for carrying out the data backup can be reduced as much as possible.

For failure frequency, the specific implementation of determining the backup period of each blockchain node may be: failure frequencies of each blockchain node of the plurality of blockchain nodes can be obtained first to determine backup periods of each blockchain node based on the failure frequencies corresponding to each blockchain node.

The backup period and the failure frequency may be in a negative correlation, i.e., if the failure frequency corresponding to a certain blockchain node is higher, the backup period corresponding to the blockchain node may be shorter, and if the failure frequency corresponding to another blockchain node is lower, the backup period corresponding to the blockchain node may be longer. Through the setting operation of the backup period, the failure of the block chain link point can be ensured, and when the data recovery is needed, the data recovery can be timely carried out based on the backup data.

In the case that there are a plurality of blockchain nodes described above, a corresponding mapping relationship may also be set to determine a backup period corresponding to each blockchain node, and the implementation principle is similar to the principle of determining a backup period of a single target blockchain node described above, which is not repeated here.

S404, when the triggering condition is met, determining that the data backup requirement is detected.

In one implementation, if the current time satisfies the trigger condition, it may be determined that a data backup requirement is detected, then a subsequent data backup operation may be continued, and if the current time does not satisfy the trigger condition, it may be determined that a data backup requirement is not detected.

As previously described, determining whether the trigger condition is met may include the following:

in the first mode, when the trigger condition is that the height difference reaches the preset height difference, the trigger condition is that: the block height of the backed up block in the historical backup data and the block height of the latest block on the block chain can be determined in real time, and the height difference between the two block heights is calculated; after the height difference is obtained, the height difference can be compared with a preset height difference, and if the height difference reaches the preset height difference, a triggering condition can be met; if the height difference does not reach the preset height difference, it may be determined that the trigger condition is satisfied.

For example, in the case that the preset height difference is 3, assuming that the fourth block height is 4 and the third block height is 7, it can be seen that the height difference of the two block heights is 3, it can be determined that the trigger condition is satisfied; assuming that the fourth block height is 4 and the third block height is 6, it can be seen that the difference in height between the two block heights does not reach 3, and it can be determined that the trigger condition is not satisfied.

In the second mode, in the case that the trigger condition is that the current time reaches the time indicated by the backup period of the target blockchain node: whether the current time is the time indicated by the backup period of the target blockchain node can be detected in real time; if the current time is the time indicated by the backup period of the target blockchain node, determining that the trigger condition is met; if the current time is not the time indicated by the backup period of the target blockchain node, it may be determined that the trigger condition is not met. For example, the backup period may be one day, i.e., the data backup operation is performed at the same point in time every day.

S405, when it is determined that the data backup requirement exists, the backed-up first block height in the historical backup data of the backup storage area is obtained, and the second block height of the latest block in the block chain is obtained.

And S406, determining the incremental backup data from the flow storage area and the blockchain based on the first block height and the second block height, and storing the incremental backup data in the backup storage area.

The specific embodiments of steps S405 to S406 may be referred to the descriptions in steps S203 to S204, and are not repeated here.

In the embodiment of the application, a method for realizing dynamic incremental backup by recording the modification flow of the node is provided, when the block chain data is backed up, the data backup can be carried out under the condition that the normal operation is not influenced without stopping the machine, and the influence of the backup on the normal operation of the node is effectively reduced; in the process of data backup, only partial blockchain data can be backed up, but the whole blockchain data is not backed up, so that the time and the storage space required by backup can be greatly reduced, and the backup efficiency is effectively improved. In addition, different triggering conditions aiming at the data backup can be designed based on different parameters so as to carry out the incremental backup based on actual conditions, and the flexibility, the rationality and the reliability of the incremental backup are improved.

The foregoing details of the method of embodiments of the present application are set forth in order to provide a better understanding of the foregoing aspects of embodiments of the present application, and accordingly, the following provides a device of embodiments of the present application.

FIG. 5 is a schematic diagram illustrating a data backup device according to an exemplary embodiment of the present application; the data backup means may be for a computer program (including program code) running in a computer device, for example the data backup means may be an application program in a computer device; the data backup device may be used to perform some or all of the steps in the method embodiments shown in fig. 2 and 4. Referring to fig. 5, the data backup device includes the following units:

a processing unit 501 configured to generate a target modified pipeline record based on a modification operation of a target blockchain node when the modification operation is detected on a blockchain of the target blockchain node;

a storage unit 502, configured to store the target modified running water record in a running water storage area;

the processing unit 501 is further configured to, when detecting that a data backup requirement exists, obtain a backed up first block height in the historical backup data of the backup storage area, and obtain a second block height of a latest block in the block chain;

The storage unit 502 is further configured to determine incremental backup data from the pipelined storage area and the blockchain based on the first block height and the second block height, and store the incremental backup data in the backup storage area.

In one implementation, the storage unit 502 is specifically configured to:

taking a block between the second block height and the first block height as a backup block;

obtaining block data and transaction data of the backup block from the block chain, and obtaining a modification flow record corresponding to the backup block from the flow storage area;

and taking the acquired block data, transaction data and the modified flow record as incremental backup data.

In one implementation, the storage unit 502 is specifically configured to:

searching a historical modification pipeline record of the data from the modification pipeline record which is stored in the pipeline storage area and is in the same block with the target modification pipeline record;

and merging the historical modification flow records and the target modification flow records to obtain merged target modification flow records, and storing the merged target modification flow records in a flow storage area.

In one implementation, the processing unit 501 is further configured to:

acquiring characteristic parameters of the target blockchain node, wherein the characteristic parameters comprise one or more of a third block height of a latest block on the blockchain, a block generation speed of the block on the blockchain, a historical backup frequency of the target blockchain node and a failure frequency of the target blockchain node;

determining a triggering condition for carrying out data backup on the target block link point based on the characteristic parameters of the block chain node;

and when the triggering condition is met, determining that the data backup requirement is detected.

In one implementation, the characteristic parameter includes a third block height of a most recent block on the blockchain; the processing unit 501 is specifically configured to:

determining the backed up fourth block height in the historical backup data, and calculating the height difference between the fourth block height and the third block height;

and taking the height difference reaching a preset height difference as a triggering condition.

In one implementation, the target blockchain node is any one of a plurality of blockchain nodes to be backed up; the characteristic parameters comprise block generation speeds of blocks on the block chain; the processing unit 501 is specifically configured to:

Determining backup periods of all block chain nodes based on block generation speeds corresponding to all block chain link points; the backup period of a block chain node is used for indicating the time interval of the block chain node for carrying out data backup; the backup period and the block generation speed are in a negative correlation;

and taking the time indicated by the current time reaching the backup period of the target blockchain node as a trigger condition.

In one implementation, the modifying operation is a transfer operation of a resource in the account; the processing unit 501 is specifically configured to:

determining the residual resources in the account after transferring the resources in the account, and acquiring the time of the modification operation and the operation type of the modification operation;

and generating a target modification flow record based on the account corresponding to the modification operation, the residual resources of the account, the time corresponding to the modification operation and the operation type.

In one implementation, the processing unit 501 is further configured to:

when a data recovery requirement for the backup data exists, acquiring historical backup data and a modification flow record in the incremental backup data from the backup storage area;

And restoring the backup data based on the acquired historical backup data and the modified flow record.

It will be appreciated that the division of the units in the embodiments of the present application is illustrative, and is merely a logic function division, and other division manners may be actually implemented. Each functional unit in the embodiments of the present application may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit. The integrated units may be implemented in hardware or in software functional units.

Referring to fig. 6, fig. 6 is a schematic structural diagram of a computer device according to an embodiment of the present application. As shown in fig. 6, the computer device includes: at least one processor 601, a memory 602. Optionally, the computer device may also include a network interface 603. Wherein data can be interacted between the processor 601, the memory 602 and the network interface 603, the network interface 603 is controlled by the processor 601 for receiving and sending messages, the memory 602 is used for storing a computer program comprising program instructions, and the processor 601 is used for executing the program instructions stored in the memory 602. Wherein the processor 601 is configured to invoke the program instructions to perform the above method.

The memory 602 may include a volatile memory (RAM), such as a random-access memory (RAM); the memory 602 may also include a non-volatile memory (non-volatile memory), such as a flash memory (flash memory), a Solid State Drive (SSD), etc.; the memory 602 may also include a combination of two or more of the types of memory described above.

The processor 601 may be a central processing unit (central processing unit, CPU). In one embodiment, the processor 601 may also be a graphics processor (Graphics Processing Unit, GPU). The processor 601 may also be a combination of a CPU and a GPU.

In one possible implementation, the memory 602 is used to store program instructions that the processor 601 may call to perform the following steps:

In one implementation, the processor 601 is specifically configured to:

In one implementation, the processor 601 is further configured to:

In one implementation, the characteristic parameter includes a third block height of a most recent block on the blockchain; the processor 601 is specifically configured to:

In one implementation, the target blockchain node is any one of a plurality of blockchain nodes to be backed up; the characteristic parameters comprise block generation speeds of blocks on the block chain; the processor 601 is specifically configured to:

In one implementation, the modifying operation is a transfer operation of a resource in the account; the processor 601 is specifically configured to:

In one implementation, the processor 601 is further configured to:

In specific implementation, the above-described devices, processors, memories, etc. may perform the implementation described in the above-described method embodiments, or may perform the implementation described in the embodiment of the present application, which is not described herein again.

Also provided in this embodiment is a computer (readable) storage medium storing a computer program, where the computer program includes program instructions, and when the program instructions are executed by a processor, the program instructions enable the processor to perform some or all of the steps performed in the method embodiments described above. The computer storage medium may be volatile or nonvolatile. The computer-readable storage medium may mainly include a storage program area and a storage data area, wherein the storage program area may store an operating system, an application program required for at least one function, and the like; the storage data area may store data created from the use of blockchain nodes, and the like.

Embodiments of the present application also provide a computer program product comprising program instructions which, when executed by a processor, implement some or all of the steps of the data backup method described above. Alternatively, the program instructions may be stored in a computer-readable storage medium, from which the program instructions are read by a computer device, such as a processor of the computer device, which executes the program instructions, causing the computer device to perform the data backup method provided above.

Those of ordinary skill in the art will appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

In the above embodiments, it may be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented in software, may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more program instructions. When the computer program instructions are loaded and executed on a computer, the processes or functions described in accordance with embodiments of the present application are produced in whole or in part. The computer may be a general purpose computer, a special purpose computer, a network of computers, or other programmable devices. The program instructions may be stored in or transmitted across a computer-readable storage medium.

The program instructions may be transferred from one website, computer, server, or data center to another website, computer, server, or data center by a wired (e.g., coaxial cable, fiber optic, digital subscriber line (Digital Subscriber Line, DSL)) or wireless (e.g., infrared, wireless, microwave, etc.). Computer readable storage media can be any available media that can be accessed by a computer or data storage devices, such as servers, data centers, etc., that contain an integration of one or more available media. The usable medium may be a magnetic medium (e.g., a floppy Disk, a hard Disk, a magnetic tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a Solid State Disk (SSD)), or the like.

The foregoing is merely specific embodiments of the present application, but the scope of the present application is not limited thereto, and any person skilled in the art can easily think about changes or substitutions within the technical scope of the present application, and the changes and substitutions are intended to be covered by the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1. A method of data backup, the method comprising:

2. The method of claim 1, wherein the determining incremental backup data from the pipelined storage region and the blockchain based on the first and second blockheights comprises:

3. The method of claim 1, wherein storing the target modified flow record in a flow storage area comprises:

4. The method as recited in claim 1, further comprising:

5. The method of claim 4, wherein the characteristic parameter comprises a third block height of a latest block on the blockchain; the determining triggering conditions for data backup on the blockchain based on the characteristic parameters of the blockchain node includes:

6. The method of claim 4, wherein the target blockchain node is any one of a plurality of blockchain nodes to be backed up; the characteristic parameters comprise block generation speeds of blocks on the block chain; the determining triggering conditions for data backup on the blockchain based on the characteristic parameters of the blockchain node includes:

7. The method of claim 1, wherein the modifying operation is a transfer operation of a resource in an account; the generating a target modified flow record based on the modifying operation includes:

8. The method of any one of claims 1-7, further comprising:

9. A data backup apparatus, the apparatus comprising:

10. A computer device comprising a processor and a memory, wherein the memory is for storing a computer program, the computer program comprising program instructions, the processor being configured to invoke the program instructions to perform the method of any of claims 1-8.

11. A computer readable storage medium, characterized in that the computer readable storage medium has stored therein program instructions, which when executed, are adapted to carry out the method according to any of claims 1-8.

12. A computer program product comprising program instructions for implementing the method according to any of claims 1-8 when executed by a processor.