Remote backup and recovery method for concentrator system data

Abstract

The invention provides a concentrator system data remote backup and recovery method, which comprises the following steps: loading all concentrators in the same network as nodes into a distributed network based on a distributed framework, each concentrator having a unique identity label; during the operation period of each concentrator, compressing and packaging key data of the concentrator; each node concentrator makes a decision by using a distributed algorithm, and distributes at least part of key data to at least part of nodes to realize redundant backup; when any concentrator in the distributed network is damaged or needs to be replaced, the replacement device asks for backup data belonging to the concentrator to be replaced from other concentrator nodes in the network, unpacking and decompressing are carried out, and data recovery is completed. According to the invention, even if part of concentrators are completely damaged, data recovery can still be carried out, and extra special equipment does not need to be additionally arranged to carry out remote backup of data.

Description

Technical Field

[0001] The present invention relates to the technical field of data backup and recovery of a concentrator, and in particular to a method for off-site backup and recovery of concentrator system data. Background Art

[0002] In the field of energy collection, concentrators are common key equipment, which are located between the collection master station and the energy meter terminal equipment. In addition, the concentrator equipment group under the master station system is large in number and widely distributed.

[0003] A concentrator usually manages dozens to thousands of terminals, and the data stored in them is extremely critical. Once the equipment is damaged, it will affect users in the service area of ​​the concentrator for a period of time, so the rapid recovery of the equipment is extremely important.

[0004] Regarding equipment recovery, there are many local backup and recovery methods, but they all have a common disadvantage: local backup cannot cope with the situation where the equipment is completely damaged. Of course, you can also purchase dedicated equipment to back up the data of the concentrator equipment group, but this requires increasing the equipment purchase cost, and if this dedicated equipment is damaged, it will cause greater losses. On the other hand, the network structure constructed between the dedicated equipment and the concentrator system is star-shaped, and the data throughput of the dedicated equipment is large, so the construction of network facilities near it is required to be high. Summary of the invention

[0005] The present invention aims to solve at least one of the technical problems in the prior art that the local backup method is difficult to restore internal key data when the concentrator is completely damaged, and the use of special equipment to perform off-site backup of concentrator data requires a large amount of investment and increases system risk points.

[0006] To this end, the present invention provides a method for off-site backup and recovery of concentrator system data. The method can at least ensure that data recovery can be performed even if part of the concentrators are completely damaged, and no additional special equipment is required for off-site data backup.

[0007] The present invention provides a method for off-site backup and recovery of concentrator system data, comprising:

[0008] Based on the distributed framework, all concentrators in the same network are loaded into the distributed network as nodes, where each concentrator has a unique identity;

[0009] During the operation of each concentrator, its key data is compressed and packaged;

[0010] Each node concentrator uses a distributed algorithm to make decisions and distribute at least part of the key data to at least part of the nodes to achieve redundant backup;

[0011] When any concentrator in a distributed network is damaged or needs to be replaced, the replacement device requests the backup data of the concentrator to be replaced from other concentrator nodes in the network, unpacks and decompresses it, and completes data recovery.

[0012] The method for off-site backup and recovery of concentrator system data according to the above technical solution of the present invention may also have the following additional technical features:

[0013] In the above technical solution, the unique identity includes an EUI64 address, an EUI48 address, an IPv6 address, an IPv4 address or a logical device name.

[0014] In the above technical solution, during the data compression and packaging process, the data is encrypted using an asymmetric encryption method, and the compressed and packaged encrypted data can only be decrypted and obtained through the current concentrator.

[0015] In the above technical solution, when compressing and packaging, the key data is identified and classified, and the key data is compressed and packaged using a compression algorithm;

[0016] The compression algorithm includes DEFLATE, BZIP2 or Zstd.

[0017] In the above technical solution, the distributed framework includes ROS2, OpenDDS, Eclipse Mosquitto or EMQX.

[0018] In the above technical solution, the distribution of at least part of the key data to at least part of the nodes has four backup strategies, including:

[0019] The first backup strategy: distribute all key data of the current concentrator to all other nodes for backup;

