A ladder networking data management and backup method and system under a hybrid cloud architecture

Abstract

The application relates to the technical field of elevator Internet of Things data processing, and discloses an elevator Internet of Things data management and backup method and system under a hybrid cloud architecture, which comprises the following steps: collecting elevator terminal equipment original data streams on the edge side and processing the original data streams to generate pretreatment data; identifying data sensitivity according to a security rule library, encrypting high and medium sensitive data, and keeping low sensitive data in plaintext; dividing the data into three backup priority sets according to business criticality, and respectively distributing the data to an edge side local backup unit, a private cloud and a public cloud backup cluster after clustering based on access frequency and storage occupation; monitoring storage load, link state and backup progress, and scheduling resources when an exception occurs; and regularly recovering and practicing the backup data. Through data hierarchical processing, differential storage, dynamic monitoring and scheduling and regular practice, the application supports intelligent management of large-scale elevator cluster data.

Description

Technical Field

[0001] This invention relates to the field of elevator Internet of Things (IoT) data processing technology, and more specifically, to a method and system for elevator IoT data management and backup under a hybrid cloud architecture. Background Technology

[0002] With accelerating urbanization and ever-increasing building heights, elevators, as core equipment in vertical transportation, are becoming increasingly important for safe operation and intelligent management. Elevator network systems provide data support for preventative maintenance and emergency response by collecting real-time elevator operating status, fault logs, passenger flow data, and equipment sensor information. However, as the number of elevators surges, forming large-scale clusters, the amount of data is growing explosively and becoming increasingly heterogeneous. Existing data management methods have limitations in storage allocation, security, and backup efficiency, making it difficult to adapt to the dynamic management needs of large-scale clusters and failing to meet the requirements of efficient data management, security, and flexible backup for large-scale elevator clusters.

[0003] Therefore, how to provide a method and system for elevator network data management and backup under a hybrid cloud architecture is a technical problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0004] In view of this, the present invention proposes a method and system for elevator network data management and backup under a hybrid cloud architecture, aiming to solve the problem that existing technologies cannot meet the needs of large-scale elevator clusters for efficient data management, security and flexible backup.

[0005] In one aspect, this invention proposes a method for elevator network data management and backup under a hybrid cloud architecture, comprising:

[0006] A data acquisition node is set up on the edge side to access the raw data stream of the elevator terminal equipment, and the raw data stream is processed to generate preprocessed data;

[0007] The preprocessed data is identified for sensitivity based on a security rule base to obtain high-sensitivity data, medium-sensitivity data, and low-sensitivity data. The high-sensitivity data and medium-sensitivity data are encrypted to generate encrypted data segments, while the low-sensitivity data is retained as plaintext data segments.

[0008] The encrypted data segments and plaintext data segments are divided into three levels of backup priority sets according to business criticality. The three levels of backup priority sets are a first priority data set, a second priority data set, and a third priority data set. The first priority data set, the second priority data set, and the third priority data set are aggregated using a clustering algorithm based on data access frequency and storage usage to obtain a first priority data cluster set, a second priority data cluster set, and a third priority data cluster set. The first priority data cluster set, the second priority data cluster set, and the third priority data cluster set are then sequentially allocated to the edge-side local backup unit, the private cloud backup cluster, and the public cloud backup cluster of the hybrid cloud architecture.

[0009] Monitor the storage load, transmission link status and data backup progress of the three-level backup priority set. When insufficient storage capacity, link interruption or backup progress delay exceeds the progress threshold is detected, adjust the backup task queue or allocate backup channel resources, and trigger resource scheduling according to backup priority.

[0010] Data recovery drills are performed periodically on the data backups of the three-level backup priority set.

[0011] Furthermore, when performing sensitivity identification on the preprocessed data according to the security rule base, the process includes:

[0012] The security rule base includes historical security data and sensitivity classification rules. The historical security data is obtained by analyzing the historical operation data of the elevator network. The sensitivity classification rules are divided into high-sensitivity data, medium-sensitivity data and low-sensitivity data according to the data leakage risk threshold.

[0013] When identifying preprocessed data, the preprocessed data is compared with historical security data to obtain data to be divided that matches the historical security data; according to the sensitivity division rules, the data to be divided is divided into high-sensitivity data, medium-sensitivity data and low-sensitivity data.

[0014] Furthermore, when dividing the data to be segmented into high-sensitivity data, medium-sensitivity data, and low-sensitivity data, the following steps are included:

[0015] The data leakage risk threshold is divided into a high-risk threshold and a low-risk threshold, wherein the low-risk threshold is smaller than the high-risk threshold.

[0016] When the data to be classified is greater than or equal to the high-risk threshold, it is classified as high-sensitivity data;

[0017] When the data to be classified is greater than the low-risk threshold and less than the high-risk threshold, it is classified as medium-sensitivity data.

[0018] When the data to be classified is less than or equal to the low-risk threshold, it is classified as low-sensitivity data.

[0019] Furthermore, when dividing the encrypted data segments and plaintext data segments into a three-level backup priority set based on business criticality, the following is included:

[0020] The criticality of the business is determined quantitatively through a weighted scoring model, which includes a data failure impact factor, a real-time requirement factor, and a related equipment range factor.

[0021] Data failure impact factor; calculated based on the risk of elevator downtime, maintenance delay costs, and safety compliance penalties caused by missing data;

[0022] Real-time requirement factor: determined based on the urgency of the data;

[0023] Related equipment scope factor: set according to the number of elevators or the size of the group affected by the data;

[0024] The encrypted data segment and the plaintext data segment are input into the weighted scoring model, and the business criticality score value is output. The score is divided according to the scoring threshold, which is divided into a high-risk scoring threshold and a low-risk scoring threshold. The low-risk scoring threshold is less than the high-risk scoring threshold.

[0025] When the business criticality score is greater than or equal to the high-risk score threshold, it is determined to be the first priority data set;

[0026] When the business criticality score is greater than or equal to the low-risk score threshold but less than the high-risk score threshold, it is determined to be a second priority data set;

[0027] When the business criticality score is less than the low-risk score threshold, it is determined to be a third-priority data set.

[0028] Furthermore, when aggregating the first priority data set, the second priority data set, and the third priority data set using a clustering algorithm based on data access frequency and storage usage, the following steps are included:

[0029] For each data item in the priority data set, the access frequency and data storage usage per unit time are statistically analyzed to form the access and storage characteristic value of the data item.

[0030] The similarity between data items is calculated based on the access storage feature values, and the data items are aggregated into the same data cluster set according to the access frequency and storage usage.

[0031] For the first priority data set, aggregate data items with high access frequency and low storage consumption to obtain the first priority data cluster set;

[0032] For the second priority data set, aggregate data items with moderate access frequency and moderate storage consumption to obtain the second priority data cluster set;

[0033] For the third priority data set, aggregate data items with low access frequency or high storage consumption to obtain the third priority data cluster set;

[0034] During the aggregation process, clustered subsets within the same priority data set remain independent and do not cross-aggregate with clustered subsets of other priority data sets.

[0035] Furthermore, when insufficient storage capacity is detected, the following measures are taken:

[0036] The backup units that are insufficient in storage capacity are located, and these backup units include edge-side local backup units, private cloud backup clusters, and public cloud backup clusters.

[0037] For backup units with insufficient storage capacity, retain the complete storage of the high-priority data cluster set corresponding to the backup unit, and compress or migrate the low-priority data cluster set within the backup unit with insufficient storage capacity.

[0038] If the capacity of the local backup unit on the edge side is insufficient, the data with low access frequency in the third priority data cluster set stored therein will be migrated to the reserved space of the private cloud backup cluster.

[0039] If the private cloud backup cluster has insufficient capacity, migrate the third priority data cluster set stored thereto to the public cloud backup cluster and encrypt and mark it as migration data;

[0040] If the public cloud backup cluster has insufficient capacity, the third priority data cluster set stored therein will be compressed and stored to retain critical information.

[0041] Furthermore, in the event of a link interruption, the following includes:

[0042] Locate the specific location of the link interruption. The link includes the first transmission link between the edge-side local backup unit and the private cloud backup cluster, and the second transmission link between the private cloud backup cluster and the public cloud backup cluster.

[0043] If the first transmission link is interrupted, the second priority data cluster set to be transmitted from the edge side to the private cloud will be temporarily stored in the temporary buffer of the local backup unit on the edge side, and the transmission of the third priority data will be suspended at the same time.

[0044] If the second transmission link is interrupted, the third priority data cluster set to be transmitted from the private cloud to the public cloud will be marked as pending transmission and stored in the temporary extended partition of the private cloud. Incremental logging will be started for the second priority data cluster set, and only the data update part will be cached.

[0045] During the link interruption, the recovery status of the interrupted link is monitored in real time, and a link reconnection attempt is triggered every preset time interval;

[0046] Once the link is restored, transmission is resumed sequentially in the order of updated data associated with the first priority data cluster set, cached data of the second priority data cluster set, and data to be transmitted of the third priority data cluster set, while also retransmitting incremental data generated during the interruption.

[0047] Furthermore, when the backup progress delay exceeds the progress threshold, including:

[0048] The actual backup progress of each priority data cluster is compared with the progress threshold to determine the priority data clusters whose delay exceeds the progress threshold;

[0049] When the delay of the first priority data cluster set exceeds the progress threshold, the reserved high-speed transmission channel is activated for the first priority data cluster set, the backup task of the third priority data cluster set is suspended, and the high-speed transmission channel resources are temporarily allocated to the first priority.

[0050] For the second priority data cluster set, incremental backup is used instead of full backup, and only the data that differs from the previous backup is transmitted.

[0051] When the backup progress of the first priority data cluster catches up with the planned progress, the temporarily occupied channel resources are released, and the backup tasks of the second and third priorities are resumed.

[0052] Furthermore, when periodically performing data recovery drills on the data backups of the aforementioned three-level backup priority set, the following includes:

[0053] The exercise cycle is set in the order of the first priority data cluster set, the second priority data cluster set, and the third priority data cluster set, with the exercise cycle of the first priority data cluster set, the second priority data cluster set, and the third priority data cluster set gradually increasing;

[0054] During the exercise, data loss scenarios were simulated for each priority data cluster set. Backup data was extracted from the corresponding backup unit for recovery, and the integrity of the recovered data was verified.

[0055] If data corruption or recovery failure is found during the exercise, it will be marked as an exercise anomaly. The cause will be traced and the backup strategy will be updated. At the same time, the anomaly record and the handling results will be stored in the backup log.

[0056] Compared with existing technologies, the beneficial effects of this invention are as follows: By preprocessing data at the edge and identifying and classifying data based on security rules, a secure hierarchical management of data is achieved, effectively ensuring the security of highly sensitive information; by combining a three-level backup priority based on business criticality and clustering optimization based on access frequency and storage usage, the utilization efficiency of backup resources and the cost-effectiveness of storage are improved in a hybrid cloud environment; by dynamically monitoring storage load, link status, and backup progress, and intelligently scheduling resources according to priority, the reliability and timeliness of data backup tasks of different priorities are ensured, enhancing the system's resilience in the face of emergencies; regular data recovery drills further verify the availability of backup data and the effectiveness of the recovery process, thereby comprehensively improving the management efficiency, security protection level, backup reliability, and business continuity assurance capabilities of the elevator network data in a hybrid cloud architecture.

[0057] On the other hand, this application also provides a data management and backup system for elevator networks under a hybrid cloud architecture, used to implement the aforementioned data management and backup method for elevator networks under a hybrid cloud architecture, including:

[0058] Acquisition Unit: A data acquisition node is set up on the edge side to access the raw data stream of the elevator terminal equipment, and the raw data stream is processed to generate preprocessed data;

[0059] Sensitivity identification and encryption unit: The preprocessed data is identified for sensitivity according to the security rule base to obtain high-sensitivity data, medium-sensitivity data and low-sensitivity data. The high-sensitivity data and medium-sensitivity data are encrypted to generate encrypted data segments, and the low-sensitivity data is retained as plaintext data segments.

[0060] Backup Unit: The encrypted data segments and plaintext data segments are divided into three-level backup priority sets according to business criticality. The three-level backup priority sets are a first priority data set, a second priority data set, and a third priority data set. The first priority data set, the second priority data set, and the third priority data set are aggregated using a clustering algorithm based on data access frequency and storage usage to obtain a first priority data cluster set, a second priority data cluster set, and a third priority data cluster set. The first priority data cluster set, the second priority data cluster set, and the third priority data cluster set are then sequentially allocated to the edge-side local backup unit, the private cloud backup cluster, and the public cloud backup cluster of the hybrid cloud architecture.

[0061] Backup Status Unit: Monitors the storage load, transmission link status and data backup progress of the three-level backup priority set. When it detects insufficient storage capacity, link interruption or backup progress delay exceeding the progress threshold, it adjusts the backup task queue or allocates backup channel resources and triggers resource scheduling according to backup priority.

[0062] The exercise unit: regularly conducts data recovery exercises on the data backup of the aforementioned three-level backup priority set. It is understood that the above-described method and system for elevator network data management and backup under a hybrid cloud architecture has the same beneficial effects, and will not be elaborated further here. Attached Figure Description

[0063] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings:

[0064] Figure 1 A flowchart illustrating a method for managing and backing up elevator network data under a hybrid cloud architecture, provided in an embodiment of the present invention;

[0065] Figure 2 This is a structural framework diagram of a ladder network data management and backup system under a hybrid cloud architecture, provided for an embodiment of the present invention. Detailed Implementation

[0066] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided to enable a more thorough understanding of the present disclosure and to fully convey the scope of the disclosure to those skilled in the art. It should be noted that, unless otherwise specified, embodiments and features in the embodiments of the present invention can be combined with each other. The present invention will now be described in detail with reference to the accompanying drawings and embodiments.

[0067] In some embodiments of this application, see Figure 1 As shown, a method for elevator network data management and backup under a hybrid cloud architecture includes:

[0068] S100: Set up a data acquisition node on the edge side to access the raw data stream of the elevator terminal equipment, process the raw data stream, and generate preprocessed data;

[0069] S200: The preprocessed data is identified for sensitivity based on the security rule base to obtain high-sensitivity data, medium-sensitivity data and low-sensitivity data. The high-sensitivity data and medium-sensitivity data are encrypted to generate encrypted data segments, while the low-sensitivity data is retained as plaintext data segments.

[0070] S300: Encrypted data segments and plaintext data segments are divided into three levels of backup priority sets according to business criticality. The three levels of backup priority sets are the first priority data set, the second priority data set, and the third priority data set. The first priority data set, the second priority data set, and the third priority data set are aggregated using a clustering algorithm based on data access frequency and storage usage to obtain the first priority data cluster set, the second priority data cluster set, and the third priority data cluster set. The first priority data cluster set, the second priority data cluster set, and the third priority data cluster set are then allocated to the edge-side local backup unit, the private cloud backup cluster, and the public cloud backup cluster of the hybrid cloud architecture in sequence.

[0071] S400: Monitors the storage load, transmission link status and data backup progress of the three-level backup priority set. When it detects insufficient storage capacity, link interruption or backup progress delay exceeding the progress threshold, it adjusts the backup task queue or allocates backup channel resources and triggers resource scheduling according to backup priority.

[0072] S500: Regularly perform data recovery drills for data backups of the three-level backup priority set.

