Distributed backup method based on node health assessment and version life cycle management

Abstract

This distributed backup method, based on node health assessment and version lifecycle management, involves data backup and service node management technologies. The method includes: service initiation of self-backup, creating hot backup packages or temporary versions; the central hub, based on backup information, does not pull hot backup packages, stores temporary versions locally, and pulls long-term versions; the central hub performs storage node election, with the server accessing each elected storage node sequentially. If a node authorizes, S2S file transfer and storage are performed; if not, a rejection flag is set, and a replacement node is elected; the central hub determines whether to elect a replacement node based on the number of successfully stored authorized nodes; this continues until a preset number of distributed storage nodes have successfully stored the data. This method achieves dynamic, fine-grained hierarchical management of backup versions, improves the accuracy and reliability of node health assessment, achieves deep integration of backup operations and node management, and ultimately reduces storage resource waste, improves backup success rate, and enhances data security.

Description

Technical Field

[0001] This application relates to the field of data backup and service node management technology, specifically to a distributed backup method based on node health assessment and version lifecycle management. Background Technology

[0002] In the operation of a distributed service system, backup management of service data is the core link to ensure system stability and prevent data loss, while the health status assessment and reasonable election of backup nodes are key technical points to improve backup storage efficiency and avoid single points of failure in the system.

[0003] Existing technologies for data backup management and node election have many technical shortcomings:

[0004] 1. Using a single backup strategy with a fixed number of backups or a fixed duration, without differentiating backup types based on service operation status (such as system restart frequency), can easily lead to redundant backup versions, wasting storage resources, or the loss of critical backup versions. At the same time, without implementing temporary / long-term hierarchical management of backup versions, it is impossible to dynamically allocate backup resources according to the version lifecycle.

[0005] 2. The use of centralized storage or simple server-side self-backup mode lacks a unified management mechanism for the backup hub and a distributed storage mechanism for discrete nodes, which easily leads to problems such as backup file conflicts and no replacement mechanism after node storage failure; in addition, the backup data is not routinely reviewed, so it is impossible to detect storage anomalies in a timely manner, resulting in a high risk of data loss.

[0006] 3. The backup operation on the server side is independent of the election and authorization process of backup nodes. The node health assessment results are not deeply integrated with the transmission and storage of backup files. This can easily lead to high-load nodes being assigned a large number of backup tasks, which in turn leads to node performance degradation and backup transmission failure.

[0007] 4. The backup method is limited. Backups using technologies such as Docker are mostly snapshot backups at a specific point in time. OPS operation and maintenance systems only implement simple static file storage. Neither can achieve dynamic management of backup versions or distributed storage, resulting in poor adaptability. Summary of the Invention

[0008] To address the shortcomings of existing technologies, this application provides a distributed backup method based on node health assessment and version lifecycle management. This method enables dynamic and refined hierarchical management of backup versions, improving the accuracy and reliability of node health assessment. It also constructs a highly fault-tolerant and highly reliable distributed backup architecture, achieving deep integration of backup operations and node management. Ultimately, this method reduces storage resource waste and improves backup success rate and data security.

[0009] To achieve the above objectives, the present invention employs the following techniques:

[0010] A distributed backup method based on node health assessment and version lifecycle management is applied to a distributed backup system including a server, a backup hub, and a storage node cluster.

[0011] The backup hub is a service or program with backup management functions, which is responsible for scheduling and calling. The storage node cluster includes multiple storage nodes. Both the server and the storage nodes are business nodes with self-backup and remote backup functions, and their roles can be interchanged.

[0012] The methods include:

[0013] S100. When the business service starts, the server compresses and backs up its own stored files, generates backup files, and determines whether the time interval between the current compressed backup and the last compressed backup exceeds the hot backup interval threshold:

[0014] If the time limit is not exceeded, delete the previous backup file and keep the latest backup file as a hot backup package;

[0015] If the number of backups exceeds the limit, the current backup file will be marked as a temporary version. At the same time, the number of temporary version backups on the server will be checked, and only the most recently generated temporary versions will be kept, while the other temporary versions will be deleted.

[0016] Specifically, when the lifespan of a hot backup package exceeds the hot backup interval threshold, the server marks it as a temporary version; when the lifespan of a temporary version exceeds the version threshold interval, the server marks it as a long-term version.

[0017] S200 and the backup hub obtain the current server's backup information via network requests, and perform different operations based on the version information in the backup information:

