Data service continuity guarantee method based on multi-level disaster recovery strategy

Abstract

The invention relates to a data service continuity guarantee method based on a multi-level disaster recovery strategy, and the method comprises the steps: distributing a service level according to a key index of a service system, and generating a differential disaster recovery strategy template; according to the disaster recovery strategy template, deploying an intra-city active-active cluster for high-priority services, deploying main and standby asynchronous replication for medium-priority services, and deploying timing snapshot backup for low-priority services; and according to the disaster recovery strategy template, constructing a remote disaster recovery center through asynchronous log copying and incremental snapshots, and supporting hybrid recovery of snapshots and logs to guarantee cross-regional service continuity. According to the invention, resource and demand matching is realized through service grading planning, and cost and efficiency are optimized; a city-wide active-active mechanism is combined with a distributed consistency protocol to ensure second-level switching and zero data loss; different-place disaster recovery adopts snapshot and log mixed recovery, so that the cross-regional recovery efficiency is improved; automatic fault sensing and closed-loop response are achieved, manual intervention is remarkably reduced, and the reliability and usability of the system are improved.

Description

Technical Field

[0001] This invention belongs to the field of cloud computing and distributed system technology, and in particular relates to a data service continuity assurance method based on a multi-level disaster recovery strategy. Background Technology

[0002] With the rapid development of the digital economy, critical business systems in finance, telecommunications, energy, government affairs, e-commerce, and other fields are becoming increasingly important, making high availability and data continuity core requirements. The widespread application of cloud computing, edge computing, and distributed systems has led to increasingly complex, distributed, and cross-domain system architectures, posing greater challenges to disaster recovery capabilities. Traditional disaster recovery solutions mainly employ primary / standby deployment, asynchronous backup, or scheduled snapshots to address scenarios such as equipment failures, network outages, and natural disasters. However, these solutions have significant drawbacks: slow response times, with switchover processes typically taking several minutes or even longer, making it difficult to meet the "zero loss, second-level recovery" requirements of core businesses; excessive manual intervention, relying on static scripts or manual operations, resulting in low efficiency; weak data consistency, with asynchronous replication between primary and standby systems often leading to data delays or loss; furthermore, disaster recovery strategies lack fine-grained classification, making it difficult to allocate resources differently based on business importance, resulting in a trade-off between cost and efficiency. Under the trend of distributed multi-site deployment, existing solutions are insufficient in terms of intra-city active-active data consistency, cross-site disaster recovery switchover efficiency, and automated scheduling capabilities, making it difficult to meet the seamless switchover and cross-regional recovery needs of high-priority businesses.

[0003] Therefore, there is an urgent need for a multi-level, automated, and intelligent disaster recovery system to solve the problems of slow response, complex switching, and poor reliability, and to achieve efficient business continuity assurance. Summary of the Invention

[0004] The purpose of this invention is to provide a data service continuity assurance method based on a multi-level disaster recovery strategy, so as to solve the problems of coarse-grained strategy, high difficulty of intra-city dual-active deployment, delayed disaster recovery switching in different locations, and weak scheduling automation capability in existing disaster recovery solutions.

[0005] To achieve one of the above-mentioned objectives, one embodiment of the present invention provides a data service continuity assurance method based on a multi-level disaster recovery strategy, the method comprising:

[0006] Based on the key indicators of the business system, assign business levels and generate differentiated disaster recovery strategy templates;

[0007] According to the disaster recovery strategy template, deploy an active-active cluster in the same city for high-priority services, deploy asynchronous replication between primary and backup for medium-priority services, and deploy scheduled snapshot backups for low-priority services.

[0008] Based on the disaster recovery strategy template, an off-site disaster recovery center is built through asynchronous log replication and incremental snapshots, supporting hybrid recovery of snapshots and logs to ensure cross-regional business continuity.

[0009] As a further improvement to one embodiment of the present invention, the method further includes, in which the allocation of service levels and generation of differentiated disaster recovery strategy templates include,

[0010] Obtain key metrics for the business system, including business importance, recovery time target, recovery point target, concurrent access volume, and data throughput;

[0011] Based on the analytic hierarchy process, fuzzy comprehensive evaluation, or machine learning model, the key indicators are weighted and calculated to generate a comprehensive score and assign corresponding high, medium, and low business levels.

[0012] Based on the business level, the disaster recovery template library is invoked to generate corresponding disaster recovery strategy templates with network topology, database architecture, and data synchronization mechanisms.

[0013] As a further improvement to one embodiment of the present invention, the method further includes, in which the deployment of a local active-active cluster for high-priority services includes,

[0014] Deploy business nodes in two geographically adjacent, physically isolated data centers and configure a distributed database to support real-time business synchronization;

[0015] User requests are distributed by calculating weights based on network latency or node health status through a load balancer, and data consistency between nodes is ensured by using an optimized two-phase commit protocol.

[0016] Configure heartbeat detection and virtual IP migration mechanisms to automatically switch traffic to healthy business nodes when a fault is detected, achieving a second-level switching.

[0017] As a further improvement to one embodiment of the present invention, the method further includes, in which the deployment of asynchronous replication for medium-priority services includes,

[0018] Deploy the master node in the primary data center and the backup node in a geographically adjacent backup data center, and configure an asynchronous replication channel based on the database business logs;