[0020] The second backup strategy: distribute some key data of the current concentrator to all other nodes for backup;

[0021] The third backup strategy: distribute all key data of the current concentrator to some nodes for backup;

[0022] The fourth backup strategy: distribute some key data of the current concentrator to some nodes for backup;

[0023] Select a backup strategy based on the quality of network communication, the amount of data to be backed up, and the available backup space on each node.

[0024] In the above technical solution, when the third backup strategy is selected for redundant backup, the selected part of nodes includes at least the first type of nodes and the second type of nodes;

[0025] Among them, the network communication quality of the first type of nodes is better than that of the second type of nodes, and the physical isolation distance between the second type of nodes and the current node is greater than the physical isolation distance between the first type of nodes and the current node.

[0026] In the above technical solution, the method of distributing at least part of the key data to at least part of the nodes also includes an emergency backup strategy, wherein the emergency backup strategy execution condition includes a first execution condition and a second execution condition, and the emergency backup strategy is executed when one of the first execution condition and the second execution condition is met;

[0027] The first execution condition includes: when the first backup strategy is not used or the first backup strategy is used but all nodes in the network are at risk of being damaged;

[0028] The second execution condition includes: when the second backup strategy, the third backup strategy, or the fourth backup strategy has been adopted, but more than a set number of nodes in the network are at risk of being damaged;

[0029] The emergency backup strategy includes:

[0030] Prepare at least one emergency backup device that can be connected to the Internet;

[0031] Virtualize the emergency backup device into a new node and add it to the distributed network;

[0032] A message is published to a dedicated topic in the distributed network, a data backup request with the highest priority is added for all devices that have not been damaged, and the emergency backup device is identified as the best backup node.

[0033] In the above technical solution, when any concentrator in the distributed network is damaged or needs to be replaced, the replacement device requests the backup data of the concentrator to be replaced from other concentrator nodes in the network, unpacks and decompresses the data, and completes data recovery, including:

[0034] Prepare a concentrator as a replacement device, and set the unique identifier of the replacement device to the unique identifier of the concentrator to be replaced;

[0035] The concentrator to be replaced is removed from the distributed network and replaced with a replacement device, and the replacement device is loaded into the distributed network as a node;

[0036] Based on the decision of the distributed algorithm, the replacement device requests the backup data of the concentrator to be replaced from other concentrator nodes in the network;

[0037] The replacement device unpacks and decompresses the acquired backup data locally and completes data recovery.

[0038] In the above technical solution, the replacement device requests the backup data of the concentrator to be replaced from other concentrator nodes in the network based on the distributed algorithm decision, including:

[0039] Node status detection: each concentrator node regularly updates and broadcasts its own status information, including storage space, network communication quality, and current load;

[0040] Data location and request: the newly connected replacement device node broadcasts a data recovery request, which includes the unique identity of the replacement device and the data range to be restored. Other nodes respond to the request based on their own status information and inform the replacement device of the data block range and status backed up;

[0041] Path selection and request distribution: Based on the collected response information, a distributed algorithm is used to select the optimal path for data request. Considering the network topology, the communication quality and load of the nodes, the distributed algorithm will select the optimal node set for data request distribution. At the same time, it is necessary to compare the timeliness of the data and use the latest available backup data.

[0042] Data transmission, the backup node selected by the distributed algorithm starts data transmission according to the request;

[0043] Data reorganization and verification: after receiving the data, the replacement device reorganizes and verifies it to ensure the integrity and consistency of the data. Among them, the data is verified using a checksum or hash value to ensure that no data corruption occurs during the transmission process.

[0044] Recovery completion notification: After data recovery is completed, the replacement device node broadcasts the recovery completion notification, updates the status information in the network, and enables other nodes to adjust their backup strategies.

[0045] In summary, due to the adoption of the above technical features, the beneficial effects of the present invention are:

[0046] Compared with local backup, the method provided by the present invention can ensure that data recovery can be performed even if the concentrator device is completely damaged, which greatly improves data security and system reliability. Compared with existing off-site backup solutions, the method of the present invention does not require the addition of special equipment outside the concentrator device group for data backup, reducing hardware costs. The present invention adopts a decentralized distributed framework, which will not cause a surge in communication pressure on single-point network devices, thereby ensuring the scalability of the system. The present invention adopts a redundant backup method. In theory, as long as the concentrators in the network are not damaged in large quantities, the data can be restored, greatly improving the possibility of data recovery. The algorithm used in the present invention is distributed, and the decision is made by each concentrator in the network to adaptively back up data for other concentrators based on factors such as its own network communication conditions with other concentrators and remaining space, thereby ensuring the efficiency of the backup process and the data security of users without perceived isolation.

[0047] Additional aspects and advantages of the present invention will become apparent from the following description or may be learned by practice of the present invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0048] The above and / or additional aspects and advantages of the present invention will become apparent and easily understood from the description of the embodiments in conjunction with the following drawings, in which:

[0049] Figure 1 It is a schematic diagram of constructing a distributed framework in a method for off-site backup and recovery of concentrator system data according to an embodiment of the present invention;

[0050] Figure 2 It is a schematic diagram of equipment identification in a method for off-site backup and recovery of concentrator system data according to an embodiment of the present invention;

[0051] Figure 3 It is a schematic diagram of redundant backup in a method for off-site backup and recovery of concentrator system data according to an embodiment of the present invention;

[0052] Figure 4 is a schematic diagram of a new concentrator in a method for off-site backup and recovery of concentrator system data according to an embodiment of the present invention;

[0053] Figure 5 It is a schematic diagram of equipment replacement in a method for off-site backup and recovery of concentrator system data according to an embodiment of the present invention;

[0054] Figure 6 It is a schematic diagram of data recovery in a method for off-site backup and recovery of concentrator system data according to an embodiment of the present invention;

[0055] Figure 7 It is a schematic diagram of completing data recovery in a method for off-site backup and recovery of concentrator system data according to an embodiment of the present invention. DETAILED DESCRIPTION

[0056] In order to more clearly understand the above-mentioned purpose, features and advantages of the present invention, the present invention is further described in detail below in conjunction with the accompanying drawings and specific embodiments. It should be noted that the embodiments of the present application and the features in the embodiments can be combined with each other without conflict.

[0057] In the following description, many specific details are set forth to facilitate a full understanding of the present invention. However, the present invention may also be implemented in other ways different from those described herein. Therefore, the protection scope of the present invention is not limited to the specific embodiments disclosed below.

[0058] Refer to the following Figures 1 to 7 The following describes a method for off-site backup and recovery of concentrator system data provided according to some embodiments of the present invention.

[0059] Some embodiments of the present application provide a method for off-site backup and recovery of concentrator system data.

[0060] The first embodiment of the present invention proposes a method for off-site backup and recovery of concentrator system data, which includes two main processes, namely, off-site disaster recovery backup process for critical data and recovery process for critical data. Specifically, the following steps S1-S4 are included. It can be understood that steps S1 to S4 are not strictly performed in sequence, and those skilled in the art can adjust the order of the steps as needed, and different steps can also be performed simultaneously.

[0061] S1. Based on the distributed framework, all concentrators in the same network are loaded as nodes into the distributed network, wherein each concentrator has a unique identity. In a specific embodiment, the distributed network constructed is as follows: Figure 1 shown.

[0062] By assigning a unique identifier to each concentrator, it is possible to ensure that each concentrator device has a unique identity in the network, which facilitates data management and recovery. In some embodiments, the unique identifier can be an IP address or a logical device name, such as Figure 2 As shown, a method of using a logical device name as a unique identification of a concentrator is shown.

[0063] Specifically, the distributed framework includes any one of ROS2, OpenDDS, Eclipse Mosquitto and EMQX. It is understandable that ROS2, OpenDDS, Eclipse Mosquitto and EMQX are all communication protocols or message brokers for the Internet of Things (IoT), but they each have different characteristics and uses. The characteristics of these methods are as follows:

[0064] ROS2 supports efficient communication between nodes in distributed systems, and uses Data Distribution Service (DDS) as the underlying communication middleware to achieve reliable message delivery. At the same time, the ROS2 framework has a high-performance communication mechanism, good scalability and flexible topology, which is very suitable for the construction of distributed systems.

