Disaster recovery backup method and device, equipment and storage medium

Abstract

The invention discloses a disaster recovery backup method and device, equipment and a storage medium, and relates to the technical field of data processing. The method comprises the steps of obtaining a task change event which refers to an event triggered by state change of a task, analyzing the task change event, generating a dependency tree containing a multi-level dependency relationship, obtaining standby nodes corresponding to a target task and an associated task based on the dependency tree, and sending the standby nodes to the associated task. And sending the target task and the associated task to respective corresponding standby nodes in parallel. The dependency tree takes a target task in the task change event as a root node and takes an associated task having a dependency relationship with the target task as a child node. Therefore, by generating the dependency tree containing the multi-level dependency relationship, the dependency tasks with the association relationship can be accurately identified, the target tasks and the association tasks are sent to the corresponding standby nodes in parallel, the standby nodes execute the tasks in parallel, and the problem of task omission or execution conflicts caused by disorder of the dependency relationship can be avoided.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to disaster recovery backup methods, apparatus, equipment and storage media. Background Technology

[0002] With the rapid integration of artificial intelligence (AI) technology into the disaster recovery field, machine learning can now predict the frequency of task changes to optimize synchronization strategies. Current data synchronization mechanisms in disaster recovery systems primarily include table-level synchronization and log-based asynchronous replication.

[0003] Table-level synchronization: Performs full or incremental synchronization on a physical table basis in databases such as MySQL (My Structured Query Language). For example, it captures task changes by parsing binary logs (bin logs) and synchronizes them to standby nodes in table order. Log-based asynchronous replication: Achieves real-time data replication through database logs (such as MySQL's binary logs or Oracle's redo logs). For example, the Data Transmission Service (DTS) uses log parsing and data replay technology to achieve real-time data replication.

[0004] However, with table-level synchronization schemes, if foreign key dependencies exist between tables (e.g., the order table depends on the user table), incorrect synchronization order can lead to inconsistencies in disaster recovery data logic, failing to meet transactional requirements. Log-based asynchronous replication schemes require replaying backlogged logs during failover, resulting in recovery time objectives (RTO) of several hours and failing to guarantee the atomicity of cross-database transactions. Summary of the Invention

[0005] The purpose of this application is to provide a disaster recovery backup method, apparatus, device, and storage medium that can accurately back up data and quickly and accurately restore data in the event of data failure.

[0006] To achieve the above objectives, this application adopts the following technical solution:

[0007] Firstly, this application provides a disaster recovery backup method, which includes: acquiring task change events, where a task change event is an event triggered by a change in the state of a task; parsing the task change event; generating a dependency tree containing multi-level dependencies, where the dependency tree has the target task in the task change event as the root node and related tasks that have a dependency relationship with the target task as child nodes, and the child nodes are distributed sequentially according to the dependency hierarchy; based on the dependency tree, obtaining the backup nodes corresponding to the target task and related tasks respectively, and sending the target task and related tasks in parallel to their respective backup nodes.

[0008] The technical solution provided in this application can accurately identify dependent tasks with related relationships by generating a dependency tree containing multi-level dependencies, and send the target task and related tasks in parallel to their respective backup nodes. The backup nodes execute the tasks in parallel, which can avoid the problem of task omission or execution conflict caused by the confusion of dependency relationships.

[0009] One possible implementation, based on a dependency tree, obtains the backup nodes corresponding to the target task and related tasks. Specifically, this can be achieved by parsing the hierarchical structure of the dependency tree to obtain the dependency hierarchy between the target task and related tasks, and then, based on the dependency hierarchy and node allocation rules, obtaining the backup nodes corresponding to each task. This approach clarifies task dependencies based on the hierarchical structure of the dependency tree and accurately matches backup nodes according to the node allocation rules, avoiding node allocation errors caused by conflicting dependency relationships.

[0010] Another possible implementation involves the following dependency hierarchy: first-level related tasks, second-level related tasks, and related tasks below the second level corresponding to the target task. The dependency strength between the first-level related tasks and the target task is greater than that between the second-level related tasks and the target task, and the dependency strength between the second-level related tasks and the target task is greater than that between the related tasks below the second level and the target task. Matching backup nodes according to the dependency strength hierarchy prioritizes the disaster recovery reliability of core dependent tasks while allocating resources in an orderly manner, improving overall disaster recovery efficiency and accuracy.

[0011] Another possible implementation involves the following node allocation rules: assigning the target task to a first-level backup node, first-level related tasks to second-level backup nodes, second-level related tasks to third-level backup nodes, and tasks below the second level to edge backup nodes. This allows for hierarchical matching of backup nodes based on dependency strength, ensuring both the priority of core task disaster recovery and precise resource allocation.

[0012] Another possible implementation involves parsing task change events to generate a dependency tree containing multi-level dependencies. Specifically, this can be achieved by parsing the dependencies of task identifiers in the task change event to obtain the static and dynamic dependencies corresponding to the target task. Based on these static and dynamic dependencies, and according to the dependency hierarchy, a dependency tree containing multi-level dependencies is generated. By parsing the dependencies of task identifiers in the task change event, the static and dynamic dependencies of the target task are distinguished. Then, based on the dependency hierarchy logic of both, a dependency tree containing multi-level associations is constructed, accurately representing the hierarchical dependencies between tasks.

[0013] Another possible implementation of the above method includes: converting the dependency tree into a dependency graph; analyzing redundant paths in the dependency graph using a preset graph analysis model to obtain the analysis results of redundant paths; generating a compression strategy based on the analysis results of redundant paths; and dynamically adjusting the dependency tree according to the compression strategy. Converting the dependency tree into a dependency graph, identifying redundant paths and generating a compression strategy based on the graph analysis model, and dynamically adjusting the dependency tree can simplify the dependency structure and avoid resource waste caused by redundancy.