[0019] The health monitoring mechanism monitors the status of the master node and supports automatic or manual confirmation of switching to the backup node.

[0020] During the switchover process, update routing rules to ensure that service recovery time is controlled within minutes.

[0021] As a further improvement to one embodiment of the present invention, the method further includes, in which the deployment of scheduled snapshot backups for low-priority services includes,

[0022] Configure a scheduled snapshot generation mechanism in the production environment to back up data mirrors via object storage or off-site data centers;

[0023] In the event of a disaster, manually or semi-automatically load snapshot images to restore the business system state;

[0024] Update backup metadata and recovery logs to ensure that data recovery points are controlled within hours.

[0025] As a further improvement to one embodiment of the present invention, the method further includes, in which the construction of the off-site disaster recovery center through asynchronous log replication and incremental snapshots includes,

[0026] Configure read-only replica databases and snapshot repositories in cross-regional disaster recovery centers, and transmit business logs through asynchronous log replication and high-priority channels;

[0027] Periodically generate incremental snapshots and combine them with log compensation to achieve hybrid recovery of snapshots and logs;

[0028] When the local node is unavailable, load the latest snapshot and replay the logs, switch the disaster recovery center to writable mode and update the access path;

[0029] The generation of incremental snapshots includes,

[0030] The business operations of the main data center are transformed into database business logs, and cross-regional transmission is optimized through compression and priority queuing.

[0031] Incremental snapshots are generated based on differential analysis algorithms, reducing data transmission volume and storing them in the snapshot repository of the disaster recovery center;

[0032] During the recovery process, the snapshot is loaded after verifying its integrity, and the latest data changes are compensated for by replaying the logs.

[0033] As a further improvement to one embodiment of the present invention, the method further includes performing multi-dimensional monitoring, fault detection, policy matching, and automated switching through an intelligent scheduling platform, and dynamically optimizing disaster recovery strategies and resource allocation based on real-time and historical data, specifically including:

[0034] By monitoring and collecting indicators such as heartbeat signals, database latency, and business error rate from multiple dimensions, a multi-factor weighted model is used to determine the fault status.

[0035] Based on the business level and fault scope, the strategy engine is invoked to match the switching strategy and generate an executable task sequence.

[0036] The scheduling and execution module issues switching, rebuilding, or rollback commands and connects to the cloud computing platform to achieve automated execution.

[0037] By using machine learning models to analyze historical fault data, we can dynamically optimize strategy parameters and scheduling efficiency.

[0038] To achieve one of the above-mentioned objectives, an embodiment of the present invention also provides a data service continuity assurance system based on a multi-level disaster recovery strategy, the system including a disaster recovery level planning module, a local disaster recovery deployment module, and a remote disaster recovery construction module;

[0039] The disaster recovery level planning module is used to allocate business levels and generate differentiated disaster recovery strategy templates based on the key indicators of the business system.

[0040] The same-city disaster recovery deployment module is used to deploy same-city active-active clusters for high-priority services, deploy primary-standby asynchronous replication for medium-priority services, and deploy scheduled snapshot backups for low-priority services, according to the disaster recovery strategy template.

[0041] The off-site disaster recovery construction module is used to build an off-site disaster recovery center based on the disaster recovery strategy template through asynchronous log replication and incremental snapshots, and supports mixed recovery of snapshots and logs to ensure cross-regional business continuity.

[0042] To achieve one of the above-mentioned objectives, an embodiment of the present invention also provides an electronic device, including a memory and a processor, characterized in that the memory stores a computer program that can run on the processor, and when the program is executed on the processor, it implements the steps in the data service continuity assurance method based on the multi-level disaster recovery strategy described above.

[0043] To achieve one of the above-mentioned objectives, an embodiment of the present invention also provides a storage medium storing a computer program, characterized in that, when the computer program is executed by a processor, it implements the steps in the data service continuity assurance method based on a multi-level disaster recovery strategy as described above.

[0044] Compared with existing technologies, this invention provides a data service continuity assurance method based on a multi-level disaster recovery strategy. It achieves precise matching of resources and needs through hierarchical business planning, optimizing costs and efficiency; the intra-city active-active mechanism combined with a distributed consistency protocol ensures second-level switching and zero data loss; the off-site disaster recovery adopts a hybrid recovery of snapshots and logs to improve cross-regional recovery efficiency; and the intelligent scheduling platform realizes automatic fault detection and closed-loop response, significantly reducing manual intervention and improving system reliability and availability, making it suitable for various scenarios such as finance and e-commerce. Attached Figure Description

[0045] Figure 1 This is an overall flowchart of the data service continuity assurance method based on a multi-level disaster recovery strategy described in this invention.

[0046] Figure 2This is a schematic diagram of the architecture of the data service continuity assurance system based on a multi-level disaster recovery strategy as described in this invention. Detailed Implementation

[0047] The present invention will now be described in detail with reference to the specific embodiments shown in the accompanying drawings. However, these embodiments do not limit the present invention, and any structural, methodological, or functional modifications made by those skilled in the art based on these embodiments are included within the scope of protection of the present invention.

[0048] Embodiments of the present invention are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and should not be construed as limiting the present invention.

[0049] In Embodiment 1 of the present invention, the present invention provides a data service continuity assurance method based on a multi-level disaster recovery strategy, such as... Figure 1 As shown, the method includes,