[0018] If it is a hot backup package, the backup file retrieval operation will not be performed, and the process will end.

[0019] If it is a temporary version, it will be retrieved from the local storage of the backup hub:

[0020] If a file with the same file identifier as the file in the backup information is found, it is determined to be a file name conflict, the backup file retrieval operation is not performed, and the process ends.

[0021] If no file with the same file identifier as the backup information is found, the temporary version of the backup file is pulled to the local storage of the backup hub and saved. At the same time, the number of temporary versions corresponding to the current server in the local storage of the backup hub is checked, only the most recently generated temporary versions are kept, other temporary versions are deleted, and the saving information is recorded.

[0022] If it is a long-term version, then execute S300;

[0023] S300, the backup hub elects the top N storage nodes in the storage node cluster whose current health meets the preset health standard and whose ranking is the best, and sends the node information of the elected storage nodes to the current server.

[0024] S400: The server accesses the corresponding storage nodes one by one based on the received node information and initiates a direct connection authorization request. If the currently accessed storage node agrees to the authorization, the server directly transmits the backup file to it to complete the distributed storage. If the currently accessed storage node does not agree to the authorization, the server marks it as pseudo-unhealthy.

[0025] The server reports the authorization status of the accessed storage nodes to the backup hub.

[0026] S500, the backup hub performs the following processing based on the authorization status:

[0027] If M storage nodes disagree with the authorization, the backup hub will select the top M storage nodes with the best health ranking from the remaining candidate nodes in the storage node cluster and send their node information to the server so that the server can repeat S400. The remaining candidate nodes include storage nodes that have not been elected and whose health meets the preset health standard at the current time of supplementary election.

[0028] For those that have been authorized, the backup hub sends a query to each of the authorized storage nodes:

[0029] If the storage node reports successful storage, the backup center records the discrete storage information of that storage node.

[0030] If a storage node reports a transmission failure or storage failure, the backup center marks the storage node as pseudo-unhealthy and simultaneously elects a storage node with the best health ranking from the remaining candidate nodes, and sends its node information to the server so that the server can repeat the S400 process.

[0031] When the number of successfully stored data reported by the storage node is N, or when there are no more candidate nodes remaining, S500 ends.

[0032] Furthermore, for storage nodes falsely marked as unhealthy, the backup hub instructs them to perform multiple health self-checks:

[0033] If the health status of a node reaches the preset health standard in half or more of the self-checks, the backup center will remove the mark of the pseudo-unhealthy node and re-include it in the remaining candidate nodes.

[0034] If the health status reaches the preset health standard less than half of the self-checks or fails to reach the preset health standard for three consecutive self-checks, the backup center will completely discard the storage node and display it through a visual interface to facilitate operator intervention.

[0035] Furthermore, in multiple self-checks, the number of times Y≥5, the time interval between the (X+2)th and (X+1)th self-checks is twice the time interval between the (X+1)th and (X)th self-checks, and X takes the value 1, 2, ..., Y-2.

[0036] Furthermore, in S400, after the server transmits the backup file to the authorized storage node, the storage node verifies its local storage environment upon receiving the long-term version backup file, counts the number of long-term versions stored by the server, retains only the most recent long-term versions, deletes the others, and feeds back the operation information to the server so that the server can synchronize the operation information to the backup center.

[0037] Furthermore, after S500 is completed, the backup hub collects storage information of all backup files from the server, storage node cluster, and local storage of the backup hub, and displays it on a visual interface for operators to query and download.

[0038] Furthermore, the backup hub sends verification requests to each storage node at predetermined intervals to ensure that the backup files are stored normally; if a storage anomaly is detected, an alarm is immediately issued and the abnormal backup files are re-stored.

[0039] Furthermore, the health of storage nodes is calculated using a multi-metric normalized weighting algorithm, including the following steps:

[0040] Collect operational metrics for storage nodes, including service memory utilization. U jvm Waste recycling performance P gc CPU utilization U cpu System memory usage U men Disk space usage U disk Bandwidth utilization U net Service lifespan U sur All operating indicators are limited to a value range of [0, 100]. If the actual value exceeds 100, it will be treated as 100.

[0041] Each operational metric is mapped to the [0,1] range through normalization. The larger the mapped value, the less healthy the operating status of the storage node in the dimension of that operational metric.

[0042] Calculate the comprehensive health value based on the preset weights of each operational indicator. H :

[0043] H=H jvm *w 1 + H gc *w 2 + H cpu *w 3 + H men *w 4 + H disk *w 5 + H net *w 6 + H sur *w 7 ;