[0014] Another possible implementation involves parsing the dependencies of task identifiers in the task change event to obtain the static dependencies corresponding to the target task. Specifically, this can be achieved by: extracting foreign key constraint information of the target task from the database corresponding to the task identifier in the task change event. This foreign key constraint information includes the related fields referencing the task identifier; based on the extracted foreign key constraint information, the static dependent task is obtained. The static dependent task is a related task that references the task identifier and / or related fields. The relationship between the static dependent task and the target task is the static dependency relationship. Extracting foreign key constraint information from the database corresponding to the task identifier to determine the static dependent task can accurately pinpoint the static dependency relationship of the target task, ensuring the accuracy and reliability of static dependency identification.

[0015] Another possible implementation involves parsing the dependencies of task identifiers in the task change event to obtain the dynamic dependencies corresponding to the target task. Specifically, this can be achieved by obtaining the Structured Query Language (SQL) execution plan triggered by the task change event. The SQL execution plan includes the logical order of SQL statement execution. Parsing this execution order reveals the dynamic dependent tasks associated with the target task during execution. The relationship between these dynamic dependent tasks and the target task constitutes the dynamic dependency. By obtaining the SQL execution plan triggered by the task change event and parsing its execution order, the dynamic dependent tasks associated with the target task can be accurately identified, thus clarifying the dynamic dependencies and ensuring the accuracy of dynamic dependency analysis.

[0016] Another possible implementation of the above method includes: in the event of a failure of a related task, executing the related task based on the backup node corresponding to the related task. Executing the task according to its corresponding backup node when a related task fails can quickly restore the operation of the related task, avoiding the impact of the target task on the interruption of the related task, and ensuring the continuity and stability of the overall task flow.

[0017] Secondly, a disaster recovery backup device is provided, which includes an acquisition module, a parsing module, and a backup module.

[0018] The aforementioned acquisition module is used to acquire task change events, which are events triggered by changes in the state of a task.

[0019] The aforementioned parsing module is used to parse task change events and generate a dependency tree containing multi-level dependencies. The dependency tree takes the target task in the task change event as the root node and the associated tasks that have a dependency relationship with the target task as child nodes, and the child nodes are distributed sequentially according to the dependency hierarchy.

[0020] The aforementioned backup module is used to obtain the backup nodes corresponding to the target task and related tasks based on the dependency tree, and to send the target task and related tasks to their respective backup nodes in parallel.

[0021] In one possible implementation, the aforementioned backup module is also used to parse the hierarchical structure of the dependency tree, obtain the dependency hierarchy between the target task and related tasks, and obtain the backup nodes corresponding to the target task and related tasks according to the dependency hierarchy and node allocation rules.

[0022] Another possible implementation is that the above dependency hierarchy includes: first-level associated tasks, second-level associated tasks, and associated tasks below the second level corresponding to the target task. Among them, the dependency strength between the first-level associated task and the target task is greater than the dependency strength between the second-level associated task and the target task, and the dependency strength between the second-level associated task and the target task is greater than the dependency strength between the associated tasks below the second level and the target task.

[0023] Another possible implementation is that the above node allocation rules include: allocating target tasks to first-level backup nodes, first-level related tasks to second-level backup nodes, second-level related tasks to third-level backup nodes, and related tasks below the second level to edge backup nodes.

[0024] In another possible implementation, the parsing module is also used to parse the dependency relationship of the task identifier in the task change event, obtain the static dependency relationship and dynamic dependency relationship corresponding to the target task, and generate a dependency tree containing multi-level dependency relationships according to the dependency hierarchy based on the static dependency relationship and dynamic dependency relationship.

[0025] In another possible implementation, the aforementioned parsing module is also used to convert the dependency tree into a dependency graph, analyze the redundant paths of the dependency graph using a preset graph analysis model, obtain the analysis results of the redundant paths of the dependency graph, generate a compression strategy based on the analysis results of the redundant paths, and dynamically adjust the dependency tree according to the compression strategy.

[0026] In another possible implementation, the above-mentioned parsing module is also used to extract foreign key constraint information of the target task based on the database corresponding to the task identifier in the task change event. The foreign key constraint information includes the associated fields that reference the task identifier. Based on the extracted foreign key constraint information, the static dependent task is obtained. The static dependent task is the associated task that references the task identifier and / or the associated fields. The relationship between the static dependent task and the target task is the static dependency relationship.

[0027] In another possible implementation, the parsing module is also used to obtain the structured query language (SQL) execution plan triggered by the task change event. The SQL execution plan includes the logical order of SQL statement execution. The logical order of SQL statement execution is parsed to obtain the dynamic dependent tasks associated with the target task during execution. The relationship between the dynamic dependent tasks and the target task is the dynamic dependency relationship.

[0028] In another possible implementation, the aforementioned backup module is also used to execute the associated task based on the backup node corresponding to the associated task in the event of a failure of the associated task.

[0029] The technical effects of any implementation method in the second aspect can be found in the technical effects of any implementation method in the first aspect mentioned above, and will not be repeated here.

[0030] Thirdly, a computer device is provided, comprising: a processor and a memory, wherein the memory stores at least one computer program, and the at least one computer program is loaded and executed by the processor to implement the disaster recovery backup method described above.

[0031] Fourthly, a computer-readable storage medium is provided, wherein at least one computer program is stored in the computer-readable storage medium, and the at least one computer program is loaded and executed by a processor to implement the disaster recovery backup method described above.

[0032] Fifthly, a computer program product is provided, which includes a computer program or instructions, and when the computer program or instructions are executed by a processor, the disaster recovery and backup method described above is implemented.

[0033] The solutions provided in aspects three through five above are used to implement the method provided in aspect one above, and their specific implementations will not be described in detail here. The technical effects corresponding to any implementation method of the solutions provided in aspects three through five above can be found in the technical effects corresponding to any implementation method in aspect one above, and will not be described in detail here.

[0034] It should be noted that any of the possible implementations of any of the above aspects can be combined, provided that the solutions do not contradict each other. Attached Figure Description

[0035] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0036] Figure 1 A schematic diagram of the structure of a disaster recovery backup system provided in this application embodiment;

[0037] Figure 2 A flowchart illustrating a disaster recovery backup method provided in an embodiment of this application;

[0038] Figure 3 A flowchart illustrating a dependency tree compression method provided in this application embodiment;