[0050] S1: Based on the key indicators of the business system, assign business levels and generate differentiated disaster recovery strategy templates;

[0051] S2: According to the disaster recovery strategy template, deploy a local active-active cluster for high-priority services, deploy asynchronous replication for primary and backup for medium-priority services, and deploy scheduled snapshot backups for low-priority services.

[0052] S3: Based on the disaster recovery strategy template, an off-site disaster recovery center is built through asynchronous log replication and incremental snapshots, supporting hybrid recovery of snapshots and logs to ensure cross-regional business continuity.

[0053] In one specific embodiment of the present invention, service levels are assigned and differentiated disaster recovery strategy templates are generated, specifically as follows:

[0054] Obtain key metrics for the business system, including business importance, recovery time target, recovery point target, concurrent access volume, and data throughput;

[0055] Based on the analytic hierarchy process, fuzzy comprehensive evaluation, or machine learning model, the key indicators are weighted and calculated to generate a comprehensive score and assign corresponding high, medium, and low business levels.

[0056] Based on the business level, the disaster recovery template library is invoked to generate corresponding disaster recovery strategy templates with network topology, database architecture, and data synchronization mechanisms.

[0057] It should be noted that the process of automatically assigning business levels and generating differentiated disaster recovery strategy templates aims to configure suitable disaster recovery strategies for different business systems through quantitative assessment and intelligent matching, so as to achieve resource optimization and business continuity assurance.

[0058] Furthermore, firstly, the system obtains key metrics of the business system through the disaster recovery management platform, including but not limited to business importance, Recovery Time Objective (RTO), Recovery Point Objective (RPO), concurrent access volume, and data throughput. Business importance is assessed based on the importance of business functions (such as core transactions, financial settlement, user authentication, etc.), typically quantified using a predefined priority scoring table; RTO represents the longest allowable recovery time after a business interruption; RPO represents the allowable data loss time window; concurrent access volume and data throughput are obtained through real-time monitoring or historical data collection, reflecting the business's load characteristics. These metrics can be manually entered by operations personnel or automatically collected from the business operating environment through system integration interfaces, such as extracted from application logs, database performance monitoring, or network traffic analysis.

[0059] Furthermore, based on the acquired key indicators, the system employs the Analytic Hierarchy Process (AHP), fuzzy comprehensive evaluation, or machine learning models for weighted calculations to generate a comprehensive score to assign high (L1), medium (L2), or low (L3) business levels. Specifically, the AHP constructs a comparison matrix between indicators, calculates the weight of each indicator, and generates a comprehensive score; the fuzzy comprehensive evaluation uses fuzzy mathematics to handle the uncertainty of indicators and generates a level assignment degree; and the machine learning model uses historical operating data to train a classification model and predict the optimal level.

[0060] Furthermore, after assigning business levels, the system calls the built-in disaster recovery template library to generate corresponding disaster recovery policy templates. The template library contains predefined network topologies, database architectures, and data synchronization mechanism configurations. For example, L1 level matches local active-active clusters, real-time strong synchronization, and second-level failover strategies; L2 level matches asynchronous master-slave replication and minute-level failover strategies; and L3 level matches scheduled snapshot backups and hourly recovery strategies. The generation process includes the following steps: First, select a matching template based on the business level; then, adjust the template parameters based on specific business metrics (such as concurrency and data volume), such as setting the synchronization frequency or snapshot period; finally, generate a policy template containing network topology (such as load balancer configuration), database architecture (such as distributed database type), and data synchronization mechanism (such as log replication method). The generated templates are distributed to the cloud computing management system, network module, and database platform via the scheduling engine for subsequent disaster recovery deployment.

[0061] Preferably, to ensure the adaptability of the strategy, the system supports a dynamic adjustment mechanism. When real-time operational metrics (such as load fluctuations and network latency) or business requirements change, the system reassesses the scoring weights or triggers a level adjustment, and updates the strategy template. For example, if the concurrency of L2 services increases significantly, the system can temporarily upgrade it to a protection level close to L1 and adjust it to a real-time synchronization mechanism. In addition, operations and maintenance personnel can manually correct the automatically assigned level or template parameters through the disaster recovery management platform, forming a dual protection mechanism of "automatic recommendation + manual correction" to ensure the accuracy and flexibility of the strategy.

[0062] In one specific embodiment of the present invention, a local active-active cluster is deployed for high-priority services, specifically as follows:

[0063] Deploy business nodes in two geographically adjacent, physically isolated data centers and configure a distributed database to support real-time business synchronization;

[0064] User requests are distributed by calculating weights based on network latency or node health status through a load balancer, and data consistency between nodes is ensured by using an optimized two-phase commit protocol.

[0065] Configure heartbeat detection and virtual IP migration mechanisms to automatically switch traffic to healthy business nodes when a fault is detected, achieving a second-level switching.

[0066] It should be noted that the process of deploying a local active-active cluster for high-priority businesses aims to achieve strong data consistency and second-level failover for critical business systems by building an active-active architecture in two geographically adjacent, physically isolated data centers, thereby ensuring the continuous availability of high-priority businesses (such as core payment systems, financial transaction engines, and user authentication centers).