[0065] OpenDDS is a fully open source real-time distributed computing system based on the OMG DDS standard and supports multiple programming languages ​​and platforms.

[0066] Eclipse Mosquitto is an open source MQTT message broker service that is lightweight and suitable for resource-constrained systems such as embedded systems. It is completely open source, supports multiple programming languages ​​and platforms, and is easy to deploy.

[0067] EMQX has high performance and scalability, supports large-scale concurrent connections and high throughput. It has rich functions, supports multiple protocols and extended functions such as rule engine and data persistence. It also provides open source and commercial versions.

[0068] Technical personnel in this field may also adopt other suitable methods to build a distributed framework, in which a plurality of concentrators are connected in communication, wherein each concentrator has a working area and a backup area, the working area is used to generate data to be backed up, and the backup area is used to store at least the backup data sent from other concentrators, and of course local backup data may also be stored.

[0069] S2. During the operation of each concentrator, its key data is compressed and packaged.

[0070] Specifically, during the operation of the concentrator device, its key data is identified, classified, and compressed. Among them, the key data includes the terminal data in the concentrator service area and other data set by the user that needs to be backed up. Since the real-time requirement for data backup is not high, but the network traffic limit is high, the compression algorithms that can be used are: DEFLATE, BZIP2 or Zstd.

[0071] Among them, the DEFLATE compression algorithm has a high compression rate and low computational overhead, and is very suitable for the application scenario disclosed herein; the DEFLATE algorithm combines LZ77 and Huffman coding techniques, which can reduce the occupancy of system resources while ensuring compression efficiency.

[0072] The BZIP2 compression algorithm uses the Burrows-Wheeler transform and Huffman coding, which can provide a very high compression rate and a good balance between compression rate and speed.

[0073] The Zstd compression algorithm provides both high compression ratio and high compression speed. Its compression ratio is close to that of the DEFLATE compression algorithm. Compared with traditional algorithms, Zstd is newer and may not be as widely supported as other algorithms on some embedded platforms.

[0074] In some embodiments, during the data compression and packaging process, the data is encrypted using an asymmetric encryption method, and the compressed and packaged encrypted data can only be decrypted and obtained through the current concentrator; in this way, the security of the data is guaranteed, and other concentrator devices can only store this data but cannot decrypt this data. It is understandable that the decryption authentication should be associated with the unique identity.

[0075] S3, such as Figure 3 As shown, each node concentrator uses a distributed algorithm to make decisions, and distributes at least part of the key data to at least part of the nodes in a many-to-many manner to achieve redundant backup.

[0076] Specifically, in each backup behavior (when a new node is added, or a node has data that needs to be backed up), the entity performing the backup can be all nodes except the node to be backed up, or some nodes except the node to be backed up. The backup action can be a full backup or a partial backup.

[0077] In a specific embodiment, the distribution of at least part of the key data to at least part of the nodes has four backup strategies, including: the first backup strategy: distributing all the key data of the current concentrator to all other nodes for backup; the second backup strategy: distributing part of the key data of the current concentrator to all other nodes for backup; the third backup strategy: distributing all the key data of the current concentrator to some nodes for backup; the fourth backup strategy: distributing part of the key data of the current concentrator to some nodes for backup; the four backup strategies are specifically shown in the following table.

[0078]

[0079] Among them, the first backup strategy is suitable for application scenarios with good network communication quality, low amount of data to be backed up or large available backup space on each node, and extremely high requirements for data recovery.

[0080] The second backup strategy is suitable for application scenarios where the overall network quality is good, the amount of data to be backed up is high or the available backup space on each node is small, and the data recovery requirements are general.

[0081] The third backup strategy is applicable to situations where the network quality is average but the network quality between some nodes is good. It will increase the communication pressure between some nodes in a short period of time, but the data recoverability is average.

[0082] The fourth backup strategy is suitable for application scenarios with average network quality, large amount of data to be backed up, and low data recovery requirements.

[0083] Specifically, you can select a backup strategy based on the quality of network communication, the amount of data to be backed up, and the size of the available backup space on each node.