[0039] Figure 4 A schematic diagram of the principle of an original dependency graph provided in an embodiment of this application;

[0040] Figure 5 A schematic diagram illustrating the principle of an optimized dependency graph provided in an embodiment of this application;

[0041] Figure 6 This is a schematic diagram of the structure of a disaster recovery backup device provided in an embodiment of this application;

[0042] Figure 7 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0043] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0044] In the description of this application, it should be understood that the terms "upper," "lower," "left," "right," "front," "rear," "inner," and "outer," etc., indicate the orientation or positional relationship based on the orientation or relative positional relationship shown in the accompanying drawings. They are used only for the convenience of describing this application and for simplification, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this application. Unless otherwise specified, the above-mentioned orientational descriptions can be flexibly set in practical applications, provided that the relative positional relationships shown in the accompanying drawings are satisfied.

[0045] The terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this application, unless otherwise stated, "a plurality of" means two or more.

[0046] In the description of this application, it should be noted that, unless otherwise expressly specified and limited, the terms "installation," "connection," "linking," and "communication" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection. They can refer to a direct connection or an indirect connection through an intermediate medium, or a connection within two components. Those skilled in the art can understand the specific meaning of the above terms in this application according to the specific circumstances.

[0047] In embodiments of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, article, or apparatus that includes that element.

[0048] In the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design that is described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design. Specifically, the use of the terms "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0049] In the embodiments of this application, at least one can also be described as one or more, and multiple can be two, three, four or more, and this application does not impose any restrictions.

[0050] In the description of this specification, specific features, structures, materials, or characteristics may be combined in any suitable manner in one or more embodiments or examples.

[0051] To facilitate understanding, the terms used in the embodiments of this application will be explained first.

[0052] Recovery Time Objective (RTO): refers to the maximum acceptable time required from the occurrence of a disaster (such as system crash, data center failure, natural disaster, etc.) to the full recovery of business processes or systems to a normal operating state.

[0053] Dependency chain: refers to an ordered chain of relationships formed between multiple tasks, components, modules or steps in project management, software development, system architecture or business processes due to their interdependencies.

[0054] A Directed Acyclic Graph (DAG) is a special type of directed graph data structure. Its core characteristics are that it is "directed" and "loopless"—that is, all edges in the graph have a clear direction (from one node to another), and there is no path that can start from a node, go through several edges, and return to itself (to avoid infinite loops).

[0055] Incremental synchronization refers to copying only the data added, modified, or deleted from the source device since the last synchronization (i.e., incremental data), rather than all data, during each synchronization. After synchronization, the target device only updates the changed parts, maintaining consistency with the source device.

[0056] Full synchronization: This means that during each synchronization, all data from the source end is completely copied to the target end, regardless of whether any data has been added, modified, or deleted. After synchronization, the data on the target end is completely consistent with the data on the source end (the original data on the target end will be overwritten or replaced by the full data on the source end).

[0057] Chained transaction packages are a technical solution used in distributed systems or blockchain technology to manage related transactions. The core is to organize multiple independent transactions with dependencies into a "transaction chain" according to a preset logical order. Through unified rules, it is ensured that they either execute successfully as a whole or trigger a coordinated rollback or compensation when a link fails, so as to maintain data consistency and business process integrity.

[0058] Kafka message queue: refers to a distributed, high-throughput, low-latency message middleware. Its core function is to decouple "producers (data senders)" and "consumers (data receivers)" in distributed systems, achieve asynchronous communication and traffic shaping. It is a key component for building real-time data pipelines, log collection, and event-driven architectures.

[0059] Two-Phase Commit Protocol (2PC) is a consistency protocol used in distributed systems to enable multiple nodes (such as databases and servers) to jointly complete a transaction. Its core objective is to ensure that all participating nodes either execute the transaction (commit) simultaneously or cancel the transaction (rollback) simultaneously, avoiding data inconsistency problems where some nodes execute the transaction while others do not.

[0060] It should be noted that all information (including but not limited to device information, network information, etc.), data (including but not limited to data used for analysis, stored data, displayed data, etc.), and signals involved in this application have been authorized by the subject or fully authorized by all parties, and the collection, use, and processing of related data must comply with relevant laws, regulations, and standards. For example, the target tasks, related tasks, dependency trees, etc. involved in this application were all obtained with full authorization.

[0061] Commonly used disaster recovery and backup methods in the industry mainly involve table-level synchronization and log-based asynchronous replication, which will be briefly explained below.

[0062] Table-level synchronization: This method performs full or incremental synchronization based on physical tables in relational database management systems such as MySQL. For example, it captures task changes by parsing binary logs and synchronizes them to standby nodes in table order.

[0063] Log-based asynchronous replication: Real-time data replication is achieved through database logs. For example, data transmission services use log parsing and data replay technologies to achieve real-time data replication.

[0064] However, the above technical solutions still have the following drawbacks:

[0065] (1) Insufficient transactional reliability: Table-level synchronization (such as MySQL full / incremental synchronization) only guarantees the consistency of data in a single table, and cannot guarantee atomicity when performing cross-table operations. For example, when updating the order table and the user table, if only the order table is synchronized while the user table is not, the disaster recovery data will be in a logically inconsistent state, which cannot support business switching. Log-based asynchronous replication has consistency delays, and backlogged logs need to be replayed during failover, resulting in an RTO of several hours.

[0066] (2) Lack of Dependency Handling: Existing solutions rely on manually defined inter-table dependency rules (such as foreign key constraints), which cannot dynamically identify complex business dependency chains (such as multi-table cascading updates). For example, in an e-commerce scenario, the order table depends on the user address table, which in turn depends on the region table. Manual configuration can easily miss intermediate dependency nodes, leading to data chain breaks. Static dependency graphs cannot adapt to business changes (such as adding fields or table relationships), requiring frequent manual rule updates, resulting in high maintenance costs.

[0067] (3) Low recovery efficiency: Asynchronous replication based on logs requires replaying the entire change history, resulting in slow data recovery speed during disaster recovery switchover (e.g., replaying tens of millions of data points takes several minutes). Single point of failure recovery relies on centralized nodes. If the master node fails, the entire disaster recovery system is paralyzed and cannot automatically switch to the backup node.

