A three-site mutual backup method under a commercial secret network virtualization architecture

Abstract

This invention relates to a three-site mutual backup method under a commercial encrypted network virtualization architecture, belonging to the field of network communication technology. It addresses the technical problems of existing cross-regional and cross-network segment communication schemes, including insufficient interconnection security, adaptability, data backup efficiency, fault switching response speed, hardware architecture cost-effectiveness, and incomplete scenario coverage. The method includes the following steps: master station backup generation; parallel off-site replication; breakpoint resumption and anomaly recovery; local storage and version retention at branch stations; fault switching and local recovery. The three-site mutual backup method under the commercial encrypted network virtualization architecture of this invention offers: superior interconnection security and adaptability, more efficient and complete data backup, low-impact automated fault switching, a more reasonable and cost-controllable hardware architecture, higher detection accuracy, and stronger scalability.

Description

Technical Field

[0001] This invention relates to the field of network communication technology, and in particular to a three-site mutual backup method under a commercial cryptographic network virtualization architecture. Background Technology

[0002] With the advancement of digital transformation, core businesses are increasingly reliant on system continuity and data security. In commercial encrypted network scenarios, multi-site mutual backup has become a key means of preventing business interruption risks. Currently, small and medium-sized enterprises generally face disaster recovery needs for their core businesses. However, in the existing network architecture, the security and stability of cross-regional and cross-network segment communication, the efficiency of backup strategies, and the degree of automation in fault switching have all become core challenges restricting disaster recovery capabilities. At the same time, due to the strict cost control requirements of enterprises for disaster recovery construction, it is necessary to balance hardware investment, operation and maintenance costs, and space occupation while ensuring the implementation of functions.

[0003] The existing cross-regional, cross-network segment communication solution is a "two-location, dual-node mutual backup system." This solution achieves cross-network segment interconnection between two locations through an encrypted channel, employs backup software for full backup of core data (once a week) plus daily incremental backup, and stores the backup data at the branch station. The hardware architecture adopts a "distributed terminal deployment" mode, meaning each office node is equipped with an independent office computer and computing computer, without centralized server virtualization management. During failover, the failure status of the main station needs to be manually checked, the branch station backup data recovery process needs to be manually initiated, and terminal network access parameters need to be configured. Terminal users need to log in again or switch access addresses.

[0004] This solution has the following shortcomings:

[0005] 1. Insufficient interconnection security and adaptability; security level does not meet the requirements of commercial encrypted networks; does not support public IP address translation and penetration; cross-network segment tunnels are prone to interruption; cannot adapt to complex network environments.

[0006] 2. Low data backup efficiency and poor integrity: Full backup has a long cycle and incremental backup has a low frequency. Core data cannot be backed up in a timely manner after updates. There is no post-backup verification mechanism, and it is difficult to detect when the backup set is damaged, resulting in a high risk of data loss.

[0007] 3. Slow and inaccurate failover response: It relies on manual detection and operation, and the failover process is cumbersome and prone to errors; it cannot detect the availability of core services by only probing network connectivity, and is prone to false failovers such as "network is working but service is not"; the recovery time is far beyond what is acceptable for business operations.

[0008] 4. Low cost-effectiveness of hardware architecture: Terminal devices are deployed in a decentralized manner, office computers and computing computers are configured independently, the number of devices is large, the workload of operation and maintenance is large and difficult; there is no centralized virtualization management, the space occupancy rate is high, and the hardware procurement and subsequent maintenance costs are high.

[0009] 5. Incomplete scenario coverage: There is no fallback access solution in the event of a complete main site outage, resulting in a complete business interruption and an inability to guarantee continuity. Summary of the Invention

[0010] This invention aims to address the technical problems of existing cross-regional and cross-network segment communication schemes, such as insufficient interconnection security, adaptability, data backup efficiency, fault switching response speed, hardware architecture cost-effectiveness, and incomplete scenario coverage. It provides a three-site mutual backup method under a commercial encrypted network virtualization architecture.

[0011] To solve the above-mentioned technical problems, the technical solution of the present invention is as follows:

[0012] A method for three-site mutual backup under a commercial cryptographic network virtualization architecture, applicable to systems with interconnected data connections: a master station, a first branch station, and a second branch station; the method includes the following steps:

[0013] Step 1: Main site backup generation;

[0014] The master station triggers backup tasks according to a preset time sequence; when the task is executed, the backup agent mounts the production storage volume through the storage direct connection protocol, creates a storage-level snapshot, reads the disk block data stream from the snapshot, and generates a backup set;

[0015] Step 2: Parallel off-site replication;

[0016] After the backup set is generated, the master station simultaneously initiates two independent replication subtasks, pointing to the first sub-station and the second sub-station respectively; each sub-station establishes an independent connection, transmits the backup set to the first or second sub-station via an encrypted channel and bandwidth isolation control;

[0017] Step 3: Resuming interrupted downloads and recovering from errors;

[0018] During the replication process, the master maintains a transmission status table to record the delivery status of each data block to the first or second substation.