[0073] Specifically, data acquisition nodes are set up at the edge to access the raw data stream of the elevator terminal equipment. The raw data stream includes operating status data transmitted by the elevator controller, vibration data collected by sensors, temperature data collected by sensors, video stream inside the car captured by the camera, door opening and closing status data fed back by the door operator system, and load data recorded by the weighing device. The data acquisition nodes process the raw data stream by cleaning and filtering noise data and filling in missing values ​​caused by transmission interruption, converting the format to unify heterogeneous data into a standard format, and extracting key feature values ​​and removing redundant information through dimensionality reduction to generate preprocessed data. Preprocessed data undergoes sensitivity identification based on a security rule base. This base includes historical security data and sensitivity classification rules. Historical security data is derived from analyzing historical operational data of the elevator network. Sensitivity classification rules categorize data into high-sensitivity, medium-sensitivity, and low-sensitivity based on data leakage risk thresholds. During identification, the preprocessed data is first compared with historical security data to identify data that matches these thresholds. Then, the data is classified according to the sensitivity classification rules. Data leakage risk thresholds are divided into high-risk and low-risk thresholds, with the low-risk threshold being lower than the high-risk threshold. Data greater than or equal to the high-risk threshold is considered high-sensitivity; data greater than the low-risk threshold but less than the high-risk threshold is considered medium-sensitivity; and data less than or equal to the low-risk threshold is considered low-sensitivity. After obtaining these three categories, high-sensitivity and medium-sensitivity data are encrypted to generate encrypted data segments, while low-sensitivity data is preserved as plaintext data segments. Next, the encrypted and plaintext data segments are divided into three priority backup sets based on business criticality. Business criticality is quantified using a weighted scoring model, which includes a data failure impact factor calculated based on the risk of elevator downtime, maintenance delay costs, and safety compliance penalties caused by data loss; a real-time requirement factor determined based on the urgency of the data; and an associated equipment scope factor set according to the number of elevators or the size of the groups affected by the data. The data is input into the model to obtain a business criticality score, which is then divided according to the scoring threshold. The scoring threshold is divided into a high-risk scoring threshold and a low-risk scoring threshold, with the low-risk scoring threshold being less than the high-risk scoring threshold. Data sets with scores greater than or equal to the high-risk scoring threshold are classified as first priority data sets, data sets with scores greater than or equal to the low-risk scoring threshold but less than the high-risk scoring threshold are classified as second priority data sets, and data sets with scores less than the low-risk scoring threshold are classified as third priority data sets.Then, a clustering algorithm based on data access frequency and storage usage is used to aggregate the three-level sets: the priority data set is divided into priority data sets based on the importance of data with clear business criticality, ensuring that high-priority data, such as core data affecting the safe operation of elevators, receives priority resource protection. Further clustering yields priority data cluster sets, which aggregate data with similar characteristics within the same priority based on data access frequency and storage usage, such as high-frequency access with small capacity and low-frequency access or large capacity. The significance is that data storage is more accurately adapted to the performance and cost characteristics of each node of the hybrid cloud, edge side local backup unit, private cloud, and public cloud. For example, the edge side is suitable for high-frequency access and small capacity data for fast response, while the public cloud is suitable for low-frequency access or large capacity data to optimize costs, improve storage resource utilization and access efficiency, and achieve dual optimization of business priority and data characteristics, better supporting large-scale elevator network data management. For each priority data set, the access frequency and data storage usage per unit time are statistically analyzed for each data item, forming access-to-storage feature values. Similarity between data items is calculated based on these feature values, and aggregation is performed according to access frequency and storage usage. The first priority data set aggregates data items with high access frequency and low storage usage to obtain the first priority data cluster set. The second priority data set aggregates data items with medium access frequency and moderate storage usage to obtain the second priority data cluster set. The third priority data set aggregates data items with low access frequency or high storage usage to obtain the third priority data cluster set. Furthermore, clusters within the same priority data set remain independent and do not cross-aggregate with other priority clusters. Finally, the first, second, and third priority data cluster sets are sequentially allocated to the edge-side local backup unit, private cloud backup cluster, and public cloud backup cluster of the hybrid cloud architecture. Simultaneously, the system monitors the storage load, transmission link status, and data backup progress of the three-tier backup priority set. When insufficient storage capacity, link interruption, or backup progress delay exceeding the progress threshold is detected, the system adjusts the backup task queue or allocates backup channel resources, triggering resource scheduling based on backup priority: When storage capacity is insufficient, the system locates the insufficient backup units, retains the complete storage of the high-priority data cluster set corresponding to the insufficient backup units, and compresses or migrates the low-priority data cluster set within the unit. When the local backup unit on the edge side is insufficient, the system migrates the data with low access frequency in the third-priority data cluster set stored thereto to the reserved space in the private cloud backup cluster. When the private cloud backup cluster is insufficient, the system migrates the third-priority data cluster set stored thereto to the public cloud backup cluster and encrypts and marks it as migrated data. When the public cloud backup cluster is insufficient, the system compresses and stores the third-priority data cluster set stored thereto, while retaining critical information.When a link is interrupted, the interruption location is located, including the first transmission link between the edge and the private cloud, and the second transmission link between the private cloud and the public cloud. When the first transmission link is interrupted, the second priority data cluster set to be transmitted from the edge to the private cloud is temporarily stored in the edge temporary cache area, and the third priority data transmission is suspended. When the second transmission link is interrupted, the third priority data cluster set to be transmitted from the private cloud to the public cloud is marked as pending transmission and stored in the private cloud temporary extended partition. Incremental logging is started for the second priority data cluster set, caching only the updated part. During the interruption, the recovery status is monitored in real time, and a link reconnection attempt is triggered once every preset time interval. After recovery, transmission is resumed in the order of first priority associated updated data, second priority cached data, and third priority pending transmission data, with priority given to retransmitting incremental data generated during the interruption. When the backup progress delay exceeds the progress threshold, the actual backup progress of each priority is compared with the progress threshold to determine the set of delays. When the first priority is delayed, the reserved high-speed transmission channel is activated, the third priority backup task is suspended, and the channel resources are temporarily allocated to the first priority. For the second priority, incremental backup is used instead of full backup, and only the data that differs from the last backup is transmitted. When the progress of the first priority catches up with the plan, the temporary resources are released, and the second and third priority backup tasks are resumed. In addition, data recovery drills are conducted regularly for the data backup of the three-level backup priority sets. The drill cycle is set in the order of the first priority data cluster set, the second priority data cluster set, and the third priority data cluster set, and the cycle gradually increases. During the drill, data loss scenarios are simulated for each priority, and backup data is extracted from the corresponding backup unit for recovery to verify the integrity of the recovered data. If data corruption or recovery failure is found, it is marked as a drill anomaly, the cause is traced, the backup strategy is updated, and the anomaly record and processing results are stored in the backup log.

[0074] Understandably, by collecting and preprocessing elevator network data, grading and encrypting data based on sensitivity, clustering and storing data based on priority, dynamically monitoring and scheduling data, and conducting regular recovery drills, this method achieves secure management of the entire data lifecycle. While ensuring data security, it balances storage costs, access efficiency and business continuity, effectively supporting the intelligent management of large-scale elevator clusters.

[0075] In some embodiments of this application, when performing sensitivity identification on preprocessed data according to a security rule base, the following is included:

[0076] The security rule base contains historical security data and sensitivity classification rules. The historical security data is obtained by analyzing the historical operation data of the elevator network. The sensitivity classification rules divide data into high-sensitivity data, medium-sensitivity data and low-sensitivity data according to the data leakage risk threshold.

[0077] When identifying preprocessed data, the preprocessed data is compared with historical security data to obtain data to be classified that matches the historical security data. According to the sensitivity classification rules, the data to be classified is divided into high-sensitivity data, medium-sensitivity data and low-sensitivity data.