[0068] Based on this, this application proposes a disaster recovery backup method, including: acquiring task change events (events triggered by changes in task state), parsing the task change events, generating a dependency tree containing multi-level dependencies, obtaining backup nodes corresponding to the target task and related tasks based on the dependency tree, and sending the target task and related tasks to their respective backup nodes in parallel. The dependency tree uses the target task in the task change event as the root node and related tasks that depend on the target task as child nodes, with child nodes distributed sequentially according to the dependency hierarchy. Thus, by generating a dependency tree containing multi-level dependencies, dependent tasks with related relationships can be accurately identified. Based on the dependency tree, the target task and related tasks can be sent to their respective backup nodes in parallel, and the backup nodes execute tasks in parallel, avoiding task omissions or execution conflicts caused by confusing dependencies.

[0069] The solution provided in this application can be applied to Figure 1 In the disaster recovery backup system shown, Figure 1 This is a schematic diagram of the structure of a disaster recovery backup system provided in an embodiment of this application.

[0070] For example, the disaster recovery backup system includes a task change capture module 100, a dependency resolution engine module 101, a chain synchronization controller module 102, an artificial intelligence (AI) optimization module 103, and a backup node cluster module 104.

[0071] The task change capture module 100 is used to acquire task change events.

[0072] The dependency resolution engine module 101 is used to parse task change events and generate a dependency tree and / or dependency graph containing multi-level dependencies.

[0073] The chained synchronization controller module 102 is used to generate chained transaction packages based on dependency trees and / or dependency graphs, coordinate parallel synchronization tasks of multiple nodes, and ensure the atomicity of cross-node transactions through the 2PC mechanism.

[0074] AI optimization module 103 is used to identify redundant dependent nodes (such as indirect dependencies without actual business connection), shorten the synchronization link (compress the dependency graph), and predict potential failures (such as log backlog, excessive node load) to trigger expansion or routing adjustments in advance.

[0075] The standby node cluster module 104 is used to obtain the standby nodes corresponding to the target task and related tasks based on the dependency tree, and to receive tasks through the Kafka message queue, and write the received tasks to local storage according to the dependency tree hierarchy.

[0076] Figure 2 This is a flowchart illustrating a disaster recovery backup method provided in an embodiment of this application. The method can be executed by a disaster recovery backup system. The disaster recovery backup system can be... Figure 1 The disaster recovery and backup system in the middle.

[0077] like Figure 2 As shown, the disaster recovery backup method provided in this application embodiment may include:

[0078] Step S201: Obtain the task change event.

[0079] Among them, the task change event refers to the event triggered by the change of the state of the task.

[0080] Optionally, the task change event includes at least one of the following: event identifier, task identifier, change table, change type, task status before change, task status after change, and timestamp, but is not limited thereto, and the embodiments of this application do not specifically limit it.

[0081] Event identifiers are global codes used to uniquely identify individual task change events, ensuring that events can be accurately located throughout the entire chain (generation, collection, processing, and storage), avoiding duplicate statistics or omissions.

[0082] For example, in an e-commerce scenario, the event triggered by the first payment for order_id=1001 has an event identifier format of event type_timestamp_random number, such as: ORDER_PAY_STATUS_20240822091503_721. If the order is subsequently cancelled (status changes from paid to cancelled), the event identifier after cancellation is: ORDER_CANCEL_STATUS_20240822102015_348.

[0083] The task identifier is used to bind the specific task corresponding to the task change event.

[0084] For example, the tasks bound to event identifier ORDER_PAY_STATUS_20240822091503_721 include:

[0085] Order task: Bind to the primary key of the order table, task identifier: order_id = 1001 (corresponding to order number 1001 in the e-commerce platform).

[0086] Payment task: Bind the primary key of the payment record, task identifier: pay_id=5008 (corresponding to the payment transaction number 5008).

[0087] Inventory task: Bind the primary key of the inventory record, task identifier: inventory_id = 8003 (corresponding to the inventory entry with number 8003).

[0088] A change table is a specific table used to record changes to the structure or content of a data table.

[0089] For example, if a record in the users table is modified, the table is changed to the users table.

[0090] Change type: Used to describe the specific operation type that changes the task.

[0091] Optionally, the task change type includes at least one of INSERT, UPDATE, and DELETE, but is not limited thereto, and the embodiments of this application do not specifically limit this.

[0092] INSERT: Indicates adding one or more records to the change table.

[0093] UPDATE: This indicates that the values ​​of some fields in an existing record in the change table are modified.

[0094] DELETE: This indicates that the specified record in the Changes table will be deleted.

[0095] Task status before change: This records the status of the task before the current change occurred.

[0096] For example, for an order task: if the previous status was "unpaid" (pending payment), it means that the order has not been paid before this payment.

[0097] Payment task: The previous status was "processing," indicating that the payment was being processed before the result was confirmed.

[0098] Logistics task: The previous status was pending_delivery, indicating that the logistics had not yet left the warehouse before this shipment.

[0099] Task status after change: This is used to record the status of the task after this change occurs.

[0100] Order task: The status has been changed to "paid" (paid), indicating that the order payment has been completed;

[0101] Payment task: The status after the change is "success" (payment successful), indicating that the order payment has been completed;

[0102] Logistics task: The status after the change is already_delivery (shipped), indicating that the logistics has been dispatched.

[0103] Timestamp: Used to record the time when a task change event is generated, usually accurate to the millisecond level.

[0104] The timestamp format is the yyyy-MM-dd HH:mm:ss.SSS standard format.

[0105] The format is as follows: Year (yyyy): four digits, e.g., 2025; Month (MM): two digits, ranging from [01, 12]; Day (dd): two digits, ranging from [01, 31]; Hour (HH): two digits, using 24-hour format, ranging from [00, 23]; Minute (mm): two digits, ranging from [00, 59]; Second (ss): two digits, ranging from [00, 59]; Millisecond (SSS): three digits, ranging from [000, 999].