[0084] Among them, when the third backup strategy is selected for redundant backup, the pressure on the communication network is relatively low, and more original data can be backed up. However, its data recoverability is average, so this feature needs to be optimized.

[0085] The optimization method includes: when selecting the third backup strategy for redundant backup, the selected part of the nodes includes at least first-type nodes and second-type nodes; wherein the network communication quality of the first-type nodes is better than that of the second-type nodes, and the physical isolation distance between the second-type nodes and the current node is greater than the physical isolation distance between the first-type nodes and the current node.

[0086] In a specific embodiment, two backup nodes are set for the current node to be backed up. One is another node with better communication quality in the network, which can support fast backup and recovery of data; the other is a node with poor network communication quality but physically isolated from a distant node, to ensure safe recovery of off-site backup data in the event of node damage and data loss due to a disaster in a certain place. This dual backup mechanism improves the disaster tolerance of the system, improves the recoverability of data to a certain extent, and optimizes the solution.

[0087] In some embodiments, the backup principle includes: regular detection of key data, quantitative detection of data changes, and the need to perform a data backup when a threshold is reached. More specifically, it is generally not recommended to perform data backup immediately when data needs to be backed up. A priority parameter can be set, and data backup can be performed immediately in an emergency. Otherwise, the remote node and the node to be backed up will decide the backup time according to the task arrangement.

[0088] In some embodiments, the distributing at least part of the critical data to at least part of the nodes further comprises an emergency backup strategy, wherein the emergency backup strategy execution condition comprises a first execution condition and a second execution condition, and the emergency backup strategy is executed when one of the first execution condition and the second execution condition are satisfied;

[0089] The first execution condition includes: when the first backup strategy is not used or the first backup strategy is used but all nodes in the network are at risk of damage; the second execution condition includes: when the second backup strategy, the third backup strategy or the fourth backup strategy has been adopted, but more than a set number of nodes in the network are at risk of damage.

[0090] The emergency backup strategy includes:

[0091] Prepare an emergency backup device that can be connected to the network; the emergency backup device can be a concentrator or a computer or other device with storage space. As a preference, choose a computer with sufficient storage space;

[0092] Virtualize the emergency backup device into a new node and add it to the distributed network;

[0093] A message is published to a dedicated topic in the distributed network, a data backup request with the highest priority is added for all devices that have not been damaged, and the emergency backup device is identified as the best backup node.

[0094] Through the emergency backup strategy, the purpose of protecting the data of nodes that have not been damaged can be achieved as much as possible. Of course, more than one emergency backup device can be set up in an emergency, and the purpose of batch backup can be achieved through parameter configuration or the use of different topics in the network, reducing the network pressure of a single virtual temporary node and rescuing more data. It should be noted that the emergency backup strategy will cause higher network pressure in the case of batch data rescue, so it should be used with caution unless possible large-scale damage is expected.

[0095] In some embodiments, when the backup space of any node is insufficient to complete a single backup task under the current backup strategy, the topic is used to confirm which data in its backup space is not unique, and the non-unique data is filtered according to timeliness, and the oldest data is cleared; if the data in the backup space of a certain node is unique, it will first apply to transfer the backup data to other nodes with sufficient space to make room. If most nodes are in a state where the backup area is full of unique data and the space is insufficient, the master station is notified to request adjustment of the backup strategy or reduction of the backup content.

[0096] S4. When any concentrator in the distributed network is damaged or needs to be replaced, the replacement device requests the backup data of the concentrator to be replaced from other concentrator nodes in the network, unpacks and decompresses it, and completes data recovery.

[0097] In some embodiments, step S4 includes steps S41 - S44 .

[0098] S41, such as Figure 4 As shown, prepare a new concentrator as a replacement device, and set the unique identity of the replacement device to the unique identity of the concentrator to be replaced; this step ensures that the new device can take over the role of the old device in the network and continue to undertake data processing and communication tasks, and only the device with the identity can decrypt the backup data originally belonging to the device.