[0067] Furthermore, the system first deploys business nodes in two geographically adjacent, physically isolated data centers. Each node is configured with complete application services, a distributed database, and storage resources to support parallel processing of user requests. The distributed database employs a technology supporting strong consistency, achieving real-time business synchronization between nodes through an optimized distributed business protocol. Specifically, each business node generates a business log entry upon receiving a user request and transmits the log to the peer node in real time via a synchronous broadcast mechanism, ensuring consistency between the database states of the two nodes. During database configuration, the system adjusts the log synchronization frequency and business commit strategy based on business load and consistency requirements to reduce network overhead and guarantee business consistency.

[0068] Furthermore, regarding request distribution, the system distributes user requests based on dynamic weights through a load balancer. These dynamic weights are calculated based on real-time network latency, node health status (such as CPU utilization and memory usage), or business response time to ensure requests are allocated to the node with the best performance. The load balancer works in conjunction with a distributed database, combining an optimized two-phase commit (2PC) protocol to optimize data consistency performance by reducing network round trips for log commits or batch processing business logs. During business execution, after the master node generates business logs, it initiates a consensus vote. Once the peer node confirms log synchronization, the business commit is completed, and a response is returned to the user. The entire process ensures strong data consistency.

[0069] Furthermore, to achieve second-level failover, the system is configured with heartbeat detection and virtual IP migration mechanisms. Heartbeat detection uses distributed coordination tools to monitor the operational status of business nodes and the database in real time, including metrics such as network connectivity, process liveness, and database service latency. When any node failure is detected (e.g., lost heartbeat signal, service response timeout), the system immediately triggers the failover process, redirecting user requests to healthy nodes via virtual IP migration or dynamic DNS updates. During the failover process, the healthy node takes over service processing using synchronized service logs, ensuring a seamless switchover. After the failed node recovers, the system verifies its state consistency through a preheating mechanism before rejoining it into the cluster, avoiding data conflicts. The entire failover process is automatically executed by the intelligent scheduling platform without manual intervention, ensuring the continuity of high-priority services.

[0070] In one specific embodiment of the present invention, asynchronous replication between primary and backup systems is deployed for medium-priority services, specifically as follows:

[0071] Deploy the master node in the primary data center and the backup node in a geographically adjacent backup data center, and configure an asynchronous replication channel based on the database business logs;

[0072] The health monitoring mechanism monitors the status of the master node and supports automatic or manual confirmation of switching to the backup node.

[0073] During the switchover process, update routing rules to ensure that service recovery time is controlled within minutes.

[0074] It should be noted that the process of deploying asynchronous replication for medium-priority services aims to provide minute-level recovery capabilities for medium-priority services (such as reporting systems, internal office systems, and workflow approval systems) by building a primary and standby architecture in the primary data center and a geographically adjacent standby data center, in order to balance data consistency and resource costs.

[0075] Furthermore, firstly, the system deploys a master node in the primary data center, responsible for handling all user requests and business operations; and deploys a backup node in a geographically adjacent standby data center as a hot backup of the master node, possessing the same application services and database configuration, but remaining in standby mode. An asynchronous replication channel based on database business logs is configured between the master and backup nodes. Specifically, the master node generates business log entries when executing business operations, recording information such as operation type, data object, and timestamp; through the asynchronous replication channel, these log entries are transmitted to the backup node in a highly efficient manner. The backup node then applies the logs to update its local database copy, maintaining data consistency with the master node, but allowing for brief delays. To optimize transmission efficiency, the system can compress or prioritize log entries, ensuring that critical business operations are synchronized first.

[0076] Furthermore, to achieve reliable failover, the system continuously monitors the master node's status through a health check mechanism, including network connectivity, database response time, service error rate, and hardware resource utilization. The health check mechanism uses distributed coordination tools to periodically send heartbeat signals and combines this with log analysis to determine if the master node is operating normally. If a master node failure is detected (such as lost heartbeat signals or service response timeouts), the system supports automatic or manual failover. Automatic failover is triggered by a preset threshold, immediately activating the backup node; manual failover involves sending an alarm to operations personnel through the disaster recovery management platform, awaiting confirmation before execution. During failover, the system updates routing rules, adjusting user requests to the backup node via load balancer or dynamic DNS, and the backup node's database switches to writable mode to continue processing service requests. The entire failover process is controlled within minutes, ensuring rapid service recovery.

[0077] Furthermore, after the switchover is complete, the system records the switchover timeline and operation logs, which are then pushed to the audit system for archiving. Once the faulty primary node recovers, the system reconfigures it as a backup node through status verification and log synchronization mechanisms, restoring the primary-backup architecture to normal operation. The switchover and recovery process can be automatically coordinated by an intelligent scheduling platform, reducing manual intervention and improving operational efficiency. This asynchronous primary-backup replication mechanism, through asynchronous replication and health checks, ensures the continuity of medium-priority services while optimizing resource utilization, making it suitable for scenarios with moderate recovery time requirements.

[0078] In one specific embodiment of the present invention, scheduled snapshot backups are deployed for low-priority services, specifically as follows:

[0079] Configure a scheduled snapshot generation mechanism in the production environment to back up data mirrors via object storage or off-site data centers;

[0080] In the event of a disaster, manually or semi-automatically load snapshot images to restore the business system state;