[0106] For example, the timestamp of the order payment event is 2024-08-22 09:15:03.689, which means that the event was generated at 9:15:03.689 milliseconds on August 22, 2024.

[0107] For example, task change events can be obtained through MySQL's binary logs.

[0108] MySQL's binary log is a core log file that comes with the MySQL master database. It is used to record task change operations in the database, such as INSERT, UPDATE, and DELETE.

[0109] For example, by retrieving the operation UPDATE order SET status='paid'WHERE id=1001 from the MySQL binary log, the task change event can be obtained, including: the changed table is the order table, the task identifier is id=1001, the change type is UPDATE, the task status before the change is unpaid, and the task status after the change is paid.

[0110] Step S202: parse the task change event and generate a dependency tree containing multi-level dependencies.

[0111] In this context, dependency refers to the relationship between two or more objects, tasks, modules, or entities, where the existence, operation, completion, or state of one party depends on the fulfillment of preconditions by the other. Simply put, it's the logical connection of who cannot live without whom, and who waits for whom; the core is the dependent party's preconditions for the dependent party.

[0112] For example, order delivery (dependent party) → order payment (dependent party), meaning that order delivery is contingent upon order payment being completed.

[0113] A dependency tree is a tree structure used to clearly show the dependencies between multiple tasks, that is, the existence, operation, or completion of a task depends on the existence, operation, or completion of other tasks.

[0114] The dependency tree visually represents the hierarchical relationship between the root node, parent node, and child nodes, showing who depends on whom.

[0115] Root node: The topmost starting point of the dependency tree, it is the source of the entire dependency relationship and has no parent node.

[0116] Child nodes: represent the tasks that are depended upon.

[0117] Parent node: Represents a task that depends on other tasks (it can only exist or run based on child nodes).

[0118] In this embodiment of the application, the dependency tree takes the target task in the task change event as the root node, and the associated tasks that have a dependency relationship with the target task as child nodes, and the child nodes are distributed in order according to the dependency hierarchy.

[0119] For example, the dependencies of task identifiers in a task change event are parsed to obtain the static and dynamic dependencies of the target task.

[0120] The target task refers to the task triggered by the task change event.

[0121] Static dependencies are the inherent, fundamental dependencies of a task that do not change with state or time. They are prerequisites for the existence or execution of a task (these dependencies must exist regardless of the state of the task).

[0122] For example, the static dependency of the order task (id=1001) is the user information verification task (id=2001), which indicates that any order must first verify user information. In other words, the order task and the user information verification task have a static dependency relationship.

[0123] Specifically, the detailed steps for obtaining the static dependencies corresponding to the target task include:

[0124] Based on the database corresponding to the task identifier in the task change event, extract the foreign key constraint information of the target task, and obtain the static dependent task based on the extracted foreign key constraint information.

[0125] A static dependency task is an associated task that references a task identifier and / or associated fields. The relationship between a static dependency task and the target task is called a static dependency relationship.

[0126] Foreign key constraints are a set of rules used to define the relationship between two data tables or tasks.

[0127] Optionally, the foreign key constraint information includes, but is not limited to, the associated field that references the task identifier, and the embodiments of this application do not specifically limit this.

[0128] For example, query the database schema corresponding to the task identifier to obtain the foreign key constraints of the target task.

[0129] A database schema is used to define the names of tables, column names, data types (such as integers and strings), primary key / foreign key relationships, etc., in a database. For example, the schema of a user table might contain fields such as user ID (integer, primary key), username (string), and phone number (string, unique).

[0130] For example, if the target task is to update the order table, querying the database will determine that the order table has a foreign key user_id that is related to the user table (user.id), indicating that the order must belong to a certain user. Therefore, the order table is statically dependent on the user table.

[0131] Recursively resolve the dependencies of the user table (such as the foreign key constraint address_id in the user table related to the address table) until there are no more foreign key relationships.

[0132] The static dependency relationship of the order table is output as: order→user→address (a three-level static dependency chain, with arrows indicating dependencies).

[0133] Dynamic dependencies refer to conditional dependencies that arise dynamically with changes in task status or business context, and only take effect under specific states or scenarios.

[0134] For example, the order task (id=1001) only becomes dependent on the logistics delivery task (id=3001) after its status changes to paid (no logistics dependency is needed when it is unpaid). In other words, the order task and the logistics delivery task have a dynamic dependency relationship.

[0135] Specifically, the detailed steps to obtain the dynamic dependencies corresponding to the target task include:

[0136] Obtain the Structured Query Language (SQL) execution plan triggered by the task change event. The SQL execution plan includes the logical order of SQL statement execution. Parse the logical order of SQL statement execution to obtain the dynamic task table associated with the target task during execution.

[0137] The relationship between a dynamically dependent task and a target task is called a dynamic dependency relationship.

[0138] SQL is a standardized programming language specifically designed for managing and manipulating relational databases; it is the universal language in the database field.

[0139] For example, `SELECT username, age FROM users WHERE age>18` means querying all users whose age is greater than 18 from the database table.

[0140] For example, when the target task executes the UPDATE order statement, it needs to verify the product inventory (the internal logic includes SELECT * FROM product WHERE id = order.product_id), so the order table dynamically depends on the product table.