[0078] Understandably, summarizing refers to the process of systematically reviewing historical data generated by the elevator network's past operations and extracting historical security data. Specifically, this includes: collecting historical operational data such as records of data breaches, security violations, compliance inspection results, and data access logs from multiple past operating cycles; using a combination of statistical analysis and risk modeling to deeply mine this historical data, identifying key characteristics such as which types of data have been breached, the direct and indirect losses caused by each breach, and the scope of data breach propagation; and finally integrating these characteristics into structured historical security data, including data type tags, breach probability information, and breach impact levels, providing a reference benchmark for sensitivity identification of subsequent preprocessed data. The data breach hazard threshold is a critical value used to quantitatively assess the degree of data breach risk. It combines the data security requirements in elevator industry safety standards, references actual loss cases caused by data breaches in enterprises, and introduces a risk matrix model for quantitative calculation. The data breach hazard threshold is clearly divided into high-risk and low-risk thresholds, with the low-risk threshold being lower than the high-risk threshold. The high-risk threshold corresponds to a risk level where data leakage could lead to elevator safety accidents, significant economic losses, or serious compliance risks; the low-risk threshold corresponds to a risk level where data leakage would only cause minor losses or have no direct safety impact. In the actual identification process, the preprocessed data is first compared with historical safety data to filter out data that meets the preset standards for classification; then, the risk assessment value of the data to be classified is compared with the above thresholds. If the assessment value is greater than or equal to the high-risk threshold, it is determined to be high-sensitive data; if the assessment value is greater than the low-risk threshold but less than the high-risk threshold, it is determined to be medium-sensitive data; and if the assessment value is less than or equal to the low-risk threshold, it is determined to be low-sensitive data, thereby achieving accurate classification of data sensitivity.

[0079] In some embodiments of this application, dividing the data to be segmented into high-sensitivity data, medium-sensitivity data, and low-sensitivity data includes:

[0080] The data breach risk threshold is divided into a high-risk threshold and a low-risk threshold, with the low-risk threshold being lower than the high-risk threshold.

[0081] Data to be classified is classified as high-sensitivity data when it is greater than or equal to the high-risk threshold.

[0082] When the data to be classified is greater than the low-risk threshold and less than the high-risk threshold, it is classified as medium-sensitivity data.

[0083] Data that is less than or equal to the low-risk threshold is classified as low-sensitivity data.

[0084] Understandably, the purpose of defining data breach risk thresholds is to clearly define the boundaries between different levels of risk, thereby accurately distinguishing the sensitivity of data. The high-risk and low-risk thresholds are determined comprehensively based on the elevator industry's basic data security requirements, the actual impact of past data breaches, and the company's specific data protection standards. The low-risk threshold is always lower than the high-risk threshold. In practice, the risk level of the data to be classified is first assessed and converted into a comparable numerical value. When the risk value of the data reaches or exceeds the high-risk threshold, it indicates that the data breach could lead to serious consequences, and is therefore classified as high-sensitivity data. When the risk value of the data is between the low-risk and high-risk thresholds, it means that the breach would have some impact, but not as severe as high-sensitivity data, and is therefore classified as medium-sensitivity data. When the risk value is below or equal to the low-risk threshold, it indicates that the impact of the breach is relatively small, and is therefore classified as low-sensitivity data. This classification allows for different protection measures to be taken based on the actual risk level of the data, achieving targeted security management.

[0085] In some embodiments of this application, when dividing encrypted data segments and plaintext data segments into a three-level backup priority set based on business criticality, the following is included:

[0086] Business criticality is quantified and determined using a weighted scoring model, which includes data failure impact factors, real-time requirement factors, and related equipment range factors.

[0087] Data failure impact factor: calculated based on the risk of elevator downtime, maintenance delay costs, and safety compliance penalties caused by missing data;

[0088] Real-time requirement factor: determined based on the urgency of the data;

[0089] Related equipment scope factor: set according to the number of elevators or the size of the group affected by the data;

[0090] The encrypted data segment and the plaintext data segment are input into the weighted scoring model, and the business criticality score value is output. The low-risk score threshold is less than the high-risk score threshold.

[0091] When the business criticality score is greater than or equal to the high-risk score threshold, it is determined to be the first priority data set;

[0092] When the business criticality score is greater than or equal to the low-risk score threshold but less than the high-risk score threshold, it is determined to be the second priority data set;

[0093] When the business criticality score is less than the low-risk score threshold, it is determined to be the third priority data set.

[0094] Understandably, the data failure impact factor is determined by comprehensively considering the various actual losses that data loss may cause. This involves collecting past records of elevator outages due to similar data loss, analyzing the probability of such outages, their average duration, and the operational losses incurred during this period. These losses include compensation for user complaints, costs of emergency dispatching of maintenance resources, brand reputation damage during elevator outages, expenses for arranging temporary alternative transportation, and contract penalties for service interruptions. Simultaneously, for cases where missing statistical data leads to extended maintenance cycles, the increased maintenance costs are calculated by combining the time and resource input required for routine maintenance. The results of these three assessments are then weighted according to business priorities and summarized to obtain the data failure impact factor. The real-time requirement factor focuses on the time urgency of the data. The core is defining the longest permissible time from data generation to the mandatory backup period—the effective window period. Depending on the business scenario of the data, the length of the window period varies significantly. For example, urgent data requiring immediate response has a very short window period, while periodically aggregated data has a longer window period. Different window periods are then mapped to corresponding scores. A shorter window period indicates higher data urgency, resulting in a higher score. This transforms the time sensitivity of the data into quantifiable factor scores. For example: a window period of 30 minutes or less is scored as 80-100 points; a window period greater than 30 minutes but less than or equal to 24 hours is scored as 50-79 points; a window period greater than 24 hours but less than or equal to 7 days is scored as 20-49 points; and a window period greater than 7 days is scored as 0-19 points. The associated equipment scope factor is determined based on the number of elevators or the size of the group that may be affected after data failure. The classification starts with affecting only a single elevator and gradually expands to affecting elevators in the same building, the same park, a larger area, or even a large-scale cluster. Each level corresponds to a different score. The more elevators affected and the larger the group size, the wider the data's impact, and the higher the associated equipment scope factor score. When encrypted and plaintext data segments are input into the weighted scoring model, feature extraction is first performed on these data to clarify the specific performance of each data point in three aspects: data failure impact, real-time requirements, and related device scope. This determines the scores for each data point's data failure impact factor, real-time requirement factor, and related device scope factor. Next, the model calculates the business criticality score using a linear weighted summation method. Specifically, corresponding weights are assigned to each of the three factors. These weights are determined based on actual business needs and reflect the importance of different factors in business evaluation. Then, the score of each factor is multiplied by its corresponding weight, and these three products are summed to obtain the business criticality score for that data. This score directly reflects the importance of the data in the business, providing a quantitative basis for subsequently dividing the data into different backup priority sets.The specific process of inputting encrypted and plaintext data segments into a weighted scoring model to output business criticality scores and categorize them according to scoring thresholds is as follows: First, feature extraction is performed on the input encrypted and plaintext data segments to clarify the specific characteristics of each data point in the three dimensions of data failure impact, real-time requirements, and related device scope. That is, the data failure impact factor score, the real-time requirement factor score, and the related device scope factor score corresponding to each data point are determined. Next, the weighted scoring model performs a linear weighted calculation on the scores of these three factors according to preset weights (the weights are set according to actual business needs to reflect the different importance of the three factors in business evaluation). That is, the score of each factor is multiplied by its weight in relation to the data failure impact factor, the real-time requirement factor score, and the related device scope factor score. After weighting, the data are summed to obtain the business criticality score, which directly reflects the importance of the data in the business. Then, the obtained business criticality score is compared with the preset scoring thresholds, which are divided into high-risk and low-risk scoring thresholds, with the low-risk scoring threshold being less than the high-risk scoring threshold. When the score is greater than or equal to the high-risk scoring threshold, the data is assigned to the first priority data set; when the score is greater than or equal to the low-risk scoring threshold but less than the high-risk scoring threshold, it is assigned to the second priority data set; and when the score is less than the low-risk scoring threshold, it is assigned to the third priority data set, thus completing the three-level backup priority division based on business criticality.

[0095] In some embodiments of this application, when aggregating the first priority data set, the second priority data set, and the third priority data set using a clustering algorithm based on data access frequency and storage usage, the following steps are included:

[0096] For each data item in the priority data set, the access frequency and data storage usage per unit time are statistically analyzed to form the access and storage characteristic value of the data item.

[0097] The similarity between data items is calculated based on access storage feature values, and the data items are aggregated into the same data cluster set according to access frequency and storage usage.