[0081] Update backup metadata and recovery logs to ensure that data recovery points are controlled within hours.

[0082] It should be noted that the process of deploying scheduled snapshot backups for low-priority services aims to provide cost-optimized disaster recovery protection for low-priority services (such as historical data query, archive management, and development testing platforms). Through scheduled snapshot generation and backup mechanisms, business recovery can be achieved within hours in the event of a disaster, meeting the data recovery point objective (RPO) requirements.

[0083] Furthermore, firstly, the system is configured with a scheduled snapshot generation mechanism in the production environment to periodically generate full or incremental snapshot images for low-priority business data storage (such as databases or file systems). The snapshot generation cycle is set according to business needs, typically once daily or every few hours, to balance storage costs and data protection requirements. The snapshot generation process is controlled by the backup scheduling engine, using snapshot technology (such as LVM snapshots or database native snapshot tools) to capture the complete data state of the business system at a specified point in time, including database tables, file directories, and application configurations. When generating a snapshot, the system records metadata information (such as snapshot timestamp, version number, and checksum) for subsequent verification and recovery. The snapshot images are backed up to object storage or off-site data center backup storage systems via secure transmission channels (such as encrypted VPNs or dedicated networks) to ensure data is securely stored in a physically isolated environment.

[0084] Furthermore, in disaster scenarios (such as production environment unavailability due to fire, power outage, or hardware failure), the system supports manual or semi-automatic loading of snapshot images to restore the business system state. Manual recovery is triggered by operations personnel through the disaster recovery management platform, which selects the latest valid snapshot version based on metadata. Semi-automatic recovery automatically initiates the snapshot loading process based on preset rules (such as detecting prolonged production environment unavailability). The recovery process includes the following steps: First, the target snapshot image is retrieved from object storage or off-site data center, and its integrity is verified; then, the snapshot image is loaded into the database or file system of the disaster recovery center, restoring the business system to the state at the time the snapshot was generated. Due to the long snapshot cycle, some data loss may occur after recovery, making it suitable for low-priority businesses with lower real-time requirements.

[0085] Furthermore, to ensure data recovery targets are controlled within hours, the system updates backup metadata and recovery logs to track snapshot versions and recovery operations. The metadata management system records the version information, storage path, and checksum of each snapshot to ensure quick location of the latest snapshot during recovery. Recovery logs record the snapshot loading time, operation results, and data compensation status (such as whether there is subsequent log replay), and are pushed to the audit system for archiving to support compliance checks. If the production environment is restored, the system reconfigures the data synchronization relationship between the production environment and the disaster recovery center through metadata comparison and log synchronization to complete the rollback operation. This scheduled snapshot backup mechanism provides reliable disaster recovery assurance for low-priority businesses through a low-cost backup and recovery strategy, and is suitable for archiving, testing, and other scenarios.

[0086] In one specific embodiment of the present invention, an off-site disaster recovery center is constructed through asynchronous log replication and incremental snapshots, specifically as follows:

[0087] Configure read-only replica databases and snapshot repositories in cross-regional disaster recovery centers, and transmit business logs through asynchronous log replication and high-priority channels;

[0088] Periodically generate incremental snapshots and combine them with log compensation to achieve hybrid recovery of snapshots and logs;

[0089] When the local node is unavailable, load the latest snapshot and replay the logs, switch the disaster recovery center to writable mode and update the access path.

[0090] It should be noted that the process of building an off-site disaster recovery center through asynchronous log replication and incremental snapshots aims to provide off-site disaster recovery capabilities for high, medium, and low priority services (L1, L2, L3) through cross-regional deployment and data synchronization mechanisms, ensuring rapid service recovery when the local data center is completely unavailable (such as natural disasters or regional power outages).

[0091] Furthermore, firstly, the system configures read-only replica libraries and snapshot repositories in cross-regional disaster recovery centers (such as data centers across cities or provinces). The read-only replica library stores business logs asynchronously replicated from the primary data center, while the snapshot repository stores periodically generated incremental snapshot files. Asynchronous log replication transmits business logs via high-priority channels (such as dedicated fiber optic cables or encrypted VPNs). Business operations in the primary data center generate log entries, recording information such as operation type, data object, and timestamp. These entries are then compressed and optimized using priority queuing before being transmitted to the disaster recovery center. Upon receiving the logs, the read-only replica library in the disaster recovery center verifies their integrity and applies them to its local database, maintaining data consistency with the primary data center while allowing for controllable latency.

[0092] Furthermore, the system periodically generates incremental snapshots to further ensure data reliability. Incremental snapshots, based on differential analysis algorithms, only record changes to the primary data center database or file system, significantly reducing data transfer volume and storage overhead compared to full snapshots. The snapshot generation cycle is adjusted according to business level; for example, L1 services use a short cycle (e.g., every minute), L2 services use a medium cycle (e.g., every hour), and L3 services use a long cycle (e.g., daily). Snapshots are replicated to the snapshot repository in the disaster recovery center via a secure transmission channel, storing metadata to record version information and checksums to ensure data integrity. Snapshot generation works in conjunction with log replication; logs provide real-time data changes, while snapshots provide periodic data snapshots, forming a hybrid recovery mechanism.