[0141] Recursively resolve the dynamic dependencies of the product table (such as the product table's relationship with the category table).

[0142] The output of the dynamic dependency relationship of the order table is: order→product→category (second-level dynamic dependency chain, arrows indicate dependencies).

[0143] Based on static and dynamic dependencies, a dependency tree containing multi-level dependencies is generated according to the dependency hierarchy.

[0144] For example, starting from the root node (order.id=1001), a dependency tree is constructed according to the dependency relationship (the dependent table is the parent node and the dependent table is the child node), and attribute information is added to each node.

[0145] Optionally, the attribute information includes at least one of data version number, hash value, and hash value, but is not limited thereto, and the embodiments of this application do not specifically limit it.

[0146] Data version number: Records the current version of the data for this node (e.g., order_v1.2, user_v3.0), used to track change history.

[0147] Hash value: A hash calculated based on the node data content (such as SHA-256 (data with order.id=1001)) used to verify data integrity.

[0148] Dependency hierarchy: The root node is at level 0, direct dependencies are at level 1, indirect dependencies are at level 2, and so on (for easier sorting later).

[0149] For example, the generated dependency tree is:

[0150] Root node: Level 0: order(id=1001) [Version: v2.1, Hash: h1].

[0151] ├─Child node level 1 (static): user(id=2001)[version:v1.5, hash:h2].

[0152] │└─Child node level 2 (static): address(id=3001)[Version:v1.0, Hash:h3].

[0153] └─Child node level 1 (dynamic): product(id=4001)[Version:v3.2, Hash:h4].

[0154] └─Child node level 2 (dynamic): category(id=5001)[Version:v2.0, Hash:h5].

[0155] Step S203: Based on the dependency tree, obtain the backup nodes corresponding to the target task and related tasks, and send the target task and related tasks to their respective backup nodes in parallel.

[0156] Among them, the standby node refers to the component used for redundancy backup and fault recovery. Its core function is to quickly take over the work when the primary node (the node that undertakes the main business / data processing) fails, is under maintenance, or is overloaded, so as to ensure the continuous operation of the system.

[0157] For example, the dependency tree is parsed to obtain the dependency hierarchy between the target task and related tasks. Based on the dependency hierarchy and node allocation rules, the corresponding backup nodes for the target task and related tasks are obtained.

[0158] Dependency hierarchy includes: first-level related tasks, second-level related tasks, and related tasks below the second level corresponding to the target task.

[0159] Among them, the dependency strength between the first-level associated task and the target task is greater than that between the second-level associated task and the target task, and the dependency strength between the second-level associated task and the target task is greater than that between the associated tasks below the second level and the target task.

[0160] For example, the static dependency relationship of the order table in the dependency tree is: order→user→address.

[0161] After parsing, the root node (target task: update the order table): order table (ID: 1001, operation type: UPDATE, status: paid); first-level related task (synchronize the user table): user table (ID: 2001, related field: order.user_id = user.id); second-level related task (synchronize the address table): address table (ID: 3001, related field: user.address_id = address.id).

[0162] The node allocation rules include: assigning target tasks to first-level backup nodes, first-level related tasks to second-level backup nodes, second-level related tasks to third-level backup nodes, and related tasks below the second level to edge backup nodes.

[0163] Assign a first-level backup node Broker A to the target task - update the order table, assign a second-level backup node Broker B to the first-level related task - synchronize the user table, and assign a third-level backup node Broker C to the second-level related task - synchronize the address table. Then send the target task, the first-level related task, and the second-level related task to their respective backup nodes in parallel.

[0164] In the event of a failure of an associated task, the associated task will be executed based on the backup node corresponding to the associated task.

[0165] For example, by combining Kafka partitioning planning, the target task and related tasks are reasonably allocated to the number of Broker nodes to ensure that each task corresponds to an independent partition.

[0166] Assign partition 1 to the target task - update the order table, partition 2 to the first-level related task - synchronize the user table, and partition 3 to the second-level related task - synchronize the address table, to avoid competing for resources with the target task.

[0167] Tasks are sent to different Broker nodes according to partitioning rules. For example, tasks to update the order table are sent to partition 1 of Broker A, tasks to synchronize the user table are sent to partition 2 of Broker B, and tasks to synchronize the address table are sent to partition 3 of Broker C.

[0168] After completing message validity verification (such as data version matching and target node correctness), each level of backup node executes its corresponding task logic. For example, the first-level backup node executes UPDATE order SET...WHERE id=1001 (target task), and the second-level backup node executes INSERT user...WHERE id=2001 (related task), ensuring that data synchronization operations accurately match task requirements.

[0169] In summary, the technical solution provided in this application can accurately identify dependent tasks with related relationships by generating a dependency tree containing multi-level dependencies, and send the target task and related tasks in parallel to their respective backup nodes. The backup nodes execute the tasks in parallel, which can avoid task omissions or execution conflicts caused by chaotic dependency relationships.

[0170] The above embodiments have described in detail the disaster recovery backup method. The following is a brief description of the dependency tree compression optimization method.

[0171] Figure 3 A flowchart illustrating a dependency tree compression method provided in this application embodiment may include:

[0172] Step S301: Based on the dependency graph transformed from the dependency tree, obtain the analysis results of redundant paths in the dependency graph.

[0173] Redundant paths refer to dependency paths that exist in the dependency graph but have no practical significance and can be simplified or replaced.

[0174] A dependency graph is a directed graph derived from a dependency tree. It retains the core dependencies of the dependency tree but allows more relationships between nodes (adding explicit supplementary dependencies, cross-level relationships, etc., breaking the strict hierarchy of the tree).

[0175] Taking the dependency tree: A (root) → B → C → D as an example, after converting it into a dependency graph, the following redundant paths may appear: In the dependency tree, the dependency of the parent node on the descendant node is indirect and transitive (such as A depends on B, B depends on C → A indirectly depends on C), and no explicit labeling is required.

[0176] If additional cross-level direct dependencies such as A→C and A→D are added to the dependency graph, they are considered redundant paths. This is because the dependencies of these paths can already be derived from the original tree's A→B→C and A→B→C→D; their explicit existence neither adds new information nor increases the complexity of the graph.

[0177] Implicit path in dependency tree: A→B→C→D (A indirectly depends on C and D)

[0178] Redundant paths in the dependency graph: A→C, A→D (transitivity is deducible, no new information).

[0179] In this embodiment of the application, the dependency tree is converted into a dependency graph, and the redundant paths of the dependency graph are analyzed by a preset graph analysis model to obtain the analysis results of the redundant paths of the dependency graph.

[0180] For example, Figure 4 This is a schematic diagram illustrating the principle of an original dependency graph provided in an embodiment of this application. For example... Figure 4 As shown. The original dependency tree nodes include: region table, address table, user table, order table, product table, and inventory table.

[0181] The dependencies are as follows: Region table (low-frequency call, i.e., dependent on) Address table; Address table (medium-frequency call) User table; User table (high-frequency call) Order table; Product table (medium-frequency call) Order table; Inventory table (high-frequency call) Product table.

[0182] Optionally, the graph analysis model includes graph neural network (GNN) algorithm models, but is not limited thereto, and the embodiments of this application do not impose specific limitations on this.

[0183] The GNN algorithm model combines the attribute information of nodes in a graph with the connection relationships (topology) between nodes, and learns the feature representations of nodes, edges or the entire graph through neural network iteration, ultimately achieving tasks such as classification, prediction, and clustering.

[0184] For example, the GNN algorithm model is used to... Figure 4 Redundancy analysis was performed on the dependency graph shown, and the analysis results of redundant paths in the dependency graph include:

[0185] (1) Compress the address-region relationship and merge the nodes.

[0186] (2) Use the proxy node (Proxy1) to pre-store user table statistics and access the user table through the proxy.

[0187] (3) Link differentiation: The order table → product table is the core link (direct access), while the order table → user table is proxied through Proxy1.

[0188] Step S302: Generate a compression strategy based on the analysis results of redundant paths.

[0189] Compression strategies refer to the operational logic of merging, simplifying, and removing redundancy from nodes, edges, and paths in graph structures (such as data dependency graphs and call relationship graphs) through algorithms or rules.

[0190] For example, a compression strategy generated based on the analysis results of redundant paths includes:

[0191] (1) Node merging: Low-contribution nodes, such as those in the region table, are aggregated with the upstream node address table into a super node address-region, while retaining aggregation characteristics, such as the region ID range. This reduces the number of nodes, making the number of nodes N' in the compressed dependency graph less than the number of nodes N in the original dependency graph.

[0192] (2) Edge pruning: Delete low-frequency edges, such as edges that are accessed less than once per hour from the address table to the region table. At the same time, remove isolated nodes formed after being associated with the deleted edges, thereby reducing the number of edges and achieving a result where the number of edges E' in the compressed dependency graph is less than the number of edges E in the original dependency graph.

[0193] (3) Path replacement: For redundant paths, a proxy node is introduced.

[0194] Taking the order table → user table → address table → region table as an example, create a user information proxy node to pre-store frequently accessed data from the user table and address table, such as the user's default address and region code.

[0195] The order table can directly access the proxy node to obtain the required information, simplifying the original path of order table → user table → address table → region table to order table → proxy node, shortening the dependency chain and improving data access efficiency.

[0196] For example, Figure 5 This is a schematic diagram illustrating the principle of an optimized dependency graph provided in an embodiment of this application. The optimized dependency graph is as follows: Order Table → User Table: proxied by Proxy1, following the pre-stored statistical information link (optimizing repeated access); Order Table → Product Table → Inventory Table: the core link, directly accessed (ensuring efficiency of high-frequency / critical paths). Address-Region: Nodes are merged using a GNN compression strategy to simplify the dependency structure.

[0197] Step S303: Dynamically adjust the dependency tree according to the compression strategy.

[0198] The original dependency tree is adjusted according to the node merging, edge pruning, and path replacement strategies in step S302.

[0199] For example, the optimized dependency tree is: Order Table → User Table: proxied by Proxy1. Order Table → Product Table → Inventory Table: the core link, directly accessed. Address-Region: nodes are merged using the GNN compression strategy to simplify the dependency structure.

[0200] In summary, the technical solution provided in this application reduces storage overhead by compressing the dependency graph, minimizing storage space for redundant nodes and edges, and saving hardware resources. It also improves computational efficiency, as the compressed graph structure is simpler, reducing algorithm iterations and data processing volume, and accelerating task response. Furthermore, it optimizes visualization and analysis, as the simplified graph structure more easily presents core dependencies, reducing the complexity of manual understanding and problem localization. Finally, it enhances system stability by reducing interference from redundant information in downstream processes and lowering the risk of failures caused by complex dependencies.

[0201] The foregoing mainly describes the solution provided in this application. Accordingly, this application also provides a disaster recovery backup device for implementing the above-described method embodiments.

[0202] like Figure 6 The schematic diagram of the disaster recovery backup device shown indicates that the device may include an acquisition module 601, a parsing module 602, and a backup module 603. The acquisition module 601 is used to execute... Figure 2 The illustrated method includes step S201; the parsing module 602 is used to execute... Figure 2 In step S202, the parsing module 602 is also used to execute... Figure 3 The operations of steps S301, S302, and S303 are performed; the backup module 603 is used to execute... Figure 2 The operation of step S203.

[0203] In some embodiments, the disaster recovery backup device includes hardware structures and / or software modules corresponding to the execution of each function in order to achieve the above-described functions. Those skilled in the art will readily recognize that, based on the units and algorithm steps of the examples described in conjunction with the embodiments disclosed herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0204] This application embodiment can divide the disaster recovery backup device into functional modules according to the above method embodiment. For example, each function can be divided into a separate functional module, or two or more functions can be integrated into a feature extraction module. The integrated module can be implemented in hardware or as a software functional module. It should be noted that the module division in this application embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.