[0098] For the first priority data set, aggregate the data items with high access frequency and low storage consumption to obtain the first priority data cluster set;

[0099] For the second priority data set, aggregate the data items with moderate access frequency and moderate storage consumption to obtain the second priority data cluster set;

[0100] For the third priority data set, aggregate data items with low access frequency or high storage consumption to obtain the third priority data cluster set;

[0101] During the aggregation process, clustered subsets within the same priority data set remain independent and do not cross-aggregate with clustered subsets of other priority data sets.

[0102] Understandably, this aggregation process achieves efficient aggregation of similar data by performing refined analysis of the access and storage characteristics of data items within each priority data set. For each data item in each priority data set, a uniform unit time is set. This unit time is determined based on the actual business cycle of elevator network data access. The number of times the data is queried, accessed, or analyzed within this unit time is counted, serving as the access frequency. Simultaneously, the storage space occupied by each data item is calculated, including the total capacity of the data itself and related metadata. The access frequency and storage usage are combined into a two-dimensional access-storage feature value, which serves as the feature identifier of the data item. Based on these access-storage feature values, the similarity between data items is calculated: using metrics such as Euclidean distance and Manhattan distance, the distance between the feature values ​​of any two data items is calculated. The smaller the distance, the closer the characteristics of the two data items are in terms of access frequency and storage usage, and the higher the similarity. Data items are clustered according to aggregation criteria based on priority levels: For the first priority data set, data items with significantly higher access frequency than other data items in the same set and significantly lower storage consumption are selected. These data items with similar characteristics are aggregated into a first priority data cluster set to ensure that frequently accessed, small-capacity critical data can be retrieved quickly. For the second priority data set, data items with access frequency in the middle range of the set and moderate storage consumption are selected. These data items with similar characteristics are aggregated into a second priority data cluster set to balance access efficiency and storage requirements. For the third priority data set, two types of data items are aggregated: one type has an access frequency lower than the set threshold, and the other type has a storage consumption greater than the set threshold. As long as either condition is met, the data item is included to form a third priority data cluster set, which is suitable for the storage characteristics of low-frequency access or large-capacity data. Throughout the aggregation process, the principle of independent clustering subsets within the same priority data set is strictly followed: the first priority clustering subset only includes data items with similar features within the first priority data set, and never includes data items of the second or third priority. Similarly, the second and third priority clustering subsets are also aggregated only within their respective original sets, avoiding cross-mixing of data of different priorities. This ensures that when the data is subsequently allocated to different backup units such as the edge, private cloud, and public cloud, the data access efficiency and storage adaptability are not affected.

[0103] In some embodiments of this application, when insufficient storage capacity is detected, the following is included:

[0104] The backup units are located where storage capacity is insufficient. These backup units include edge-side local backup units, private cloud backup clusters, and public cloud backup clusters.

[0105] For backup units with insufficient storage capacity, retain the complete storage of the high-priority data cluster set corresponding to the backup unit, and compress or migrate the low-priority data cluster set within the backup unit with insufficient storage capacity.

[0106] If the capacity of the local backup unit on the edge side is insufficient, the data with low access frequency in the third priority data cluster set stored therein will be migrated to the reserved space of the private cloud backup cluster.

[0107] If the private cloud backup cluster has insufficient capacity, migrate the third priority data cluster set stored thereto to the public cloud backup cluster and encrypt and mark it as migration data;

[0108] If the public cloud backup cluster has insufficient capacity, the third priority data cluster set stored therein will be compressed and stored to retain critical information.

[0109] Understandably, when the system detects insufficient storage capacity, it first triggers an early warning mechanism by monitoring the storage utilization of each backup unit in real time. This accurately identifies the backup unit experiencing insufficient capacity, determining whether it is an edge-side local backup unit, a private cloud backup cluster, or a public cloud backup cluster facing storage pressure. The storage utilization rate for triggering the alarm mechanism can be set by the user. During processing, the principle of prioritizing high-priority data is always followed. For backup units with insufficient capacity, the system ensures that the high-priority data clusters stored within them remain intact, without any compression or migration operations. This guarantees that this business-critical data is always efficiently accessible and its integrity is unaffected. For low-priority data clusters stored within backup units with insufficient storage capacity, compression or migration operations are performed as needed to free up storage space. If the local backup unit at the edge is found to be insufficient in capacity, since the edge needs to prioritize rapid response to frequently accessed critical data, low-frequency access data will be selected from its stored third-priority data clusters. This low-frequency data has minimal impact on real-time business operations at the edge after migration, and will be migrated to the dedicated storage space of the private cloud backup cluster. This alleviates storage pressure on the edge and temporarily utilizes the private cloud's storage resources. If the private cloud backup cluster is found to be insufficient in capacity, considering that the core function of the private cloud is to store high-priority data, its stored third-priority data clusters will be migrated entirely to the public cloud backup cluster. The migrated data will be encrypted and marked as migrated data. This alleviates pressure through the elastic storage capabilities of the public cloud while ensuring data security and traceability through encryption and marking. If the public cloud backup cluster is insufficient in capacity, given that it mainly stores low-frequency access or large-volume third-priority data, these data clusters will be compressed. During compression, critical information will be strictly preserved to ensure that the compressed data can still meet subsequent query and recovery needs, reducing storage usage without losing core value.

[0110] In some embodiments of this application, the following are included when the link is interrupted:

[0111] Locate the specific location of the link interruption. The link includes the first transmission link between the edge-side local backup unit and the private cloud backup cluster, and the second transmission link between the private cloud backup cluster and the public cloud backup cluster.

[0112] If the first transmission link is interrupted, the second priority data cluster set to be transmitted from the edge side to the private cloud will be temporarily stored in the temporary buffer of the local backup unit on the edge side, and the transmission of the third priority data will be suspended at the same time.

[0113] If the second transmission link is interrupted, the third priority data cluster set to be transmitted from the private cloud to the public cloud will be marked as pending transmission and stored in the temporary extended partition of the private cloud. Incremental logging will be started for the second priority data cluster set, and only the data update part will be cached.

[0114] During the link interruption, the recovery status of the interrupted link is monitored in real time, and a link reconnection attempt is triggered every preset time interval;

[0115] Once the link is restored, transmission is resumed sequentially in the order of updated data associated with the first priority data cluster set, cached data of the second priority data cluster set, and data to be transmitted of the third priority data cluster set, while also retransmitting incremental data generated during the interruption.