[0093] Furthermore, when the local node becomes unavailable, the system triggers an off-site disaster recovery process. First, the disaster recovery center loads the latest snapshot, selects the most recent full snapshot version from the snapshot repository, decompresses it, and restores it to the database or file system. Then, the system replays the latest business logs in the read-only replica database to compensate for data changes after the snapshot was generated, ensuring the data state is close to its pre-failure state. After recovery, the disaster recovery center's database switches to writable mode, and user requests are redirected to the disaster recovery center via a load balancer or dynamic DNS update (such as virtual IP migration) to continue processing business. The entire recovery process achieves differentiated goals based on business level: L1 services achieve second-level switching, L2 services achieve minute-level switching, and L3 services achieve hour-level recovery. After recovery, the system records operation logs and pushes them to the auditing system. If the primary data center recovers, the system reconfigures the primary / standby relationship through status verification and log synchronization, completing the failback operation.

[0094] In one specific embodiment of the present invention, an incremental snapshot is generated, specifically as follows:

[0095] The business operations of the main data center are transformed into database business logs, and cross-regional transmission is optimized through compression and priority queuing.

[0096] Incremental snapshots are generated based on differential analysis algorithms, reducing data transmission volume and storing them in the snapshot repository of the disaster recovery center;

[0097] During the recovery process, the snapshot is loaded after verifying its integrity, and the latest data changes are compensated for by replaying the logs.

[0098] It should be noted that the process of generating incremental snapshots aims to provide reliable data backup and recovery capabilities for off-site disaster recovery through efficient data differential processing and log synchronization mechanisms, and is suitable for cross-regional disaster recovery needs of high, medium and low priority businesses.

[0099] Furthermore, firstly, the business operations of the primary data center are transformed into database business logs, recording information such as operation type (e.g., insert, update, delete), data object, timestamp, and business number. To optimize cross-regional transmission efficiency, the system compresses the business logs using a lossless compression algorithm to reduce log data volume. Simultaneously, a priority queue mechanism sorts log entries, prioritizing the transmission of critical business data to ensure efficient transmission in bandwidth-constrained cross-regional networks. The logs are then transmitted to the read-only replica database in the disaster recovery center via a high-priority channel. Upon receipt, integrity verification is performed, and the data is applied to the local database, maintaining consistency between the data replica and the primary data center.

[0100] Furthermore, during the incremental snapshot generation phase, the system periodically generates snapshots based on a differential analysis algorithm, recording only the changes to the primary data center database or file system since the last snapshot. This significantly reduces data volume and storage requirements compared to a full snapshot. The generation process includes the following steps: First, the system compares the current database state with the metadata of the last snapshot to identify the changed database blocks or files; then, it generates incremental snapshot files using a differential algorithm, recording the changed data and its metadata (such as checksums and version numbers); finally, the snapshot files are copied to the snapshot repository in the disaster recovery center via a secure transmission channel, updating metadata during storage for later recovery. The snapshot generation cycle is adjusted according to the business level; for example, L1 services are generated every minute, L2 services every hour, and L3 services daily, to balance consistency and resource overhead.

[0101] Furthermore, during the recovery process, when local nodes are unavailable, the disaster recovery center first selects the latest snapshot version from the snapshot repository, verifies its integrity, and loads it into the database or file system. Subsequently, the system extracts the latest business logs from the read-only replica database, replays log entries to compensate for business changes after the snapshot was generated, and restores the data to its latest state before the failure. The log replay process ensures that business operations are applied in timestamp order to avoid data conflicts. For L1 services, recovery achieves near-zero data loss; for L2 services, recovery is controlled within 1 minute; and for L3 services, recovery follows the snapshot cycle. After recovery is complete, the disaster recovery center database switches to writable mode to continue processing user requests. The entire process is coordinated and executed by an intelligent scheduling platform, recording operation logs to support auditing.

[0102] In one specific embodiment of the present invention, an intelligent scheduling platform performs multi-dimensional monitoring, fault detection, policy matching, and automated switching, and dynamically optimizes disaster recovery strategies and resource allocation based on real-time and historical data. Specifically,

[0103] By monitoring and collecting indicators such as heartbeat signals, database latency, and business error rate from multiple dimensions, a multi-factor weighted model is used to determine the fault status.

[0104] Based on the business level and fault scope, the strategy engine is invoked to match the switching strategy and generate an executable task sequence.

[0105] The scheduling and execution module issues switching, rebuilding, or rollback commands and connects to the cloud computing platform to achieve automated execution.

[0106] By using machine learning models to analyze historical fault data, we can dynamically optimize strategy parameters and scheduling efficiency.

[0107] It should be noted that the process of performing multi-dimensional monitoring, fault detection, policy matching, and automated switching through the intelligent scheduling platform, and dynamically optimizing disaster recovery strategies and resource allocation based on real-time and historical data, aims to achieve rapid fault response and business continuity assurance through automation and intelligent means, and is suitable for the disaster recovery needs of high, medium, and low priority businesses.

[0108] Furthermore, the system collects key operational metrics through multi-dimensional monitoring modules, including heartbeat signals, database latency, business error rate, CPU utilization, memory usage, and network latency. Heartbeat signals are sent periodically via a distributed coordination tool to detect node liveness; database latency and business error rate are collected through log analysis and performance monitoring tools to reflect the database's health status; other metrics are obtained from the cloud computing management platform. The collected metrics are input into a multi-factor weighted model, and a weighted calculation formula is used to comprehensively determine the fault status, avoiding false alarms from single metrics and ensuring the accuracy of fault identification.