[0205] like Figure 7As shown, the computer device provided in this application embodiment may include a processor 701, a bus 702, a communication interface 703, and a memory 704. The processor 701, memory 704, and communication interface 703 communicate with each other via the bus 702. It should be understood that this application does not limit the number of processors and memories in the network device.

[0206] The 702 bus can be a PCI bus, an Extended Industry Standard Architecture (EISA) bus, or a UB bus, etc. Buses can be divided into address buses, data buses, control buses, etc. For ease of representation, Figure 7 The bus 702 may be represented by a single line, but this does not mean that there is only one bus or one type of bus. The bus 702 may include a path for transmitting information between various components of the network device (e.g., memory 704, processor 701, communication interface 703).

[0207] Processor 701 may include any one or more processors such as CPU, graphics processing unit (GPU), microprocessor (MP), or digital signal processor (DSP).

[0208] The memory 704 may include volatile memory, such as random access memory (RAM). The processor 701 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid state drive (SSD).

[0209] The communication interface 703 uses transceiver modules, such as, but not limited to, network interface cards and transceivers, to enable communication between network devices and other devices or communication networks.

[0210] The memory 704 stores executable program code, and the processor 701 executes the executable program code to implement the functions of the aforementioned method embodiments. That is, the memory 704 stores instructions for executing the above-described disaster recovery backup method.