[0019] If the network is interrupted, the replication manager will pause the task after detecting the exception, and automatically reconnect after the network is restored. It will resume the transfer of incomplete blocks according to the transfer status table, and confirmed blocks do not need to be retransmitted.

[0020] If the retries still fail after multiple attempts, mark the first or second substation as offline and issue an alarm.

[0021] Step 4: Local storage and version retention at the sub-site;

[0022] The receiving end of the first or second substation writes the data blocks to the local storage warehouse and independently maintains the backup set metadata; the local storage warehouses of the main station, the first substation, and the second substation periodically exchange backup set lists through the protocol.

[0023] Step 5: Failover and Local Recovery;

[0024] When the main station service is interrupted, the first and second substations trigger a state switch through detection and activate the local recovery server. The local recovery server directly reads the latest backup set in the local storage warehouse, restores the data blocks to the virtualization platform, and completes the rapid reconstruction of the business.

[0025] In the above technical solution, the process of activating the local recovery server by detecting the state switch triggered by the first and second substations in step 5 is as follows:

[0026] When core headquarters services fail, the following steps are included:

[0027] Step 511: Policy routing triggers switching;

[0028] Once the detection status changes to a failure, if the policy routing conditions of the first or second substation are met, a traffic switch will be triggered immediately, and the backup core server will be started manually or automatically by script at the first or second substation.

[0029] The policy matches all traffic from the headquarters terminal accessing the core service, and the policy routing directs this traffic to the first or second branch station to restore the core server.

[0030] Step 512: Seamless traffic switching;

[0031] Traffic from the first and / or second branch station terminals accessing the headquarters' core services is directly forwarded to the local backup core server.

[0032] Backup data transmission switching: When the backup traffic from the original headquarters to the first or second branch station is interrupted, the system will automatically switch to the first or second branch station to restore the business traffic of the server switched to the branch station terminal. At the same time, the branch station firewall will stop sending backup requests to the headquarters.

[0033] Step 513: Status synchronization and alarms;

[0034] The firewall at the first or second branch station automatically records the switchover log and sends an alarm to the operation and maintenance platform to notify the operation and maintenance personnel to handle the headquarters failure.

[0035] Port access control takes effect simultaneously: the recovery server at the first or second substation only allows access from authorized local terminals;

[0036] Step 514: Continuous fault detection;

[0037] The detection instance continues uninterrupted, continuously probing the core service ports of the headquarters, waiting for the headquarters to recover from the failure; at the same time, the firewall of the first or second branch station continuously monitors the encrypted tunnel status to prepare for subsequent switchback.

[0038] When the headquarters network fails, the following steps are included:

[0039] Step 521: Policy routing triggers switching;

[0040] Once the detection status changes to a failure, the conditions for substation policy routing are met, and traffic switching is immediately triggered. At the same time, the backup core server is manually started or automatically started by script at the first or second substation.

[0041] At this time, the encryption connection between the main station and the first and second substations is completely disconnected. The main station terminal users can use the temporary network to log in to the first or second substation firewall's built-in secure socket layer virtual private network account to access the core backup server.

[0042] Step 522: Seamless traffic switching;

[0043] Traffic from the first or second branch station terminal accessing the headquarters' core services is directly forwarded to the local backup core server.

[0044] Step 523: Status synchronization and alarms;

[0045] The firewall at the first or second branch station automatically records the switchover log and can be linked to the operation and maintenance platform to send alarms and notify operation and maintenance personnel to handle headquarters failures.

[0046] Port access control takes effect simultaneously: the recovery server at the first or second substation only allows access from authorized local terminals;

[0047] Step 524: Continuous fault detection;

[0048] The detection instance continues uninterrupted, continuously probing the core service ports of the headquarters while waiting for the headquarters to recover from the failure; at the same time, the branch firewall continuously monitors the encrypted tunnel status.

[0049] When a branch network fails, the following steps are included:

[0050] Step 531: After the detection status of the first or second substation changes to fault, all encrypted communication with the main station and the second substation is disconnected, or all encrypted communication with the main station and the first substation is disconnected. The terminal user of the first or second substation uses a temporary network to log in to the main station firewall's built-in Secure Sockets Layer (SSL) virtual private network account to access the core server.

[0051] In the above technical solution, a precise service status identification is provided between the main station, the first substation, and the second substation. This precise service status identification specifically includes: fixed address to ensure stable detection: both the source address and the destination address of the detection are fixed values;

[0052] Precise service port detection: Core service ports are detected through the TCP three-way handshake. Service is only considered to be normal when the port is in listening state, thus avoiding false judgments.

[0053] Second-level fault response: After three consecutive failed probes, the tracking status is switched immediately, and the policy routing is executed synchronously to switch traffic.

[0054] In the above technical solution, a commercial-grade encrypted channel for cross-regional transmission is established between the main station, the first substation, and the second substation. This encrypted channel is specifically as follows:

[0055] Data encryption: The core business data of the main site is first encrypted through the protocol, and the ciphertext is generated by the AES-256 algorithm. At the same time, the check value is generated by the SHA2-256 algorithm.