[0044] in, H jvm 、H gc 、H cpu 、H men 、H disk 、H net 、H sur The following are, in order: service memory utilization, garbage collection performance, CPU utilization, system memory utilization, disk space utilization, bandwidth utilization, and normalized values ​​of service lifetime. w 1 , w 2 , w 3 , w 4 , w 5 , w 6 , w 7 The preset weights for service memory utilization, garbage collection performance, CPU utilization, system memory utilization, disk space utilization, bandwidth utilization, and service lifetime are as follows: 0 < H≤1, the smaller the value, the higher the health level.

[0045] When 0.8≤ H ≤1 indicates an unhealthy level; when 0.5≤ H <0.8 indicates a sub-healthy state; when 0≤ H <0.5 indicates a healthy level; the preset health standard refers to either a sub-healthy level or a healthy level.

[0046] The beneficial effects of this invention are as follows:

[0047] 1. Implement refined two-tier hierarchical management of backup versions: Based on system operating status (hot backup threshold) and version lifecycle, backups are divided into three categories: hot backup, temporary version, and long-term version, enabling dynamic and intelligent allocation of backup resources; by controlling the number of temporary versions retained on the server and the backup hub to only retain 5 temporary versions, storage resource waste is effectively reduced; the hot backup strategy avoids backup version redundancy when the system restarts frequently, greatly improving backup management efficiency;

[0048] 2. Improve the accuracy and reliability of node health assessment: Design a multi-dimensional node operation indicator system covering virtual machines (JVM, GC) and hardware (CPU, disk, bandwidth) to match the actual operating characteristics of distributed service nodes; design differentiated normalization algorithms (piecewise linear, exponential normalization) for the risk characteristics of different indicators to improve the risk sensitivity of key indicators; set up extreme value penalties and business veto mechanisms to avoid node misselection caused by abnormal indicators or business failures, and ensure that the assessment results are highly consistent with the actual operating status of nodes;

[0049] 3. It adopts a three-tier architecture of server-side self-backup, unified management of the backup hub, and distributed storage of discrete nodes, which fundamentally solves the single point of failure problem of traditional centralized backup; it sets up a node replacement mechanism, and after storage failure, it re-elects a node from the candidate node pool to ensure successful storage on 3 discrete nodes, which greatly improves the fault tolerance of the backup architecture; the daily routine review mechanism can promptly detect storage anomalies and ensure the storage security of backup data.

[0050] 4. Use the overall health value of nodes as the core basis for node election and direct connection authorization to avoid high-load and abnormal nodes being assigned backup tasks from the source, reduce the probability of backup transmission failure, and improve overall backup efficiency; through the S2S file transfer mechanism, realize direct data interaction between the server and storage nodes, and significantly reduce the transmission pressure and operating load of the backup hub.

[0051] 5. The various thresholds (such as GC pause time, exponentially normalized k value) and indicator weight allocation in the weighting algorithm can be flexibly adjusted according to the actual business scenario, and the number of temporary versions retained can be modified as needed; the storage node cluster supports dynamic expansion, and the candidate node pool mechanism can adapt to the dynamic changes in cluster size, making it suitable for distributed service systems of different sizes and types. Attached Figure Description

[0052] Figure 1 This is a flowchart of a method embodiment of this application.

[0053] Figure 2 This is a lifecycle evolution diagram of backup file versions in an embodiment of this application.

[0054] Figure 3 This is a timing diagram of storage node election and S2S transmission in an embodiment of this application. Detailed Implementation

[0055] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the implementation methods of the present invention will be described in detail below with reference to the accompanying drawings. However, the embodiments described in this invention are only some embodiments of the present invention, and not all embodiments.

[0056] This application provides a distributed backup method based on node health assessment and version lifecycle management, applicable to a distributed backup system including a server, a backup hub, and a storage node cluster.

[0057] The backup hub is a service or program with backup management capabilities, responsible for scheduling and invocation. The storage node cluster includes multiple storage nodes. Both the server and storage nodes are business nodes with self-backup and remote backup capabilities, and their roles can be interchangeable. For example, consider three services: A, B, and C. A acts as the backup hub, responsible for actual scheduling and invocation, while B and C are the actual business services. B and C perform self-backups upon startup. When A performs scheduling operations, B can act as the server and C as a storage node, or vice versa, thus implementing distributed discrete storage logic, allowing B and C to act as distributed storage nodes for each other. Nodes process business data normally when not participating in backup tasks. One of the key innovations of this example is using the business service itself as a backup node, which reduces operational pressure and eliminates the need for additional dedicated backup nodes. Discrete nodes can also be of this type.