[0116] Understandably, the real-time link status monitoring mechanism is a dynamic monitoring system that continuously runs on all nodes of the hybrid cloud architecture. Through multi-dimensional indicator collection and intelligent analysis, it perceives the communication status of two transmission links in real time. The real-time link status monitoring mechanism relies on monitoring agents deployed on nodes in the edge, private cloud, and public cloud. At very short intervals, based on the real-time requirements of link transmission, it sends fixed-format link detection data packets to the peer node. These data packets contain timestamps, checksums, and other identifying information. Simultaneously, the system continuously collects and records key operational indicators of the two links, including data packet transmission success rate, reception response time, packet loss rate, communication signal strength, and the continuous stability of the link connection, such as whether periodic jitter or momentary disconnections occur. For the first transmission link, i.e., the link between the edge and the private cloud, the monitoring mechanism makes a judgment by comparing the detection packets sent by the edge with the acknowledgment packets returned by the private cloud. If, after several consecutive attempts based on the link reliability requirements, no acknowledgment response is received from the private cloud, and the business data packets from the edge to the private cloud are completely undeliverable without any interactive feedback, the first transmission link is determined to be interrupted. For the second transmission link, which is the link between the private cloud and the public cloud, the monitoring mechanism judges the interruption by comparing the detection packets sent by the private cloud with the response status of the public cloud. If the detection packets sent by the private cloud continue to time out without being acknowledged, and the planned business data to be transmitted remains in the "transmission in progress" state for an extended period without any progress updates, the second transmission link is determined to be interrupted. If the first transmission link is determined to be interrupted, since the transmission between the edge side and the private cloud mainly involves second and third priority data, the security of the second priority data will be prioritized: the second priority data originally planned to be transmitted from the edge side to the private cloud will be clustered and temporarily stored in the temporary cache area of ​​the local backup unit on the edge side. The temporary cache area has short-term high-reliability storage capabilities to avoid data loss; at the same time, the transmission of third priority data will be suspended to reduce the resource consumption on the edge side and ensure that the temporary cache area has sufficient space to accommodate the second priority data. If the transmission link is determined to be interrupted in the second priority stage, differentiated processing will be applied to data of different priorities in the transmission scenario between the private cloud and the public cloud: For the third priority data cluster set that the private cloud plans to transmit to the public cloud, it will be marked as pending transmission and stored in a temporary extended partition in the private cloud. The temporary extended partition is a reserved elastic storage space specifically used to temporarily store the data to be transmitted. For the second priority data cluster set, due to its high update frequency, an incremental logging mechanism will be activated to cache only the updated part of the data during the interruption, which reduces storage pressure and accurately records data changes. Throughout the link interruption process, the system will continuously send link detection data packets to monitor the recovery status of the interrupted link in real time. Every few minutes to tens of minutes, depending on the urgency of the business, a link reconnection attempt will be automatically triggered to ensure a response as soon as the link is restored.Once the link is restored, to ensure efficient data transmission and prioritize data based on importance, transmission will resume according to the principle of high priority first: First, the updated data of the first priority data cluster will be transmitted; then, the cached data of the second priority data cluster that was temporarily stored during the interruption will be transmitted; finally, the accumulated data of the third priority data cluster marked as pending transmission will be transmitted. During this process, incremental content generated by each priority data during the interruption will be prioritized for retransmission to ensure the integrity and continuity of all data and avoid data loss due to the interruption.

[0117] In some embodiments of this application, when the backup progress delay exceeds a progress threshold, the following is included:

[0118] The actual backup progress of each priority data cluster is compared with the progress threshold to determine the priority data clusters whose delay exceeds the progress threshold;

[0119] When the delay of the first priority data cluster set exceeds the progress threshold, the reserved high-speed transmission channel is enabled for the first priority data cluster set, the backup task of the third priority data cluster set is suspended, and the high-speed transmission channel resources are temporarily allocated to the first priority.

[0120] For the second priority data cluster set, incremental backup is used instead of full backup, and only the data that differs from the previous backup is transmitted.

[0121] When the backup progress of the first priority data cluster catches up with the planned progress, the temporarily occupied channel resources are released, and the backup tasks of the second and third priorities are resumed.

[0122] Understandably, the progress threshold here is a time threshold directly related to the data size, and its determination is entirely based on the actual operation records of historical backup data. The system will first review the complete backup process of data of different sizes in past backup tasks, and calculate the actual time taken for each size of data from the start of backup to the completion of backup, including the time spent on the entire process of data reading, transmission, verification, and storage, forming a historical correspondence database of data size and backup time. Based on this, benchmark time standards are established for datasets of different sizes: for example, if the historical average backup time for 100MB of first-priority data is 5 minutes, then the progress threshold for 100MB of first-priority data is set to 5 minutes; if the historical average backup time for 2GB of third-priority data is 1 hour, then a progress threshold of 1 hour is set for 2GB of third-priority data. This threshold setting method is fine-tuned based on data priority. High-priority data, due to its higher transmission and processing priority, usually has a more stable historical backup time, and the threshold will strictly refer to its historical average time. Low-priority data may have slightly different historical times due to fluctuations in resource allocation, and the threshold will be 1.2-1.5 times its historical average time as a buffer, which both reflects actual efficiency and reserves reasonable fault tolerance. When the current backup task starts, the system will first identify the actual size of the data to be backed up, and then refer to the historical data size-time correspondence to retrieve the historical average time corresponding to that size of data as the current progress threshold. For example, if 150MB of second-priority data needs to be backed up, and historically, the average backup time for 150MB of second-priority data is 8 minutes, then the progress threshold for this backup is set to 8 minutes. If the actual backup time exceeds 8 minutes, it is considered a progress delay. If the delay of the first-priority data cluster exceeds the progress threshold, since this type of data is crucial to business continuity, the system will immediately activate an emergency response mechanism: activating a dedicated high-speed transmission channel, which has higher bandwidth and transmission efficiency and is normally on standby only for urgent needs of high-priority tasks; simultaneously suspending the backup task of the third-priority data cluster, releasing the transmission resources it occupies, and temporarily allocating all resources of the high-speed transmission channel to the first-priority data cluster to maximize its transmission speed and accelerate the backup progress. For the second-priority data cluster, even if it has not reached the delay threshold or is in a delayed state, incremental backup will be used instead of the original full backup. That is, by comparing the current data with the content of the last backup, only the newly added or changed difference data is extracted and transmitted, rather than transmitting the entire dataset, thereby reducing the amount of data to be transmitted, improving backup efficiency, and shortening the completion time.To determine whether the backup progress of the first priority data cluster is within the planned schedule, it is necessary to dynamically compare the real-time progress with the planned progress. The specific process is as follows: The system will preset a time-data-volume planned progress curve for the backup task of the first priority data cluster. This curve is generated based on the total data size and the corresponding progress threshold. The progress threshold is the historical average time to back up data of this size, specifying the cumulative amount of backup data to be completed at each time point in the backup process. For example, for a task with a total size of 200MB and a progress threshold of 10 minutes, the plan is to complete 100MB in the 5th minute and 200MB in the 10th minute. During the backup process, the system collects the actual backup data volume and the time consumed for the first priority data cluster in real time, updates the actual progress point every short interval, and compares it with the planned progress curve. If at a certain moment, the actual amount of backup data completed reaches or exceeds the amount of data to be completed at that moment, for example, 120MB is actually completed at the 6th minute, exceeding the planned 120MB, then it is preliminarily determined that the progress has caught up with the planned range. The system verifies the match between the remaining unbacked-up data volume and the remaining available time: the remaining data volume is obtained by subtracting the completed volume from the total data volume, and the remaining time is obtained by subtracting the consumed time from the progress threshold. If the remaining data volume can be completed within the remaining time at the current transmission speed, it further confirms that the progress has stably caught up with the plan, and there is no risk of further delay. In addition, for the first priority data containing incremental updates, it will also check whether the incremental data generated during the interruption has been synchronized and completed. Only when the backup progress of both the original data and the incremental data meets the planned requirements, and the real-time transmission speed remains stable, will it be finally determined that the backup progress of the first priority data cluster has caught up with the planned progress. At this time, the temporarily occupied resources can be released, and the normal backup of other priority tasks can be resumed. When the backup progress of the first priority data cluster catches up with the planned progress through resource allocation, the system will promptly release the temporarily occupied high-speed transmission channel resources, stop the pause of the third priority backup task, and resume the normal backup process of the second and third priority data clusters, ensuring that each priority task proceeds in sequence, thus guaranteeing the timeliness of core data and maintaining the balanced operation of the overall backup system.

[0123] In some embodiments of this application, when periodically performing data recovery drills on data backups of a three-level backup priority set, the following steps are included:

[0124] The exercise cycle is set in the order of first priority data cluster set, second priority data cluster set, and third priority data cluster set, with the exercise cycle of the first priority data cluster set, second priority data cluster set, and third priority data cluster set increasing progressively;

[0125] During the exercise, data loss scenarios were simulated for each priority data cluster set. Backup data was extracted from the corresponding backup unit for recovery, and the integrity of the recovered data was verified.

[0126] If data corruption or recovery failure is found during the exercise, it will be marked as an exercise anomaly. The cause will be traced and the backup strategy will be updated. At the same time, the anomaly record and the handling results will be stored in the backup log.