[0099] S42, such as Figure 5As shown, the concentrator to be replaced is removed from the distributed network and replaced with a replacement device, and the replacement device is loaded into the distributed network as a node; in this way, the new device can immediately access the network and start the data recovery process.

[0100] S43, such as Figure 6 As shown, based on the distributed algorithm decision, the replacement device requests the backup data of the concentrator to be replaced from other concentrator nodes in the network; the distributed algorithm selects the optimal path and node for data recovery request according to the backup data status of each node, ensuring the efficiency and integrity of data recovery.

[0101] In the data recovery process, the key is how to efficiently obtain the required data from the backup node to ensure the integrity and speed of recovery. To achieve this goal, the distributed algorithm decision-making process of data recovery usually includes the following steps:

[0102] Node status detection: Each concentrator node regularly updates and broadcasts its own status information, including storage space, network communication quality, and current load; this information will be collected and saved by other nodes for subsequent decision-making processes.

[0103] Data location and request: the newly connected replacement device node broadcasts a data recovery request, which includes the unique identity of the replacement device and the data range that needs to be restored. Other nodes respond to the request based on their own status information and inform the replacement device of the data block range and status of the backup.

[0104] Path selection and request distribution, based on the collected response information, use a distributed algorithm to select the optimal path for data request; considering the network topology, node communication quality and load conditions, the distributed algorithm will select the optimal node set for data request distribution; at the same time, it is necessary to compare the timeliness of the data and use the latest available backup data; among them, the optimal path planning algorithm used in the distributed algorithm can be the Dijkstra algorithm or the A* algorithm.

[0105] Data transmission, the backup node selected by the distributed algorithm starts data transmission according to the request; during the data transmission process, a reliable transmission protocol (such as TCP) should be used to ensure the integrity and order of the data packets.

[0106] Data reorganization and verification: after receiving the data, the replacement device reorganizes and verifies it to ensure the integrity and consistency of the data; among them, a checksum (such as CRC) or hash value is used for data verification to ensure that no data corruption occurs during the transmission process.

[0107] Recovery completion notification: After data recovery is completed, the replacement device node broadcasts the recovery completion notification, updates the status information in the network, and enables other nodes to adjust their backup strategies.

[0108] If no available backup data is found in the network, it means that the backup nodes are also destroyed in the disaster. In this case, it can only be treated as a new node without backup data. At the same time, the operator should evaluate the possibility of disaster recurrence and adjust the backup strategy to improve data recoverability.

[0109] S44, such as Figure 7 As shown, the replacement device will unpack and decompress the obtained backup data locally and complete the data recovery. During the recovery process, the system will perform a data integrity check to ensure that the recovered data is consistent with the original data to avoid data loss or damage.

[0110] In this specification, the schematic representations of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described can be combined in any one or more embodiments or examples in a suitable manner.

[0111] Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in the protection scope of the present invention.

Claims

1. A method for off-site backup and recovery of concentrator system data, characterized in that: include: Based on the distributed framework, all concentrators in the same network are loaded into the distributed network as nodes, where each concentrator has a unique identity; During the operation of each concentrator, its key data is compressed and packaged; Each node concentrator uses a distributed algorithm to make decisions and distribute at least part of the key data to at least part of the nodes to achieve redundant backup; When any concentrator in a distributed network is damaged or needs to be replaced, the replacement device requests the backup data of the concentrator to be replaced from other concentrator nodes in the network, unpacks and decompresses it, and completes data recovery.

2. The method for off-site backup and recovery of concentrator system data according to claim 1, characterized in that: The unique identity includes an EUI64 address, an EUI48 address, an IPv6 address, an IPv4 address or a logical device name.

3. The method for off-site backup and recovery of concentrator system data according to claim 1, characterized in that: During the data compression and packaging process, the data is encrypted using an asymmetric encryption method, and the compressed and packaged encrypted data can only be decrypted and obtained through the current concentrator.

4. The method for off-site backup and recovery of concentrator system data according to claim 1, characterized in that: When compressing and packaging, key data is identified and classified, and compression algorithms are used to compress and package key data; The compression algorithm includes DEFLATE, BZIP2 or Zstd.