[0058] This example's method includes five core processes: server-side self-backup hierarchical management, unified scheduling of the backup hub, storage node election and authorization, discrete storage, and re-inspection and maintenance. It also incorporates a weighted algorithm based on multi-index normalization to achieve node health assessment and election. Figures 1-3 The specific technical solution is as follows:

[0059] S100. When the business service starts, the server compresses and backs up its own stored files, generating a zip-format backup file, and stores it in a specified location. After generating the backup file, the server determines whether the time interval between the current compressed backup and the previous compressed backup exceeds the hot backup interval threshold (e.g., 1 hour).

[0060] If the restart time is less than 1 hour, the previous backup file will be deleted, and the latest backup file will be kept as a hot backup. For example, if a compressed file was backed up at 13:00 and the service was restarted at 13:05 with another compressed file backed up, the compressed file backed up at 13:00 will be deleted.

[0061] If the restart exceeds one hour, the current backup file will be marked as a temporary version. At the same time, the number of temporary version backups on the server will be checked, and only the most recently generated temporary versions (e.g., 3) will be retained, while the others will be deleted. In other words, temporary versions are eliminated based on quantity. For example, if a compressed file is backed up at 13:00, 15:00, and 17:00, then when a new compressed file is backed up at 19:00, the compressed file backed up at 13:00 will be deleted.

[0062] Example: When the Java service starts, the server compresses the business folder into backup_20251001.zip. The generation time of the last backup file is 20250930. The system has not triggered the hot backup threshold, so the file is marked as a temporary version. The server keeps the three most recent temporary versions locally and automatically deletes the old version from 20250928.

[0063] Specifically, when the lifespan of a hot backup package exceeds the hot backup interval threshold, the server marks it as a temporary version. For example, a hot backup package generated at 13:05 will be converted to a temporary version after 14:05. Conversely, when the lifespan of a temporary version exceeds the version threshold interval, the server marks it as a long-term version. For example, if the version threshold interval is 1 day, and a compressed package is backed up at 13:00 today, it will be upgraded to a long-term version after 13:00 tomorrow if it has not been deleted.

[0064] S200, the backup hub obtains the current server's backup information via network requests, and performs different operations based on the version information in the backup information. The version information includes the generation time, which can be used to determine whether the backup file is a hot backup package, a temporary version, or a long-term version.

[0065] If it is a hot backup package, the backup file retrieval operation will not be performed, and the process will end.

[0066] If it is a temporary version, it will be retrieved from the local storage of the backup hub:

[0067] If a file with the same file identifier as the file in the backup information is found, it is determined to be a file name conflict, the backup file retrieval operation is not performed, and the process ends.

[0068] If no file with the same file identifier as the backup information is found, the temporary version of the backup file is pulled to the local storage of the backup hub and saved. At the same time, the number of temporary versions corresponding to the current server in the local storage of the backup hub is checked, and only the most recently generated temporary versions (e.g., 5) are kept, the other temporary versions are deleted, and the saving information is recorded.

[0069] If it is a long-term version, then execute S300;

[0070] S300 selects the top N (e.g., top 3) storage nodes in the backup hub cluster whose current health meets the preset health standard and whose ranking is the best. It then sends the node information of the selected storage nodes to the current server so that the server can autonomously complete the S2S file transfer and storage.

[0071] In this example, the health of storage nodes is calculated using a multi-metric normalized weighting algorithm. The specific calculation is performed by each storage node through self-checking, and the backup hub obtains the calculation results. The calculation includes the following steps:

[0072] S310, collect the operating metrics of the storage nodes, including service memory utilization. U jvm Waste recycling performance P gc CPU utilization U cpu System memory usage U men Disk space usage U disk Bandwidth utilization U net Service lifespan U sur Among them, waste recycling performance P gc It includes two sub-indices: Young GC and Full GC, which are expressed as follows: P ygc and P fgc All metrics are expressed as a percentage of pause time. If the percentage of GC pause time cannot be obtained, GC frequency (times / minute) can be used instead. All operational metrics are limited to a range of [0, 100]. If the actual value exceeds 100, it will be treated as 100. The descriptions and data sources of each operational metric are shown in the table below:

[0073]