[0127] Understandably, when conducting regular recovery drills for data backups of the three-level backup priority sets, the drill cycles are first differentiated based on the importance of the data. The drill cycles gradually increase in the order of the first-priority data cluster, the second-priority data cluster, and the third-priority data cluster. First-priority data, directly related to elevator operation safety and core business continuity, has the shortest drill cycle, ensuring its backup reliability through high-frequency drills. Second-priority data, with less importance, has a longer drill cycle than first-priority data. Third-priority data, with a smaller impact or lower access frequency, has the longest drill cycle. This balances the reliability of critical data with the resource consumption of drills and the normal operation of business. During the exercise, separate simulation scenarios were constructed for data clusters of different priorities: For the first-priority data cluster, backup data was extracted from the local backup unit on the edge side to simulate recovery from edge storage failure; for the second-priority data cluster, backup data was retrieved from the private cloud backup cluster to simulate data loss during private cloud storage anomalies; and for the third-priority data cluster, backup data was obtained from the public cloud backup cluster to simulate recovery from public cloud storage failures. After the recovery operation was completed, data integrity was verified through multi-dimensional checks, including comparing the consistency between the recovered data and the original data, checking the integrity and undamagedness of the data structure, and testing whether the data could be normally accessed and analyzed by the business system, ensuring that the recovered data could be directly used in business scenarios. If, during the exercise, the recovered data was found to be corrupted, partially missing, or completely unrecoverable, the system would immediately mark the situation as an exercise anomaly. Subsequently, a tracing mechanism was initiated to investigate the cause from the backup process, storage media, recovery operations, and other aspects. After locating the root cause, the backup strategy was updated accordingly. For example, if data loss was caused by insufficient backup frequency, the backup interval for the corresponding priority data was shortened; if damage was caused by storage media issues, a more reliable storage device was replaced. At the same time, complete information such as the time of the anomaly, its specific manifestations, the tracing process, and the handling measures was recorded in the backup log to provide a basis for subsequent drills, optimizations, and improvements to the backup system.

[0128] In another preferred embodiment based on the above embodiments, see [reference] Figure 2As shown, this embodiment provides a data management and backup system for elevator networks under a hybrid cloud architecture, used to apply the above-described data management and backup method for elevator networks under a hybrid cloud architecture, including:

[0129] Acquisition Unit: A data acquisition node is set up on the edge side to access the raw data stream of the elevator terminal equipment, process the raw data stream, and generate preprocessed data;

[0130] Sensitivity identification and encryption unit: The preprocessed data is identified based on the security rule base to obtain high-sensitivity data, medium-sensitivity data and low-sensitivity data. The high-sensitivity data and medium-sensitivity data are encrypted to generate encrypted data segments, while the low-sensitivity data is retained as plaintext data segments.

[0131] Backup Unit: Encrypted data segments and plaintext data segments are divided into three levels of backup priority sets according to business criticality. The three levels of backup priority sets are the first priority data set, the second priority data set, and the third priority data set. The first priority data set, the second priority data set, and the third priority data set are aggregated using a clustering algorithm based on data access frequency and storage usage to obtain the first priority data cluster set, the second priority data cluster set, and the third priority data cluster set. The first priority data cluster set, the second priority data cluster set, and the third priority data cluster set are then distributed to the edge-side local backup unit, the private cloud backup cluster, and the public cloud backup cluster of the hybrid cloud architecture in sequence.

[0132] Backup Status Unit: Monitors the storage load, transmission link status and data backup progress of the three-level backup priority set. When it detects insufficient storage capacity, link interruption or backup progress delay exceeding the progress threshold, it adjusts the backup task queue or allocates backup channel resources and triggers resource scheduling according to backup priority.

[0133] Exercise Unit: Regularly conduct data recovery exercises on the data backups of the three-level backup priority set.

[0134] Understandably, this invention, through the collaborative operation of its various units, systematically achieves end-to-end management of elevator network data, from acquisition to backup, monitoring, and recovery verification. The acquisition unit, acting as the data entry point, has acquisition nodes deployed at the edge that directly access various raw data streams generated by elevator terminal equipment. Through noise cleaning and filtering, missing information completion, format conversion, and key feature extraction, heterogeneous raw data is transformed into standardized pre-processed data, providing a high-quality data foundation for subsequent management. The sensitivity identification and encryption unit classifies the pre-processed data based on a security rule base. By comparing it with historical security data and judging risk thresholds, it distinguishes between high, medium, and low sensitivity data. High and medium sensitivity data are then encrypted to generate encrypted data segments, while low sensitivity data is retained in plaintext, ensuring the security of core data while reducing unnecessary encryption overhead. The backup unit focuses on a tiered data storage strategy. First, encrypted and plaintext data are divided into three priority levels based on business criticality. Then, clustering is performed by analyzing data access frequency and storage usage characteristics. The first priority data cluster, with frequent access and small capacity, is suitable for local edge backup units to ensure fast access. The second priority data cluster, with moderate access and moderate capacity, is stored in a private cloud backup cluster to balance security and efficiency. The third priority data cluster, with low access frequency or large capacity, is allocated to a public cloud backup cluster to optimize storage costs, while ensuring that each priority cluster is independent and does not overlap. The backup status unit monitors the storage load, transmission link status, and backup progress of each backup unit in real time. When storage is insufficient, high-priority data is retained first, and low-priority data is compressed or migrated. When the link is interrupted, critical data is temporarily stored and reconnection is attempted. When progress is delayed, resources are allocated to accelerate high-priority tasks. Dynamic resource scheduling ensures the stability of the backup process. The training unit regularly conducts recovery drills on the three-level backup data, gradually extending the drill cycle according to priority from high to low. These drills simulate data loss scenarios to verify recovery integrity. If anomalies are found, the cause is traced and the backup strategy is updated. Logs are also recorded to provide a basis for system optimization. The close cooperation among the units ensures data security while balancing access efficiency and storage costs, providing reliable data support for the intelligent management of large-scale elevator clusters.

[0135] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit it. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the specific implementation of the present invention. Any modifications or equivalent substitutions that do not depart from the spirit and scope of the present invention should be covered within the scope of protection of the claims of the present invention.

Claims

1. A method for managing and backing up elevator network data under a hybrid cloud architecture, characterized in that, include: A data acquisition node is set up on the edge side to access the raw data stream of the elevator terminal equipment, and the raw data stream is processed to generate preprocessed data; The preprocessed data is identified for sensitivity based on a security rule base to obtain high-sensitivity data, medium-sensitivity data, and low-sensitivity data. The high-sensitivity data and medium-sensitivity data are encrypted to generate encrypted data segments, while the low-sensitivity data is retained as plaintext data segments. The encrypted data segments and plaintext data segments are divided into three levels of backup priority sets according to business criticality. The three levels of backup priority sets are a first priority data set, a second priority data set, and a third priority data set. The first priority data set, the second priority data set, and the third priority data set are aggregated using a clustering algorithm based on data access frequency and storage usage to obtain a first priority data cluster set, a second priority data cluster set, and a third priority data cluster set. The first priority data cluster set, the second priority data cluster set, and the third priority data cluster set are then allocated sequentially to the edge-side local backup unit, the private cloud backup cluster, and the public cloud backup cluster of the hybrid cloud architecture. Monitor the storage load, transmission link status and data backup progress of the three-level backup priority set. When insufficient storage capacity, link interruption or backup progress delay exceeds the progress threshold is detected, adjust the backup task queue or allocate backup channel resources, and trigger resource scheduling according to backup priority. Data recovery drills are performed periodically on the data backups of the three-level backup priority set.

2. The method for elevator network data management and backup under a hybrid cloud architecture according to claim 1, characterized in that, When performing sensitivity identification on the preprocessed data according to the security rule base, the following steps are included: The security rule base includes historical security data and sensitivity classification rules. The historical security data is obtained by analyzing the historical operation data of the elevator network. The sensitivity classification rules are divided into high-sensitivity data, medium-sensitivity data and low-sensitivity data according to the data leakage risk threshold. When identifying preprocessed data, the preprocessed data is compared with historical security data to obtain data to be divided that matches the historical security data; according to the sensitivity division rules, the data to be divided is divided into high-sensitivity data, medium-sensitivity data and low-sensitivity data.