[0056] Tunnel encapsulation: The encrypted ciphertext is encapsulated by a general routing encapsulation protocol, an internal tunnel address header is added, and it is transmitted to the first or second branch station with a fixed public address via a dedicated China Unicom line;

[0057] Decapsulation and decryption: After receiving the data packet, the firewall of the first or second substation first decapsulates the general route encapsulation tunnel, extracts the Internet Protocol security ciphertext, then verifies the data integrity through SHA2-256, and decrypts it through AES-256 to obtain the original internal network data.

[0058] The three-site mutual backup method under the commercial cryptographic network virtualization architecture of the present invention has the following beneficial effects:

[0059] 1. Superior interconnectivity and compatibility: Employs address encryption channel encryption for higher security and cross-regional networking; enables address translation to penetrate public network address translation environments, improving tunnel stability by 80% and adapting to various environments for commercial encrypted network deployment;

[0060] 2. More efficient and complete data backup: 5 incremental backups per day (compared to 1 per day with existing technology), data update delay ≤ 5 hours; new post-backup verification mechanism, backup set availability reaches 100%; 30-day backup set retention supports multi-version recovery;

[0061] 3. Automated and low-impact fault switching: Fault detection, recovery startup, and traffic switching can be completed without much manual intervention. Terminals do not need to be reconfigured, resulting in a significant improvement in user experience.

[0062] 4. The hardware architecture is more rational and the cost is controllable, reducing maintenance workload by 90% and space occupation by 80%;

[0063] 5. Higher detection accuracy: By detecting core service ports and combining them with access control configuration, the false switchover rate is 0.

[0064] 6. Enhanced scalability: New terminals / services can be quickly deployed through virtualization without the need to purchase a large amount of additional hardware, greatly reducing space usage and maintenance costs; existing technologies have a fixed number of terminals, making expansion difficult. Attached Figure Description

[0065] The present invention will now be described in further detail with reference to the accompanying drawings and specific embodiments.

[0066] Figure 1a This is a three-site network topology diagram of the system to which the three-site mutual backup method under the commercial cryptographic network virtualization architecture of the present invention is applicable.

[0067] Figure 1b for Figure 1a The diagram shows the unfolded layout of the main site. Figure 1c for Figure 1a A schematic diagram of the unfolded substation 1 in the diagram. Figure 1d for Figure 1a A schematic diagram of the unfolded substation 2 in the diagram.

[0068] Figure 2 This diagram illustrates the mechanism for three-site backup and address translation under a fixed public IP address in the three-site mutual backup method of the commercial encrypted network virtualization architecture of the present invention. Detailed Implementation

[0069] The inventive concept of this invention is as follows:

[0070] This invention employs a high-security encryption algorithm, supports public network address translation, ensures the stability of cross-network segment tunnels, meets the security requirements of commercial encrypted network communication, and achieves high-strength encrypted interconnection of three locations and three nodes.

[0071] The design incorporates an "initial full backup + daily high-frequency incremental backup" strategy, along with post-backup verification and multi-version retention mechanisms, to ensure the real-time integrity of core business data and build an efficient and complete backup system.

[0072] Establish a precise service availability detection mechanism, initiate the substation recovery process in case of failure, eliminate the need for manual configuration of terminals, and achieve a recovery time of ≤30 minutes, thus realizing low-perception fault switching.

[0073] Optimize hardware architecture, balance cost and efficiency, support centralized server virtualization management, reduce the number of devices, reduce operation and maintenance costs and space occupation, and keep the total investment under control.

[0074] Differentiated switching and access solutions are designed for the two scenarios of "server-only failure" and "total failure" of the main site to ensure business continuity and cover all failure scenarios.

[0075] The present invention will now be described in detail with reference to the accompanying drawings.

[0076] The three-site mutual backup method under the commercial cryptographic network virtualization architecture of the present invention is applicable to the following overall system architecture:

[0077] The system is interconnected with the following data stations: main station (head office), first branch station (branch office), and... Figure 1a and Figure 1c In this context, "Substation 1" represents the first substation, and "Second Substation" (branch company) is used. Figure 1a and Figure 1d The architecture consists of three nodes (using "substation 2" to represent the second substation), and is divided into three layers: network, data, and application. It relies on a combination of address encryption channel, PBR (policy-based routing), Track, and NQA (network quality analysis) network configuration, full and incremental backup strategies for backup software, and address reuse and encryption channel fallback solutions in a single-domain environment. This enables mutual backup and rapid failover across the three locations, meeting the disaster recovery needs of small to medium-sized core businesses.

[0078] The present invention provides a three-site mutual backup method under a commercial encrypted network virtualization architecture, comprising the following steps:

[0079] Step 1: Main site backup generation;

[0080] The master station triggers backup tasks according to a preset time sequence; when the task is executed, the backup agent mounts the production storage volume through the storage direct connection protocol, creates a storage-level snapshot, reads the disk block data stream from the snapshot, and generates a backup set;

[0081] Step 2: Parallel off-site replication;

[0082] After the backup set is generated, the master station simultaneously initiates two independent replication subtasks, pointing to the first sub-station and the second sub-station respectively; each sub-station establishes an independent connection, transmits the backup set to the first or second sub-station via an encrypted channel and bandwidth isolation control;