[0109] Furthermore, based on the fault status and business level, the strategy engine module calls the built-in rule template library to match suitable switching strategies and generate an executable task sequence. For L1 services, the strategy engine prioritizes triggering second-level automatic switching strategies; for L2 services, it supports automatic or manual confirmation of switching; and for L3 services, it generates a task sequence for snapshot loading and log recovery. The strategy matching process combines real-time operational metrics (such as load fluctuations) and historical fault data to dynamically adjust strategy parameters (such as switching thresholds and snapshot frequency) to adapt to changes in business needs. The generated task sequence includes specific operation instructions, such as node switching, container rebuilding, or database role changes, explicitly specifying the target node and execution parameters.

[0110] Furthermore, the scheduling and execution module receives task sequences and, through API connections to the cloud computing platform or load balancer, issues switchover, rebuild, or rollback commands. For example, a switchover command triggers virtual IP migration or DNS updates, a rebuild command initiates container scaling, and a rollback command reconfigures the primary / standby relationship after the primary node recovers. During execution, the system maintains resource mapping relationships (such as the binding of nodes to storage paths) to ensure consistent business status after the switchover. After execution, operation logs and timeline information are pushed to the audit system for archiving, supporting subsequent tracking and compliance checks.

[0111] Preferably, to achieve dynamic optimization, the system utilizes machine learning models (such as decision trees or neural networks) to analyze historical fault data, identify fault modes, and optimize strategy parameters. For example, by analyzing historical switchover times and failure rates, the model can adjust the heartbeat detection frequency or switchover threshold to improve response efficiency. The optimization results are fed back to the strategy engine to update rule templates or weight parameters, forming a closed-loop optimization mechanism. Furthermore, the system displays real-time topology, node status, and switchover history through a visual operations and maintenance interface, facilitating monitoring and decision-making by operations and maintenance personnel. This intelligent scheduling mechanism, through multi-dimensional monitoring, strategy matching, and automated execution, achieves closed-loop management from fault perception to recovery, significantly improving disaster recovery efficiency and system reliability.

[0112] In Embodiment 2 of the present invention, the present invention provides a data service continuity assurance system based on a multi-level disaster recovery strategy, such as... Figure 2 As shown, the system includes a disaster recovery level planning module 1, a local disaster recovery deployment module 2, and a remote disaster recovery construction module 3;

[0113] The disaster recovery level planning module 1 is used to allocate business levels and generate differentiated disaster recovery strategy templates based on the key indicators of the business system.

[0114] The same-city disaster recovery deployment module 2 is used to deploy same-city active-active clusters for high-priority services, deploy primary-standby asynchronous replication for medium-priority services, and deploy scheduled snapshot backups for low-priority services, according to the disaster recovery strategy template.

[0115] The off-site disaster recovery construction module 3 is used to build an off-site disaster recovery center based on the disaster recovery strategy template through asynchronous log replication and incremental snapshots, and supports mixed recovery of snapshots and logs to ensure cross-regional business continuity.

[0116] In a third embodiment of the present invention, the present invention provides an electronic device, including a memory and a processor, characterized in that the memory stores a computer program that can run on the processor, and when the program is executed on the processor, it implements the steps in the data service continuity assurance method based on a multi-level disaster recovery strategy as described above.

[0117] In Embodiment 4 of the present invention, the present invention provides a storage medium storing a computer program, characterized in that, when the computer program is executed by a processor, it implements the steps in the data service continuity assurance method based on a multi-level disaster recovery strategy as described above.

[0118] In summary, this invention provides a data service continuity assurance method based on a multi-level disaster recovery strategy. It achieves precise matching of resources and demands through hierarchical business planning, optimizing costs and efficiency. A local active-active mechanism combined with a distributed consistency protocol ensures second-level switching and zero data loss. Off-site disaster recovery employs a hybrid snapshot and log recovery approach, improving cross-regional recovery efficiency. An intelligent scheduling platform enables automatic fault detection and closed-loop response, significantly reducing manual intervention and improving system reliability and availability. This method is suitable for various scenarios such as finance and e-commerce.

[0119] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working process of the modules described above can be referred to the corresponding process in the aforementioned method implementation, and will not be repeated here.

[0120] The modules described as separate components may or may not be physically separate. Similarly, the components shown as modules may or may not be physical modules; they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0121] Furthermore, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module. The integrated module can be implemented in hardware or in a combination of hardware and software functional modules.

[0122] The integrated modules implemented as software functional modules described above can be stored in a computer-readable storage medium. These software functional modules, stored in a storage medium, include several instructions to cause a computer system (which may be a personal computer, server, or network system, etc.) or processor to execute some steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0123] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A data service continuity assurance method based on a multi-level disaster recovery strategy, characterized in that: include, Based on the key indicators of the business system, assign business levels and generate differentiated disaster recovery strategy templates; According to the disaster recovery strategy template, deploy a local active-active cluster for high-priority services, deploy asynchronous replication for primary and backup services for medium-priority services, and deploy scheduled snapshot backups for low-priority services. Based on the disaster recovery strategy template, an off-site disaster recovery center is built through asynchronous log replication and incremental snapshots, supporting hybrid recovery of snapshots and logs to ensure cross-regional business continuity.