[0074] S320. Map each operating metric to the [0,1] range using normalization. The larger the mapped value, the less healthy the operating status of the storage node in the dimension of that operating metric.

[0075] set up H jvm 、H gc 、H cpu 、H men 、H disk 、H net 、H sur The following are normalized values ​​in order: service memory usage, garbage collection performance, CPU usage, system memory usage, disk space utilization, bandwidth utilization, and service lifetime:

[0076] H jvm =min( U jvm / 100,1);

[0077] H cpu =min( U cpu / 100,1);

[0078] H men =min( U men / 100,1), U men =(Total memory - Available memory) / Total memory × 100%;

[0079] Considering the exponential risk characteristics of disk utilization, H disk Using the exponential normalization formula, H disk =1- e (-k*Udisk / 100) , k It is a constant, for example, 3, and can be flexibly adjusted according to the actual business scenario;

[0080] H net =min( U net / 100,1);

[0081] H sur=(( U sur / T ) a ) / (1+( U sur / T ) a ), H sur The unit can be determined by the user, such as minutes, hours, or days. a >0 represents the shape parameter, controlling the steepness of the curve. a The smaller the value, the flatter the curve's growth in the early stages. a The larger the value, the steeper the curve in the middle section; T >0 is a scale parameter, indicating that when U sur = T hour, H sur =0.5;

[0082] Normalized value of Young GC pause time percentage H ygc Piecewise linear normalization is used:

[0083] when P ygc ≤ T ygc hour, H ygc = P ygc / T ygc ;

[0084] when P ygc > T ygc hour, H ygc =0.8+0.2*( P ygc - T ygc ) / (100- T ygc );

[0085] Normalized value of pause time as a percentage of Full GC (Full GC) H fgc Piecewise linear normalization is used:

[0086] when P fgc ≤ T fgc hour, H fgc = Pfgc / T fgc ;

[0087] when P fgc > T fgc hour, H fgc =0.8+0.2*( P fgc - T fgc ) / (100- T fgc );

[0088] H gc = z 1* H ygc + z 2* H fgc ;in, T ygc and T fgc For example, set the preset thresholds to 5% and 2% respectively. z 1. z 2 are respectively H ygc , H fgc The weighting coefficients can be set to, for example, 0.2 and 0.8 respectively.

[0089] S330. Calculate the comprehensive health value based on the preset weights of each operating indicator. H :

[0090] H=H jvm *w 1 + H gc *w 2 + H cpu *w 3 + H men *w 4 + H disk *w 5 + H net *w 6 + H sur*w 7 ;

[0091] in, w 1 , w 2 , w 3 , w 4 , w 5 , w 6 , w 7 The preset weights for service memory usage, garbage collection performance, CPU usage, system memory usage, disk space utilization, bandwidth utilization, and service lifetime are, in order; for example, they can be set to... w 1 0.1 w 2 0.1 w 3 0.1 w 4 0.1 w 5 0.4 w 6 0.1 w 7 =0.1; 0 < H ≤1, the smaller the value, the higher the health level.

[0092] Based on overall health value H The health levels of storage nodes are classified as follows:

[0093] Health level: 0≤ H <0.5, normal state, as a candidate node;

[0094] Sub-health level: 0.5≤ H If the value is less than 0.8, there may be operational risks. Observe and investigate potential problems; it can be considered as a candidate node.

[0095] Unhealthy level, 0.8≤ H If the value is ≤1, the node will be considered as a candidate node due to an abnormal running status and its health level does not meet the preset health standards.

[0096] In this example, the candidate nodes participating in the election are only those at the healthy level and the sub-healthy level.

[0097] When the normalized value of disk space utilization H disk When the value is ≥0.9, the extreme value penalty mechanism is immediately triggered, forcibly setting the final overall health value to the calculated overall health value.H The larger one, 0.9, is used to prevent such anomalous storage nodes from being included in the candidate nodes.

[0098] Example: H jvm =0.60, H gc =0.48, H cpu =0.30, H men =0.40, H net =0.20, H sur =0.20; H disk =1- e (-3*95 / 100) =0.943, triggering the extreme value penalty mechanism. If the overall health value calculated at this time is... H If the value is 0.6352, then the final overall health score will be... H Forced to be set to 0.9.