[0083] Step 3: Resuming interrupted downloads and recovering from errors;

[0084] During the replication process, the master maintains a transmission status table to record the delivery status of each data block to the first or second substation.

[0085] If the network is interrupted, the replication manager will pause the task after detecting the exception, and automatically reconnect after the network is restored. It will resume the transfer of incomplete blocks according to the transfer status table, and confirmed blocks do not need to be retransmitted.

[0086] If the retries still fail after multiple attempts, mark the first or second substation as offline and issue an alarm.

[0087] Step 4: Local storage and version retention at the sub-site;

[0088] The receiving end of the first or second substation writes the data blocks to the local storage warehouse and independently maintains the backup set metadata; the local storage warehouses of the main station, the first substation, and the second substation periodically exchange backup set lists through the protocol.

[0089] Step 5: Failover and Local Recovery;

[0090] When the main station service is interrupted, the first and second substations trigger a state switch through detection and activate the local recovery server. The local recovery server directly reads the latest backup set in the local storage warehouse, restores the data blocks to the virtualization platform, and completes the rapid reconstruction of the business.

[0091] The following is a more detailed description of the three-site mutual backup method under the commercial cryptographic network virtualization architecture of the present invention and the network architecture (three-site three-node network architecture) of the applicable system:

[0092] 1. Network layer linkage logic;

[0093] Main site: core service network segment (including domain controller server, code repository server, management server, core business server cluster), computing service network segment (including computing server, GPU computing node, computing node cluster), backup software main client, firewall;

[0094] Substation 1: Core service network segment (including domain controller server, code repository server, management server, backup software and recovery server for core business server cluster), computing service network segment (including computing server, GPU computing node, computing node cluster), backup software segment 1, firewall;

[0095] Sub-site 2: Core service network segment (including domain controller server, code repository server, management server, backup software and recovery server for core business server cluster), computing service network segment (including computing server, GPU computing node, computing node cluster), backup software segment 2, firewall;

[0096] Interconnection: The firewalls of the main station, substation 1, and substation 2 establish encrypted address channels in pairs, i.e., IPSEC / VPN encrypted tunnels. Tunnel 1: Main station - Substation 1; Tunnel 2: Main station - Substation 2; Tunnel 3 (optional): Substation 1 - Substation 2. Address translation traversal is enabled to adapt to public IP address translation environments, such as NAT traversal for public IP address translation scenarios. See the detailed network topology diagram for the three locations. Figures 1a-1d .

[0097] 2. Address Translation: Pass-through of fixed public IP addresses - Pass-through of internal network segments under fixed public IP addresses;

[0098] 2.1 Configuration Implementation (Taking the firewalls of the main station and substation 1 as an example);

[0099] Using a dedicated public IP address from a carrier eliminates the need to adapt to dynamic IP address changes, simplifying address translation configuration. The public IP address is used directly as the tunnel identifier, and ACL (Access Control List) policies enable precise mapping of internal network segments.

[0100] The firewalls at Substation 1 and Substation 2 are configured symmetrically, requiring only modification of the local public IP address, internal network segment, and peer public IP address parameters.

[0101] 2.2 Address Translation and Tunneling Working Principle (see...) Figure 2 Address translation and tunneling working principle layer).

[0102] Public IP (address) direct identification: The public interface of the three firewalls is configured with a fixed public IP (address) as the source / destination address for establishing the encrypted tunnel. This eliminates the need for UDP (Datagram Protocol) port 4500 encapsulation negotiation; the tunnel is established directly based on the public IP (address). See [link / reference]. Figure 2 .

[0103] External network access traffic undergoes NAT (Network Address Translation), while tunnel traffic exempts NAT from retaining the original internal network IP address, including the following steps:

[0104] By using ACL (Access Control List) policies, tunnel traffic and external network access traffic are clearly distinguished. Only terminal internet traffic undergoes address translation, while tunnel traffic is transmitted within the GRE (Generic Router Encapsulation) tunnel using the original internal network IP (address), enabling direct interconnection between cross-regional internal network segments.

[0105] Initiating end: Main site backup server (i.e.) Figure 2 (The "main backup software client" in the middle).

[0106] Data source: Main site core service server;

[0107] Backup targets: Backup server for branch station 1, backup server for branch station 2;

[0108] See backup task process. Figure 2The three-site backup task process layer includes stages 1-4. Stage 1: Initial full backup, that is, the first full backup is performed on both substations → Stage 2: 5 incremental backups per day (2:00 / 7:00 / 12:00 / 17:00 / 22:00) → Stage 3: Post-backup verification → Stage 4: Retain 30-day backup set, that is, a 30-day backup set retention mechanism.

[0109] 3. Automatic detection: Accurate service status identification is achieved under a fixed public IP address;