5. The method for off-site backup and recovery of concentrator system data according to claim 1, characterized in that: The distributed framework includes ROS2, OpenDDS, Eclipse Mosquitto or EMQX.

6. The method for off-site backup and recovery of concentrator system data according to claim 1, characterized in that: The method of distributing at least part of the critical data to at least part of the nodes has four backup strategies, including: The first backup strategy: distribute all key data of the current concentrator to all other nodes for backup; The second backup strategy: distribute some key data of the current concentrator to all other nodes for backup; The third backup strategy: distribute all key data of the current concentrator to some nodes for backup; The fourth backup strategy: distribute some key data of the current concentrator to some nodes for backup; Select a backup strategy based on the quality of network communication, the amount of data to be backed up, and the available backup space on each node.

7. The method for off-site backup and recovery of concentrator system data according to claim 6, characterized in that: When the third backup strategy is selected for redundant backup, the selected part of nodes includes at least the first type of nodes and the second type of nodes; Among them, the network communication quality of the first type of nodes is better than that of the second type of nodes, and the physical isolation distance between the second type of nodes and the current node is greater than the physical isolation distance between the first type of nodes and the current node.

8. The method for off-site backup and recovery of concentrator system data according to claim 6, characterized in that: The method of distributing at least part of the key data to at least part of the nodes also includes an emergency backup strategy, wherein the emergency backup strategy execution condition includes a first execution condition and a second execution condition, and the emergency backup strategy is executed when one of the first execution conditions is met; The first execution condition includes: when the first backup strategy is not used or the first backup strategy is used but all nodes in the network are at risk of being damaged; The second execution condition includes: when the second backup strategy, the third backup strategy, or the fourth backup strategy has been adopted, but more than a set number of nodes in the network are at risk of damage; The emergency backup strategy includes: Prepare at least one emergency backup device that can be connected to the Internet; Virtualize the emergency backup device into a new node and add it to the distributed network; A message is published to a dedicated topic in the distributed network, a data backup request with the highest priority is added for all devices that have not been damaged, and the emergency backup device is identified as the best backup node.

9. The method for off-site backup and recovery of concentrator system data according to claim 1, characterized in that: When any concentrator in the distributed network is damaged or needs to be replaced, the replacement device requests the backup data of the concentrator to be replaced from other concentrator nodes in the network, unpacks and decompresses the data, and completes data recovery, including: Prepare a concentrator as a replacement device, and set the unique identifier of the replacement device to the unique identifier of the concentrator to be replaced; The concentrator to be replaced is removed from the distributed network and replaced with a replacement device, and the replacement device is loaded into the distributed network as a node; Based on the decision of the distributed algorithm, the replacement device requests the backup data of the concentrator to be replaced from other concentrator nodes in the network; The replacement device unpacks and decompresses the acquired backup data locally and completes data recovery.

10. The method for off-site backup and recovery of concentrator system data according to claim 9, characterized in that: The decision based on the distributed algorithm, whereby the replacement device requests the backup data belonging to the concentrator to be replaced from other concentrator nodes in the network, includes: Node status detection: each concentrator node regularly updates and broadcasts its own status information, including storage space, network communication quality, and current load; Data location and request: the newly connected replacement device node broadcasts a data recovery request, which includes the unique identity of the replacement device and the data range to be restored. Other nodes respond to the request based on their own status information and inform the replacement device of the data block range and status backed up; Path selection and request distribution: Based on the collected response information, a distributed algorithm is used to select the optimal path for data request. Considering the network topology, the communication quality and load of the nodes, the distributed algorithm will select the optimal node set for data request distribution. At the same time, it is necessary to compare the timeliness of the data and use the latest available backup data. Data transmission, the backup node selected by the distributed algorithm starts data transmission according to the request; Data reorganization and verification: after receiving the data, the replacement device reorganizes and verifies it to ensure the integrity and consistency of the data. Among them, the data is verified using a checksum or hash value to ensure that no data corruption occurs during the transmission process. Recovery completion notification: After data recovery is completed, the replacement device node broadcasts the recovery completion notification, updates the status information in the network, and enables other nodes to adjust their backup strategies.

Images