[0099] S400: The server, based on the received node information, accesses the corresponding storage nodes one by one, initiating direct connection authorization requests. The storage nodes determine whether to grant authorization based on their real-time health status: if their real-time health status meets the preset health standard, they grant authorization; otherwise, they deny authorization. This handshake protocol / mechanism prevents miscommunication caused by changes in the storage node's health status from the time of election to the current real-time connection, where the health status may fall below the preset health standard.

[0100] If the currently accessed storage node agrees to the authorization, the server directly transmits the backup file to it to complete the distributed storage. After the server transmits the backup file to the authorized storage node, the storage node verifies its local storage environment upon receiving the long-term version backup file, counts the number of long-term versions stored by the server, retains only the most recent long-term versions, deletes the others, and sends the operation information back to the server so that the server can synchronize the operation information to the backup hub.

[0101] If the currently accessed storage node does not agree to authorization, the server marks it as pseudo-unhealthy.

[0102] After the access is completed, the server reports the authorization status of the accessed storage node to the backup hub.

[0103] S500, the backup hub performs the following processing based on the authorization status:

[0104] For nodes that disagree with authorization, if M storage nodes disagree, the backup hub will elect the top M storage nodes with the best health ranking from the remaining candidate nodes in the storage node cluster and send their node information to the server so that the server can repeat S400. The remaining candidate nodes (candidate node pool) include storage nodes that have not been elected and whose health meets the preset health standard at the time of the current supplementary election. If M is 0, no re-election or re-sending of node information to the server is required. If M is 1, one storage node needs to be elected and its node information resent. If M is 2, two storage nodes need to be elected and their node information resent. If the number of remaining candidate nodes is less than M, then all remaining candidate nodes will be elected.

[0105] For those that have been authorized, the backup hub sends a query to each of the authorized storage nodes:

[0106] If the storage node reports successful storage, the backup center records the discrete storage information of that storage node.

[0107] If a storage node reports a transmission failure or storage failure, the backup center marks the storage node as pseudo-unhealthy and simultaneously elects a storage node with the best health ranking from the remaining candidate nodes, and sends its node information to the server so that the server can repeat the S400 process.

[0108] When the number of successfully stored nodes reported by the storage nodes is N (if N was set to 3 in the previous steps, it will also be 3 here), or when there are no more candidate nodes remaining, S500 ends.

[0109] Example: The backup hub calculates the overall health value of all 10 storage nodes and elects the three nodes with the lowest overall health values ​​(B, C, and D, with values ​​of 0.25, 0.28, and 0.30 respectively) as the selected discrete storage nodes. The server initiates direct connection authorization requests to B, C, and D. If all three nodes agree to the authorization, the server completes the S2S file transfer. If B, C, and D report successful storage to the backup hub, the backup process is complete. If B and C report successful storage to the backup hub, but D reports storage failure due to network failure, D is marked as a pseudo-unhealthy node. Simultaneously, the server selects the storage node E with the best health ranking from the remaining candidate nodes and sends its node information to the server so that the server can initiate a direct connection authorization request to E. If E agrees to the authorization, the server completes the S2S file transfer for this replacement. If E reports successful storage to the backup hub, then the three storage nodes B, C, and E have completed the storage, and the backup process is complete.

[0110] For storage nodes marked as falsely unhealthy, the backup center instructs them to perform multiple health self-checks. Specifically, the number of checks is Y≥5, and the time interval between the (X+2)th and (X+1)th self-checks is twice the time interval between the (X+1)th and (X)th self-checks. X takes the values ​​1, 2, ..., Y-2.

[0111] If the health status of a node reaches the preset health standard in half or more of the self-checks, the backup center will remove the mark of the pseudo-unhealthy node and re-include it in the remaining candidate nodes.

[0112] If the health status reaches the preset health standard less than half of the self-checks or fails to reach the preset health standard for three consecutive self-checks, the backup center will completely discard the storage node and display it through a visual interface to facilitate operator intervention.

[0113] For example, if Y is 10, starting from a time interval of 1 minute, the verification time interval increases with the number of verifications, becoming 2 minutes, 4 minutes, 8 minutes, 16 minutes, ..., 1024 minutes. In 10 verifications, the preset health standard (i.e., the calculated comprehensive health value is either healthy or sub-healthy) must be met at least 5 times before the pseudo-unhealthy node is removed.

[0114] After S500 is completed, the backup hub collects storage information for all backup files from the server, storage node cluster, and local storage of the backup hub, and displays it on a visual interface for operators to query and download. The backup hub sends verification requests to each storage node at predetermined intervals (e.g., daily) to ensure the backup files are stored correctly; if a storage anomaly is detected, an alarm is immediately issued and the abnormal backup files are re-stored.