[0110] 3.1 Configuration Implementation (Taking Substation 1's Detection of the Master Station Domain Controller Service as an Example);

[0111] In a fixed public IP address environment, the source / destination IP address for probing is fixed, allowing for more precise ACL (Access Control List) policy configuration without frequent adjustments. The specific steps are as follows:

[0112] Step 1: Configure an NQA (Network Quality Assurance) service port probe instance;

[0113] Step 2: Configure the Track module to associate with NQA detection results;

[0114] Step 3: Configure policy routing to link Track status.

[0115] 3.2 Working principle;

[0116] Fixed IP (address) ensures stable detection: The source IP (address) (internal network interface of substation 1 and / or substation 2) and the destination IP (address) (core service of the main station) are both fixed values, and the detection target will not drift due to changes in the network environment, with a detection accuracy of 100%.

[0117] Precise service port detection: Core service ports are detected through the TCP three-way handshake. Service is determined to be normal only when the port is in listening state, avoiding the false judgment of "network is working but service is not working".

[0118] Second-level fault response: After three consecutive failed probes (total time 30 seconds), the Track state immediately switches, and the policy routing synchronously performs traffic switching, without any manual intervention.

[0119] 4. Encrypted Channel: Commercial-grade cross-regional transmission is achieved under a fixed public IP address;

[0120] 4.1 Configuration Implementation (Taking the encrypted tunnel between the main station and substation 1 as an example);

[0121] Step 1: Configure security proposals;

[0122] Step 2: Configure security policies;

[0123] Step 3: Configure GRE (Generic Routing Encapsulation) tunnel and bind policies.

[0124] Configure a symmetrical GRE (Generic Router Encapsulation) tunnel interface on the firewall of Substation 1, set the tunnel IP (address) to xxx, and the source address to its own fixed public IP (address) to complete the construction of the encrypted tunnel.

[0125] The encrypted tunnel between the main station and substation 2 is the same as that between the main station and substation 1, and will not be described again here.

[0126] 4.2 Encrypted transmission process;

[0127] Data encryption: The core business data of the main site (backup data / business requests) is first encrypted through the protocol, and the ciphertext is generated using the AES-256 algorithm. At the same time, the check value is generated using the SHA2-256 algorithm.

[0128] Tunnel encapsulation: The encrypted ciphertext is encapsulated using the GRE protocol, an internal tunnel IP (address) header is added, and it is transmitted to the fixed public IP (address) of substation 1 via a dedicated China Unicom line.

[0129] Decapsulation and decryption: After receiving the data packet, the firewall of Substation 1 first decapsulates the GRE (Generic Routing Encapsulation) tunnel, extracts the IPSec (Internet Protocol Security) ciphertext, then verifies the data integrity using the SHA2-256 algorithm, and decrypts it using the AES-256 algorithm to obtain the original intranet data.

[0130] 5. Real-time backup of data in multiple locations is achieved (i.e., the three-location mutual backup method of this invention).

[0131] The three-site mutual backup method under the commercial cryptographic network virtualization architecture of the present invention includes the following steps:

[0132] Deployment mode: Deploy the primary backup server in the primary network and deploy backup service replicas in the branch networks.

[0133] Step 1: Main site backup generation;

[0134] The primary backup server triggers backup tasks according to a preset time sequence (multiple time points daily). During task execution, the backup agent mounts the production storage volume via the storage direct connection protocol, creates a storage-level snapshot, reads the disk block data stream from the snapshot, and generates a backup set.

[0135] Step 2: Parallel off-site replication;

[0136] After the backup set is generated, the master backup server's master replication management server simultaneously initiates two independent replication subtasks, pointing to branch station 1 and branch station 2 respectively. Each subtask establishes an independent connection, transmits the backup set to both locations via an encrypted channel, and uses bandwidth isolation control (the master station allocates outbound bandwidth according to a preset ratio). The transmission adopts a multi-threaded concurrent mode, splitting the backup set into several data blocks and sending them in parallel. The receiving end verifies the hash of each block to ensure data integrity.

[0137] Step 3: Resuming interrupted downloads and recovering from errors;

[0138] During replication, the master backup server maintains a transmission status table, recording the delivery status of each data block to the substation. If the network is interrupted, the replication management server detects the anomaly and pauses the task. Once the network is restored, it automatically reconnects and resumes the transmission of incomplete blocks according to the status table; confirmed blocks do not need to be retransmitted. If multiple retries still fail, the substation is marked offline and an alarm is triggered. Simultaneously, it is possible to relay data through a third-party station.

[0139] Step 4: Local storage and version retention at the sub-site;

[0140] The receiving end at each branch station writes data blocks to its local storage warehouse and independently maintains backup set metadata. The branch station retention policy engine can be configured with a different retention period than the main station, supporting long-term retention of historical versions. The local storage warehouses in the three locations (main station, branch station 1, and branch station 2) periodically exchange backup set lists through a protocol to ensure state synchronization.

[0141] Step 5: Failover and Local Recovery;

[0142] When the primary site service is interrupted, the branch sites (branch site 1 and / or branch site 2) trigger a state switch by detection, activating the local recovery server. The recovery server directly reads the latest backup set from the local storage repository, restores the data blocks to the virtualization platform, and completes the rapid reconstruction of business operations.

[0143] Because the data is available locally, the recovery process does not require cross-site transfer, ensuring a recovery time of ≤30 minutes.

[0144] 6. Fault switching process (i.e., step 5 of the three-site mutual backup method of the present invention).

[0145] In step 5 of this invention, the process of substation 1 and substation 2 activating the local recovery server (i.e., the failover process) by detecting and triggering state switching is specifically as follows:

[0146] Scenario 1: Core service failure at headquarters;

[0147] The handover is performed independently by the branch firewall (the headquarters firewall does not participate in the handover logic, but only maintains basic connectivity). Taking branch 1 as an example, the handover steps are as follows (the handover logic for branch 2 is exactly the same as that for branch 1):

[0148] Step 511: Policy routing triggers switch (0-1 seconds);

[0149] Once the detection status changes to "invalid" (fault), the conditions for the substation policy routing are met, and traffic switching is immediately triggered. At the same time, the backup core server is started manually or automatically by script on substation 1.

[0150] The policy matches all traffic accessing the core services from the headquarters terminal, and the policy routing directs this traffic to the core server used for recovery at branch station 1.

[0151] Step 512: Seamless traffic switching (1-5 seconds);

[0152] Traffic from terminals at branch station 1 accessing the headquarters' core services no longer enters the encrypted tunnel but is directly forwarded to the local backup core server. The server has been periodically synchronizing the headquarters' core data (backup complete) and can immediately take over business operations without the terminals noticing (no network configuration modifications are required). Terminals at branch station 2 are also unaware of this and still access the branch station 1 backup core server through the encrypted tunnel.

[0153] Backup data transmission switching: The backup traffic from the original headquarters to branch station 1 is interrupted and automatically switched to the business traffic of "branch station 1 recovery server → branch station 1 terminal". At the same time, the firewall of branch station 1 suspends sending backup requests to the headquarters to avoid invalid transmission.

[0154] Step 513: Status synchronization and alarm (5-10 seconds);

[0155] The firewall at Substation 1 automatically records switchover logs (switchover time, fault type, and detection status), and can link with the operations and maintenance platform to send alarms (such as SMS and email) to notify operations and maintenance personnel to handle headquarters faults.

[0156] Port access control takes effect simultaneously: Substation 1 recovery server only allows access from local authorized terminals, prohibits interference from other IPs, and ensures data security during the recovery period.

[0157] Step 514: Continuous fault detection (continues to be executed after switchover);

[0158] The detection instance continues uninterrupted, continuously probing the core service ports of the headquarters, awaiting the recovery of the headquarters failure; at the same time, the firewall of Substation 1 continuously monitors the status of the encrypted tunnel, preparing for subsequent switchback.

[0159] Additional information: If the fault is "tunnel interruption", the firewall of Substation 1 will attempt to re-establish the encrypted tunnel every 30 seconds after the switch. After the tunnel is restored, if the headquarters service is still normal, the switchback will be automatically triggered.

[0160] Scenario 2: Headquarters network failure;

[0161] The probe packet could not be transmitted through the encrypted tunnel (tunnel interrupted), and its status was "invalid" (failure); at the same time, the substation firewall detected that the peer negotiation failed, and the tunnel status was "down" (closed). Taking substation 1 as an example, the switching steps are as follows (the switching logic for substation 2 is exactly the same):

[0162] Step 521: Policy routing triggers switchover (0-1 seconds);

[0163] After the detection status changes to "invalid" (fault), the conditions for policy routing of substation 1 are met, and traffic switching is immediately triggered. At the same time, the backup core server is started manually or automatically by script on substation 1.

[0164] At this point, the encryption connection between the main station and the two substations is completely disconnected. The main station terminal users can log in to the core backup server using the SSL VPN (Secure Sockets Layer Virtual Private Network) account built into the firewall of substation 1 using a temporary network (mobile hotspot, WIFI, etc.).

[0165] Step 522: Seamless traffic switching (1-5 seconds);

[0166] Traffic from terminals at branch station 1 accessing the headquarters' core services no longer enters the encrypted tunnel but is directly forwarded to the local backup core server. The server has been periodically synchronizing the headquarters' core data (backup complete) and can immediately take over business operations without the terminals noticing (no network configuration modifications are required). Terminals at branch station 2 are also unaware of this and still access the branch station 1 backup core server through the encrypted tunnel.

[0167] Step 523: Status synchronization and alarm (5-10 seconds);

[0168] The firewall at Substation 1 automatically records the switchover log (switchover time, fault type, detection status) and can link with the operations and maintenance platform to send alarms (such as SMS and email) to notify operations and maintenance personnel to handle headquarters faults. Port access control is also activated simultaneously: the Substation 1 recovery server only allows access from authorized local terminals, prohibiting interference from other IPs to ensure data security during recovery.

[0169] Step 524: Continuous fault detection (continues to be executed after switchover);

[0170] The detection instance continues uninterrupted, continuously probing the core service ports of the headquarters, awaiting the recovery of the headquarters failure; at the same time, the firewall of Substation 1 continuously monitors the status of the encrypted tunnel, preparing for subsequent switchback.

[0171] Scenario 3: Substation network failure (taking substation 1 as an example, substation 2 follows the same logic as substation 1);

[0172] The probe packet could not be transmitted through the encrypted tunnel (tunnel interrupted), and its status was "invalid" (failure); at the same time, the main station firewall detected that the peer negotiation failed, and the tunnel status was "down" (closed). The switching steps are as follows (taking substation 1 as an example, the switching logic for substation 2 is exactly the same):

[0173] Step 531: After the detection status of Substation 1 changes to "invalid" (fault), all encrypted communication with the main station and Substation 2 is disconnected. Substation 1 terminal users use temporary networks (mobile hotspots, WIFI, etc.) to log in to the main station firewall's built-in SSL VPN (Secure Sockets Layer Virtual Private Network) account to access the core server.

[0174] 7. Anti-misoperation supplementary mechanism: Core server port access control and disabling implementation;

[0175] The core of this mechanism is to ensure that probes only reflect the true operating status of core services through precise port access control (allowing only legitimate probes and authorized access) and mandatory disabling of idle ports (preventing non-service processes from occupying ports), thereby completely avoiding false switching caused by "unauthorized port occupation and illegal access interfering with probes". It is compatible with topologies where the headquarters is connected and branches are NAT-enabled, and is deeply integrated with existing automatic probe logic.

[0176] 7.1 Specific implementation (headquarters and branches, adapting to topology differences);

[0177] (1) Headquarters core server: Port access control and disabling implementation;

[0178] The headquarters core servers (such as domain controllers and backup master servers) are connected to the headquarters intranet switch. Port control is protected by a triple layer of protection: "switch ACL (access control policy) + server local firewall + side firewall ACL (access control policy)" to ensure accurate management and adapt to the side topology.

[0179] (2) Core server for partial recovery: port access control and disabling implementation;

[0180] The branch recovery uses a core server that is directly connected to the branch firewall's internal network interface. Port control is implemented by the branch firewall and is isolated from the branch's NAT (Network Address Translation) and tunneling policies to avoid interference.

[0181] Additional notes:

[0182] ① The core server configuration for Substation 2 is completely identical to that for Substation 1, with only the corresponding IP (address) parameters modified;

[0183] ② The "legitimate IP (address)" for port access control must strictly correspond to the existing probe source IP (address) and authorized terminal IP (address) to avoid probe failure caused by "probe IP (address) not being allowed";

[0184] ③ The "blacklist fallback" strategy is adopted for disabling idle ports. Core business ports are allowed first, and then all other ports are disabled to ensure that no one is missed.

[0185] 7.2 Working principle (core logic for preventing accidental switching);

[0186] Port Access Control: Preventing Probe Interference: Through switch / firewall ACLs (Access Policies), only branch probe IPs (addresses) and authorized management terminals are allowed to access the core server's business ports. Access requests from any other IPs (addresses) (including unauthorized terminals on the internal network and illegal public IPs (addresses)) are blocked. This avoids false alarms caused by "illegal IPs (addresses) accessing ports" or "unauthorized processes occupying ports" (e.g., a port is detected as open, but the core service is not actually running).

[0187] Disable unused ports: Eliminate the risk of false positives: Forcefully disable all unused ports on the core server to prevent non-core services, virus processes, and illegal programs from occupying ports.

[0188] In conjunction with existing detection logic: Port access control rules are strictly matched with the detection source IP (address) (e.g., branch detection is allowed separately) to ensure that detection traffic can smoothly penetrate the headquarters' side firewall and switch / branch firewall to reach the core service port; at the same time, through triple protection (side firewall + switch + local server), it is ensured that the detection results only reflect the real operating status of the core service, eliminating false switching from the source.

[0189] Obviously, the above embodiments are merely illustrative examples for clear explanation and are not intended to limit the implementation. Those skilled in the art will recognize that other variations or modifications can be made based on the above description. It is neither necessary nor possible to exhaustively list all possible implementations here. However, obvious variations or modifications derived therefrom are still within the scope of protection of this invention.

Claims

1. A three-site mutual backup method under a commercial encrypted network virtualization architecture, characterized in that, This method is applicable to systems that are interconnected: a main station, a first substation, and a second substation; the method includes the following steps: Step 1: Main site backup generation; The master station triggers backup tasks according to a preset time sequence; when the task is executed, the backup agent mounts the production storage volume through the storage direct connection protocol, creates a storage-level snapshot, reads the disk block data stream from the snapshot, and generates a backup set; Step 2: Parallel off-site replication; After the backup set is generated, the master station simultaneously initiates two independent replication subtasks, pointing to the first sub-station and the second sub-station respectively; each sub-station establishes an independent connection, transmits the backup set to the first or second sub-station via an encrypted channel and bandwidth isolation control; Step 3: Resuming interrupted downloads and recovering from errors; During the replication process, the master maintains a transmission status table to record the delivery status of each data block to the first or second substation. If the network is interrupted, the replication manager will pause the task after detecting the exception, and automatically reconnect after the network is restored. It will resume the transfer of incomplete blocks according to the transfer status table, and confirmed blocks do not need to be retransmitted. If the retries still fail after multiple attempts, mark the first or second substation as offline and issue an alarm. Step 4: Local storage and version retention at the sub-site; The receiving end of the first or second substation writes the data blocks to the local storage warehouse and independently maintains the backup set metadata; the local storage warehouses of the main station, the first substation, and the second substation periodically exchange backup set lists through the protocol. Step 5: Failover and Local Recovery; When the main station service is interrupted, the first and second substations trigger a state switch through detection and activate the local recovery server. The local recovery server directly reads the latest backup set in the local storage warehouse, restores the data blocks to the virtualization platform, and completes the rapid reconstruction of the business.

2. The three-site mutual backup method under the commercial encrypted network virtualization architecture according to claim 1, characterized in that, The process of activating the local recovery server by detecting the state switch triggered by the first and second substations in step 5 is as follows: When core headquarters services fail, the following steps are included: Step 511: Policy routing triggers switching; Once the detection status changes to a failure, if the policy routing conditions of the first or second substation are met, a traffic switch will be triggered immediately, and the backup core server will be started manually or automatically by script at the first or second substation. The policy matches all traffic from the headquarters terminal accessing the core service, and the policy routing directs this traffic to the first or second branch station to restore the core server. Step 512: Seamless traffic switching; Traffic from the first and / or second branch station terminals accessing the headquarters' core services is directly forwarded to the local backup core server. Backup data transmission switching: When the backup traffic from the original headquarters to the first or second branch station is interrupted, the system will automatically switch to the first or second branch station to restore the business traffic of the server switched to the branch station terminal. At the same time, the branch station firewall will stop sending backup requests to the headquarters. Step 513: Status synchronization and alarms; The firewall at the first or second branch station automatically records the switchover log and sends an alarm to the operation and maintenance platform to notify the operation and maintenance personnel to handle the headquarters failure. Port access control takes effect simultaneously: the recovery server at the first or second substation only allows access from authorized local terminals; Step 514: Continuous fault detection; The detection instance continues uninterrupted, continuously probing the core service ports of the headquarters, waiting for the headquarters to recover from the failure; at the same time, the firewall of the first or second branch station continuously monitors the encrypted tunnel status to prepare for subsequent switchback. When the headquarters network fails, the following steps are included: Step 521: Policy routing triggers switching; Once the detection status changes to a failure, the conditions for substation policy routing are met, and traffic switching is immediately triggered. At the same time, the backup core server is manually started or automatically started by script at the first or second substation. At this time, the encryption connection between the main station and the first and second substations is completely disconnected. The main station terminal users can use the temporary network to log in to the first or second substation firewall's built-in secure socket layer virtual private network account to access the core backup server. Step 522: Seamless traffic switching; Traffic from the first or second branch station terminal accessing the headquarters' core services is directly forwarded to the local backup core server. Step 523: Status synchronization and alarms; The firewall at the first or second branch station automatically records the switchover log and sends an alarm to the operation and maintenance platform to notify the operation and maintenance personnel to handle the headquarters failure. Port access control takes effect simultaneously: the recovery server at the first or second substation only allows access from authorized local terminals; Step 524: Continuous fault detection; The detection instance continues uninterrupted, continuously probing the core service ports of the headquarters while waiting for the headquarters to recover from the failure; at the same time, the branch firewall continuously monitors the encrypted tunnel status. When a branch network fails, the following steps are included: Step 531: After the detection status of the first or second substation changes to fault, all encrypted communication with the main station and the second substation is disconnected, or all encrypted communication with the main station and the first substation is disconnected. The terminal user of the first or second substation uses a temporary network to log in to the main station firewall's built-in Secure Sockets Layer (SSL) virtual private network account to access the core server.

3. The three-site mutual backup method under the commercial encrypted network virtualization architecture according to claim 1 or 2, characterized in that, A precise service status identification system is established between the main station, the first branch station, and the second branch station. This precise service status identification specifically includes: Fixed addresses ensure stable detection: both the source and destination addresses are fixed values; Precise service port detection: Core service ports are detected through the TCP three-way handshake. Service is only considered to be normal when the port is in listening state, thus avoiding false judgments. Second-level fault response: After three consecutive failed probes, the tracking status is switched immediately, and the policy routing is executed synchronously to switch traffic.

4. The three-site mutual backup method under the commercial encrypted network virtualization architecture according to claim 1 or 2, characterized in that, A commercial-grade encrypted channel for cross-regional transmission is established between the main station, the first branch station, and the second branch station. This encrypted channel specifically includes: Data encryption: The core business data of the main site is first encrypted through the protocol, and the ciphertext is generated by the AES-256 algorithm. At the same time, the check value is generated by the SHA2-256 algorithm. Tunnel encapsulation: The encrypted ciphertext is encapsulated by a general routing encapsulation protocol, an internal tunnel address header is added, and it is transmitted to the first or second branch station with a fixed public address via a dedicated China Unicom line; Decapsulation and decryption: After receiving the data packet, the firewall of the first or second substation first decapsulates the general route encapsulation tunnel, extracts the Internet Protocol security ciphertext, then verifies the data integrity through SHA2-256, and decrypts it through AES-256 to obtain the original internal network data.

Images