3. The method for elevator network data management and backup under a hybrid cloud architecture according to claim 2, characterized in that, When dividing the data to be divided into high-sensitivity data, medium-sensitivity data, and low-sensitivity data, the following steps are included: The data leakage risk threshold is divided into a high-risk threshold and a low-risk threshold, wherein the low-risk threshold is smaller than the high-risk threshold. When the data to be classified is greater than or equal to the high-risk threshold, it is classified as high-sensitivity data; When the data to be classified is greater than the low-risk threshold and less than the high-risk threshold, it is classified as medium-sensitivity data. When the data to be classified is less than or equal to the low-risk threshold, it is classified as low-sensitivity data.

4. The method for elevator network data management and backup under a hybrid cloud architecture according to claim 3, characterized in that, When dividing the encrypted data segments and plaintext data segments into a three-level backup priority set based on business criticality, the following is included: The criticality of the business is determined quantitatively through a weighted scoring model, which includes a data failure impact factor, a real-time requirement factor, and a related equipment range factor. Data failure impact factor: calculated based on the risk of elevator downtime, maintenance delay costs, and safety compliance penalties caused by missing data; Real-time requirement factor: determined based on the urgency of the data; Related equipment scope factor: set according to the number of elevators or the size of the group affected by the data; The encrypted data segment and the plaintext data segment are input into the weighted scoring model, and the business criticality score value is output. The score is divided according to the scoring threshold, which is divided into a high-risk scoring threshold and a low-risk scoring threshold. The low-risk scoring threshold is less than the high-risk scoring threshold. When the business criticality score is greater than or equal to the high-risk score threshold, it is determined to be the first priority data set; When the business criticality score is greater than or equal to the low-risk score threshold but less than the high-risk score threshold, it is determined to be a second priority data set; When the business criticality score is less than the low-risk score threshold, it is determined to be a third-priority data set.

5. The method for elevator network data management and backup under a hybrid cloud architecture according to claim 4, characterized in that, When aggregating the first priority data set, the second priority data set, and the third priority data set using a clustering algorithm based on data access frequency and storage usage, the following steps are included: For each data item in the priority data set, the access frequency and data storage usage per unit time are statistically analyzed to form the access and storage characteristic value of the data item. The similarity between data items is calculated based on the access storage feature values, and the data items are aggregated into the same data cluster set according to the access frequency and storage usage. For the first priority data set, aggregate data items with high access frequency and low storage consumption to obtain the first priority data cluster set; For the second priority data set, aggregate data items with moderate access frequency and moderate storage consumption to obtain the second priority data cluster set; For the third priority data set, aggregate data items with low access frequency or high storage consumption to obtain the third priority data cluster set; During the aggregation process, clustered subsets within the same priority data set remain independent and do not cross-aggregate with clustered subsets of other priority data sets.

6. The method for elevator network data management and backup under a hybrid cloud architecture according to claim 5, characterized in that, When insufficient storage capacity is detected, including: The backup units that are insufficient in storage capacity are located, and these backup units include edge-side local backup units, private cloud backup clusters, and public cloud backup clusters. For backup units with insufficient storage capacity, retain the complete storage of the high-priority data cluster set corresponding to the backup unit, and compress or migrate the low-priority data cluster set within the backup unit with insufficient storage capacity. If the capacity of the local backup unit on the edge side is insufficient, the data with low access frequency in the third priority data cluster set stored therein will be migrated to the reserved space of the private cloud backup cluster. If the private cloud backup cluster has insufficient capacity, migrate the third priority data cluster set stored therein to the public cloud backup cluster and encrypt and mark it as migration data; If the public cloud backup cluster has insufficient capacity, the third priority data cluster set stored therein will be compressed and stored to retain critical information.

7. The method for elevator network data management and backup under a hybrid cloud architecture according to claim 6, characterized in that, When the link is interrupted, including: Locate the specific location of the link interruption. The link includes the first transmission link between the edge-side local backup unit and the private cloud backup cluster, and the second transmission link between the private cloud backup cluster and the public cloud backup cluster. If the first transmission link is interrupted, the second priority data cluster set to be transmitted from the edge side to the private cloud will be temporarily stored in the temporary buffer of the local backup unit on the edge side, and the transmission of the third priority data will be suspended at the same time. If the second transmission link is interrupted, the third priority data cluster set to be transmitted from the private cloud to the public cloud will be marked as pending transmission and stored in the temporary extended partition of the private cloud. Incremental logging will be started for the second priority data cluster set, and only the data update part will be cached. During the link interruption, the recovery status of the interrupted link is monitored in real time, and a link reconnection attempt is triggered every preset time interval; Once the link is restored, transmission is resumed sequentially in the order of updated data associated with the first priority data cluster set, cached data of the second priority data cluster set, and data to be transmitted of the third priority data cluster set, while also retransmitting incremental data generated during the interruption.

8. The method for elevator network data management and backup under a hybrid cloud architecture according to claim 7, characterized in that, When the backup progress delay exceeds the progress threshold, including: The actual backup progress of each priority data cluster is compared with the progress threshold to determine the priority data clusters whose delay exceeds the progress threshold; When the delay of the first priority data cluster set exceeds the progress threshold, the reserved high-speed transmission channel is activated for the first priority data cluster set, the backup task of the third priority data cluster set is suspended, and the high-speed transmission channel resources are temporarily allocated to the first priority. For the second priority data cluster set, incremental backup is used instead of full backup, and only the data that differs from the previous backup is transmitted. When the backup progress of the first priority data cluster catches up with the planned progress, the temporarily occupied channel resources are released, and the backup tasks of the second and third priorities are resumed.

9. The method for elevator network data management and backup under a hybrid cloud architecture according to claim 8, characterized in that, When periodically performing data recovery drills on the data backups of the aforementioned three-level backup priority set, the following are included: The exercise cycle is set in the order of the first priority data cluster set, the second priority data cluster set, and the third priority data cluster set, with the exercise cycle of the first priority data cluster set, the second priority data cluster set, and the third priority data cluster set gradually increasing; During the exercise, data loss scenarios were simulated for each priority data cluster set. Backup data was extracted from the corresponding backup unit for recovery, and the integrity of the recovered data was verified. If data corruption or recovery failure is found during the exercise, it will be marked as an exercise anomaly. The cause will be traced and the backup strategy will be updated. At the same time, the anomaly record and the handling results will be stored in the backup log.

10. A data management and backup system for elevator networks under a hybrid cloud architecture, used to implement the data management and backup method for elevator networks under a hybrid cloud architecture as described in any one of claims 1-9, characterized in that, include: Acquisition Unit: A data acquisition node is set up on the edge side to access the raw data stream of the elevator terminal equipment, and the raw data stream is processed to generate preprocessed data; Sensitivity identification and encryption unit: The preprocessed data is identified for sensitivity according to the security rule base to obtain high-sensitivity data, medium-sensitivity data and low-sensitivity data. The high-sensitivity data and medium-sensitivity data are encrypted to generate encrypted data segments, and the low-sensitivity data is retained as plaintext data segments. Backup Unit: The encrypted data segments and plaintext data segments are divided into three-level backup priority sets according to business criticality. The three-level backup priority sets are a first priority data set, a second priority data set, and a third priority data set. The first priority data set, the second priority data set, and the third priority data set are aggregated using a clustering algorithm based on data access frequency and storage usage to obtain a first priority data cluster set, a second priority data cluster set, and a third priority data cluster set. The first priority data cluster set, the second priority data cluster set, and the third priority data cluster set are then sequentially allocated to the edge-side local backup unit, the private cloud backup cluster, and the public cloud backup cluster of the hybrid cloud architecture. Backup Status Unit: Monitors the storage load, transmission link status and data backup progress of the three-level backup priority set. When it detects insufficient storage capacity, link interruption or backup progress delay exceeding the progress threshold, it adjusts the backup task queue or allocates backup channel resources and triggers resource scheduling according to backup priority. Exercise Unit: Regularly conduct data recovery exercises on the data backups of the three-level backup priority set.

Images