[0115] The above description is only a preferred embodiment of this application and is not intended to limit this application. Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application.

Claims

1. A distributed backup method based on node health assessment and version lifecycle management, characterized in that, It is applied to a distributed backup system that includes a server, a backup hub, and a storage node cluster. The backup hub is a service or program with backup management functions, which is responsible for scheduling and calling. The storage node cluster includes multiple storage nodes. Both the server and the storage nodes are business nodes with self-backup and remote backup functions, and their roles can be interchanged. The methods include: S100. When the business service starts, the server compresses and backs up its own stored files, generates backup files, and determines whether the time interval between the current compressed backup and the last compressed backup exceeds the hot backup interval threshold: If the time limit is not exceeded, delete the previous backup file and keep the latest backup file as a hot backup package; If the number of backups exceeds the limit, the current backup file will be marked as a temporary version. At the same time, the number of temporary version backups on the server will be checked, and only the most recently generated temporary versions will be kept, while the other temporary versions will be deleted. Specifically, when the lifespan of a hot backup package exceeds the hot backup interval threshold, the server marks it as a temporary version; when the lifespan of a temporary version exceeds the version threshold interval, the server marks it as a long-term version. S200 and the backup hub obtain the current server's backup information via network requests and perform different operations based on the version information in the backup information: If it is a hot backup package, the backup file retrieval operation will not be performed, and the process will end. If it is a temporary version, it will be retrieved from the local storage of the backup hub: If a file with the same file identifier as the file in the backup information is found, it is determined to be a file name conflict, the backup file retrieval operation is not performed, and the process ends. If no file with the same file identifier as the backup information is found, the temporary version of the backup file is pulled to the local storage of the backup hub and saved. At the same time, the number of temporary versions corresponding to the current server in the local storage of the backup hub is checked, only the most recently generated temporary versions are kept, other temporary versions are deleted, and the saving information is recorded. If it is a long-term version, then execute S300; S300, the backup hub elects the top N storage nodes in the storage node cluster whose current health meets the preset health standard and whose ranking is the best, and sends the node information of the elected storage nodes to the current server. S400: The server accesses the corresponding storage nodes one by one based on the received node information and initiates a direct connection authorization request. If the currently accessed storage node agrees to the authorization, the server directly transmits the backup file to it to complete the distributed storage. If the currently accessed storage node does not agree to the authorization, the server marks it as pseudo-unhealthy. The server reports the authorization status of the accessed storage nodes to the backup hub. S500, the backup hub performs the following processing based on the authorization status: If M storage nodes disagree with the authorization, the backup hub will select the top M storage nodes with the best health ranking from the remaining candidate nodes in the storage node cluster and send their node information to the server so that the server can repeat S400. The remaining candidate nodes include storage nodes that have not been elected and whose health meets the preset health standard at the current time of supplementary election. For those that have been authorized, the backup hub sends a query to each of the authorized storage nodes: If the storage node reports successful storage, the backup center records the discrete storage information of that storage node. If a storage node reports a transmission failure or storage failure, the backup center marks the storage node as pseudo-unhealthy and simultaneously elects a storage node with the best health ranking from the remaining candidate nodes, and sends its node information to the server so that the server can repeat the S400 process. When the number of successfully stored data reported by the storage node is N, or when there are no more candidate nodes remaining, S500 ends.

2. The distributed backup method based on node health assessment and version lifecycle management according to claim 1, characterized in that, For storage nodes marked as falsely unhealthy, the backup hub instructs them to perform multiple health self-checks: If the health status of a node reaches the preset health standard in half or more of the self-checks, the backup center will remove the mark of the pseudo-unhealthy node and re-include it in the remaining candidate nodes. If the health status reaches the preset health standard less than half of the self-checks or fails to reach the preset health standard for three consecutive self-checks, the backup center will completely discard the storage node and display it through a visual interface to facilitate operator intervention.

3. The distributed backup method based on node health assessment and version lifecycle management according to claim 2, characterized in that, In multiple self-checks, the number of times Y≥5, the time interval between the (X+2)th and (X+1)th self-checks is twice the time interval between the (X+1)th and (X)th self-checks, and X takes the value 1, 2, ..., Y-2.