2. The data service continuity assurance method based on a multi-level disaster recovery strategy according to claim 1, characterized in that: The process of allocating service levels and generating differentiated disaster recovery strategy templates includes, Obtain key metrics for the business system, including business importance, recovery time target, recovery point target, concurrent access volume, and data throughput; Based on the analytic hierarchy process, fuzzy comprehensive evaluation, or machine learning model, the key indicators are weighted and calculated to generate a comprehensive score and assign corresponding high, medium, and low business levels. Based on the business level, the disaster recovery template library is invoked to generate corresponding disaster recovery strategy templates with network topology, database architecture, and data synchronization mechanisms.

3. The data service continuity assurance method based on a multi-level disaster recovery strategy according to claim 2, characterized in that: The deployment of a dual-active cluster within the same city for high-priority services includes... Deploy business nodes in two geographically adjacent, physically isolated data centers and configure a distributed database to support real-time business synchronization; User requests are distributed by calculating weights based on network latency or node health status using a load balancer, and data consistency between nodes is ensured by using an optimized two-phase commit protocol. Configure heartbeat detection and virtual IP migration mechanisms to automatically switch traffic to healthy business nodes when a fault is detected, achieving a second-level switching.

4. The data service continuity assurance method based on a multi-level disaster recovery strategy according to claim 3, characterized in that: The aforementioned deployment of asynchronous replication for medium-priority services includes, Deploy the master node in the primary data center and the backup node in a geographically adjacent backup data center, and configure an asynchronous replication channel based on the database business logs; The health monitoring mechanism monitors the status of the master node and supports automatic or manual confirmation of switching to the backup node. During the switchover process, update routing rules to ensure that service recovery time is controlled within minutes.

5. The data service continuity assurance method based on a multi-level disaster recovery strategy according to claim 4, characterized in that: The deployment of scheduled snapshot backups for low-priority services includes, Configure a scheduled snapshot generation mechanism in the production environment to back up data mirrors via object storage or off-site data centers; In the event of a disaster, manually or semi-automatically load snapshot images to restore the business system state; Update backup metadata and recovery logs to ensure that data recovery points are controlled within hours.

6. The data service continuity assurance method based on a multi-level disaster recovery strategy according to claim 5, characterized in that: The construction of an off-site disaster recovery center through asynchronous log replication and incremental snapshots includes, Configure read-only replica databases and snapshot repositories in cross-regional disaster recovery centers, and transmit business logs through asynchronous log replication and high-priority channels; Periodically generate incremental snapshots and combine them with log compensation to achieve hybrid recovery of snapshots and logs; When the local node is unavailable, load the latest snapshot and replay the logs, switch the disaster recovery center to writable mode and update the access path; The generation of incremental snapshots includes, The business operations of the main data center are transformed into database business logs, and cross-regional transmission is optimized through compression and priority queuing. Incremental snapshots are generated based on differential analysis algorithms, reducing data transmission volume and storing them in the snapshot repository of the disaster recovery center; During the recovery process, the snapshot is loaded after verifying its integrity, and the latest data changes are compensated for by replaying the logs.

7. The data service continuity assurance method based on a multi-level disaster recovery strategy according to claim 1, characterized in that: It also includes, The intelligent scheduling platform performs multi-dimensional monitoring, fault detection, policy matching, and automated switching, and dynamically optimizes disaster recovery strategies and resource allocation based on real-time and historical data. Specifically, this includes... By monitoring and collecting indicators such as heartbeat signals, database latency, and business error rate from multiple dimensions, a multi-factor weighted model is used to determine the fault status. Based on the business level and fault scope, the strategy engine is invoked to match the switching strategy and generate an executable task sequence. The scheduling and execution module issues switching, rebuilding, or rollback commands and connects to the cloud computing platform to achieve automated execution. By using machine learning models to analyze historical fault data, we can dynamically optimize strategy parameters and scheduling efficiency.

8. A data service continuity assurance system based on a multi-level disaster recovery strategy, characterized in that: It includes a disaster recovery level planning module, a local disaster recovery deployment module, and an off-site disaster recovery construction module; The disaster recovery level planning module is used to allocate business levels and generate differentiated disaster recovery strategy templates based on the key indicators of the business system. The same-city disaster recovery deployment module is used to deploy same-city active-active clusters for high-priority services, deploy primary-standby asynchronous replication for medium-priority services, and deploy scheduled snapshot backups for low-priority services, according to the disaster recovery strategy template. The off-site disaster recovery construction module is used to build an off-site disaster recovery center based on the disaster recovery strategy template through asynchronous log replication and incremental snapshots, and supports mixed recovery of snapshots and logs to ensure cross-regional business continuity.

9. An electronic device, comprising a memory and a processor, characterized in that: The memory stores a computer program that can run on the processor, and when the program is executed on the processor, it implements the steps in the data service continuity assurance method based on a multi-level disaster recovery strategy as described in any one of claims 1-7.

10. A storage medium storing a computer program, characterized in that: When the computer program is executed by the processor, it implements the steps in the data service continuity assurance method based on a multi-level disaster recovery strategy as described in any one of claims 1-7.

Images