[0211] In another aspect, a computer-readable storage medium is provided, which stores at least one computer program, which is loaded and executed by a processor to implement the disaster recovery backup method provided in the above-described method embodiments.

[0212] On another front, a computer program product is provided, which includes a computer program or instructions. When the computer program or instructions are executed by a processor, the disaster recovery backup method provided in the above-described method embodiments is implemented.

[0213] Through the above description of the implementation methods, those skilled in the art will clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the module can be divided into different functional modules to complete all or part of the functions described above. The specific working process of the system, modules, and units described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0214] Since the backup module, computer-readable storage medium, and computer program product in the embodiments of the present invention can be applied to the above methods, the technical effects they can achieve can also be referred to the above method embodiments. The embodiments of the present invention will not be repeated here.

[0215] The method steps in this embodiment can be implemented in hardware or by a processor executing software instructions. The software instructions can consist of corresponding software modules, which can be stored in random access memory (RAM), flash memory, read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, hard disks, portable hard disks, CD-ROMs, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor, enabling the processor to read information from and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and storage medium can reside in an ASIC. Alternatively, the ASIC can reside in a network device. Of course, the processor and storage medium can also exist as discrete components in the network device.

[0216] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented, in whole or in part, as a computer program product. A computer program product includes one or more computer programs or instructions. When the computer program or instructions are loaded and executed on a computer, the processes or functions of the embodiments of this application are performed, in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, a network device, a user equipment, or other programmable module. The computer program or instructions can be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another. For example, a computer program or instructions can be transferred from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium, such as a floppy disk, hard disk, or magnetic tape; it can also be an optical medium, such as a digital video disc (DVD); or it can be a semiconductor medium, such as a solid-state drive (SSD).

[0217] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method of disaster backup, characterized by, The method comprises: obtaining a task change event, the task change event being an event triggered by a state change of a task; parsing the task change event to generate a dependency tree containing a multi-level dependency relationship, the dependency tree taking a target task in the task change event as a root node, taking associated tasks having the dependency relationship with the target task as child nodes, and the child nodes being distributed in a dependency hierarchy; based on the dependency tree, obtaining a backup node corresponding to each of the target task and the associated tasks, and sending the target task and the associated tasks to the backup node corresponding to each of them in parallel.

2. The method of claim 1, wherein, The backup node corresponding to each of the target task and the associated tasks based on the dependency tree comprises: parsing the hierarchical structure of the dependency tree to obtain the dependency hierarchy of the target task and the associated tasks; obtaining the backup node corresponding to each of the target task and the associated tasks according to the dependency hierarchy and the node allocation rule.

3. The method of claim 2, wherein, The dependency hierarchy comprises: one layer of associated tasks corresponding to the target task, two layers of associated tasks, and two or more layers of associated tasks, wherein the dependency strength of the one layer of associated tasks with the target task is greater than that of the two layers of associated tasks with the target task, and the dependency strength of the two layers of associated tasks with the target task is greater than that of the two or more layers of associated tasks with the target task.

4. The method according to any one of claims 2-3, characterized in that, The node allocation rule comprises: allocating the target task to a first-level backup node, the one layer of associated tasks to a second-level backup node, the two layers of associated tasks to a third-level backup node, and the two or more layers of associated tasks to an edge backup node.

5. The method of claim 1, wherein, The parsing of the task change event to generate a dependency tree containing a multi-level dependency relationship comprises: parsing the dependency relationship of the task identifier in the task change event to obtain the static dependency relationship and the dynamic dependency relationship corresponding to the target task; generating a dependency tree containing a multi-level dependency relationship according to the static dependency relationship and the dynamic dependency relationship, and according to the dependency hierarchy.

6. The method of claim 5, wherein, The method further comprises: converting the dependency tree into a dependency graph, analyzing the redundant path of the dependency graph through a preset graph analysis model to obtain an analysis result of the redundant path of the dependency graph; generating a compression strategy based on the analysis result of the redundant path; dynamically adjusting the dependency tree according to the compression strategy.

7. The method of claim 5, wherein, The parsing of the dependency relationship of the task identifier in the task change event to obtain the static dependency relationship corresponding to the target task comprises: based on the database corresponding to the task identifier in the task change event, extracting foreign key constraint information of the target task, the foreign key constraint information comprising an associated field referring to the task identifier; based on the extracted foreign key constraint information, obtaining a static dependent task, the static dependent task being an associated task referring to the task identifier and / or the associated field, and the relationship between the static dependent task and the target task being a static dependency relationship.

8. The method of claim 5, wherein, The method further comprises: In the case that the associated task fails, the associated task is executed based on the backup node corresponding to the associated task. The device comprises an obtaining module, an analyzing module and a backup module.

9. The method according to any one of claims 1 to 8, characterized in that, The obtaining module is configured to obtain a task change event, the task change event being an event triggered by a state change of a task. The analyzing module is configured to analyze the task change event to generate a dependency tree comprising a plurality of dependency relationships, the dependency tree taking a target task in the task change event as a root node, taking an associated task having a dependency relationship with the target task as a child node, and the child nodes being distributed in a dependency hierarchical relationship.

10. A disaster backup apparatus characterized by comprising: The backup module is configured to obtain backup nodes corresponding to the target task and the associated task based on the dependency tree, and to send the target task and the associated task to the backup nodes corresponding thereto in parallel. The computer device comprises a processor and a memory, and the memory stores at least one computer program, the at least one computer program being loaded and executed by the processor to implement the disaster recovery backup method according to any one of claims 1-9. The computer readable storage medium stores at least one computer program, and the at least one computer program is loaded and executed by the processor to implement the disaster recovery backup method according to any one of claims 1-9. ​ 11. A computer device, comprising: ​ 12. A computer-readable storage medium, characterized in that, ​

Images