4. The distributed backup method based on node health assessment and version lifecycle management according to claim 1, characterized in that, In S400, after the server transmits the backup file to the authorized storage node, the storage node verifies its local storage environment upon receiving the long-term version backup file, counts the number of long-term versions stored by the server, retains only the most recent long-term versions, and deletes the others. It also sends operation information back to the server so that the server can synchronize the operation information to the backup center.

5. The distributed backup method based on node health assessment and version lifecycle management according to claim 1, characterized in that, After S500 is completed, the backup hub collects storage information of all backup files from the server, storage node cluster, and local storage of the backup hub, and displays it on a visual interface for operators to query and download.

6. The distributed backup method based on node health assessment and version lifecycle management according to claim 1, characterized in that, The health of storage nodes is calculated using a multi-metric normalized weighting algorithm, including the following steps: Collect operational metrics for storage nodes, including service memory utilization. U jvm Waste recycling performance P gc CPU utilization U cpu System memory usage U men Disk space usage U disk Bandwidth utilization U net Service lifespan U sur All operating indicators are limited to a value range of [0, 100]. If the actual value exceeds 100, it will be treated as 100. Each operational metric is mapped to the [0,1] range through normalization. The larger the mapped value, the less healthy the operating status of the storage node in the dimension of that operational metric. Calculate the comprehensive health value based on the preset weights of each operational indicator. H : H=H jvm *w 1 + H gc *w 2 + H cpu *w 3 + H men *w 4 + H disk *w 5 + H net *w 6 + H sur *w 7 ； in, H jvm 、H gc 、H cpu 、H men 、H disk 、H net 、H sur The following are, in order: service memory utilization, garbage collection performance, CPU utilization, system memory utilization, disk space utilization, bandwidth utilization, and normalized values ​​of service lifetime. w 1 , w 2 , w 3 , w 4 , w 5 , w 6 , w 7 The preset weights for service memory utilization, garbage collection performance, CPU utilization, system memory utilization, disk space utilization, bandwidth utilization, and service lifetime are as follows: 0 < H ≤1, the smaller the value, the higher the health level.

7. The distributed backup method based on node health assessment and version lifecycle management according to claim 6, characterized in that, When the normalized value of disk space utilization H disk When the value is ≥0.9, the extreme value penalty mechanism is immediately triggered, forcibly setting the final overall health value to the calculated overall health value. H The larger one between 0.9 and 0.

9.

8. The distributed backup method based on node health assessment and version lifecycle management according to claim 6, characterized in that, H jvm =min( U jvm / 100,1); H cpu =min( U cpu / 100,1); H men =min( U men / 100,1), U men =(Total memory - Available memory) / Total memory × 100%; H disk =1- e (-k*Udisk / 100) , k It is a constant; H net =min( U net / 100,1); H sur =(( U sur / T ) a ) / (1+( U sur / T ) a ), a >0 represents the shape parameter, controlling the steepness of the curve. a The smaller the value, the flatter the curve's growth in the early stages. a The larger the value, the steeper the curve in the middle section; T >0 is a scale parameter, indicating that when U sur = T hour, H sur =0.5; Waste recycling performance P gc It includes two sub-indices: Young GC and Full GC, which are expressed as follows: P ygc and P fgc ; Normalized value of Young GC pause time percentage H ygc : when P ygc ≤ T ygc hour, H ygc = P ygc / T ygc ; when P ygc > T ygc hour, H ygc =0.8+0.2*( P ygc - T ygc ) / (100- T ygc ); Normalized value of pause time as a percentage of Full GC (Full Garbage Collection) H fgc : when P fgc ≤ T fgc hour, H fgc = P fgc / T fgc ; when P fgc > T fgc hour, H fgc =0.8+0.2*( P fgc - T fgc ) / (100- T fgc ); H gc = z 1* H ygc + z 2* H fgc ;in, T ygc and T fgc For the preset threshold, z 1. z 2 are respectively H ygc , H fgc The weighting coefficients.

9. The distributed backup method based on node health assessment and version lifecycle management according to claim 6, characterized in that, When 0.8≤ H ≤1 indicates an unhealthy level; when 0.5≤ H <0.8 indicates a sub-healthy state; when 0≤ H <0.5 indicates a healthy level; the preset health standard refers to either a sub-healthy level or a healthy level.

10. The distributed backup method based on node health assessment and version lifecycle management according to claim 1, characterized in that, For requests initiated by the server, the storage node determines whether to grant authorization based on its own real-time health status: If your real-time health status meets the preset health standard, then you agree to authorize. If your real-time health status does not meet the preset health standard, you do not agree to authorization.

Images